I have read a lot about the new version and see things I like (such as generics), but haven't migrated because of fear of change. :-\
I was just curious if any of you have upgraded, and what your thoughts on it are?
QuoteOne interesting feature of the beta is the ability to choose whether or not to use the new 1.5 features. When compiling your code, you have to explicitly state that you want the Java compiler to use the new 1.5 features. You do this with the following syntax:
javac source 1.5 YourClassName.java
I found this in an article I just read, and it is nice to hear. I will be upgrading now, and will post more about it later.
Good plan, I'm the same way. I don't want to change :)
Looking through the spec, I see:
Quote
Autoboxing/Unboxing
This facility eliminates the drudgery of manual conversion between primitive types (such as int) and wrapper types (such as Integer). Refer to JSR 201 .
I say, boo! Primitive types -- value types -- should be able to have methods called on them directly without worrying about a reference type wrapper. Boxing wastes memory and ticks.
The enumeration addition copies exactly the way enums function in C#. :P
I like the moves that Java is making, though. It's almost becoming useful. :P
I've been familiarizing myself with the new features since the beta pre-releases of it but even with final versions out i never end up making much use of the new API until its integrated in the products I use with it. Like WebLogic.
Quote from: Myndfyre on May 18, 2004, 07:40 PM
Looking through the spec, I see:
Quote
Autoboxing/Unboxing
This facility eliminates the drudgery of manual conversion between primitive types (such as int) and wrapper types (such as Integer). Refer to JSR 201 .
I say, boo! Primitive types -- value types -- should be able to have methods called on them directly without worrying about a reference type wrapper. Boxing wastes memory and ticks.
The enumeration addition copies exactly the way enums function in C#. :P
I like the moves that Java is making, though. It's almost becoming useful. :P
Good thing your opinion doesn't matter. :P JK
java is way too verbose imo. it's getting better with 1.5, but still not enough.
I believe that 1.5 is still beta.
Quote from: St0rm.iD on May 19, 2004, 02:09 PM
java is way too verbose imo. it's getting better with 1.5, but still not enough.
I now understand why you disdain VB. As I have been working on an extremely simple sample VB .NET bot using my API, I have discovered that it uses a lot to say a little.
What I say in VB .NET:
For i As Integer = 0 to someArray.Length Step 2
' blah
Next
I can do in C#:
for (int i = 0; i < someArray.Length; i+=2) {
}
Even better are function declarations, with attributes:
C#:
[STAThread()]
public static int Main(string[] args) {
}
Note the line-continuation marker after the attribute declaration (I don't know why they decided on that, but it's gay).
VB:
<System.STAThread()>_
Public Shared Function Main(ByVal args() As String) As Integer
End Function
Eck.
Anyway, off-topic, of course. This all gets around to -- why is it you think Java is verbose? I would tend to disagree -- in fact, I think it's relatively concise.
Quote from: Myndfyre on May 19, 2004, 07:16 PM
Anyway, off-topic, of course. This all gets around to -- why is it you think Java is verbose? I would tend to disagree -- in fact, I think it's relatively concise.
I agree with you about it being concise, but when compared to languages like Python, and Scheme which storm talks about it does require a lot more typing.
After much exploration into other languages, I've decided operator overloading is a must. Makes things so much easier and concise.
Plus, Java is a dynamic language in a static world. It needs eval()!
Quote from: St0rm.iD on May 19, 2004, 08:17 PM
After much exploration into other languages, I've decided operator overloading is a must. Makes things so much easier and concise.
Plus, Java is a dynamic language in a static world. It needs eval()!
I would like to see operator overloading, but I don't mind the dynamic nature of Java. Besides, I could just write my own eval() method.
Quote from: St0rm.iD on May 19, 2004, 08:17 PM
After much exploration into other languages, I've decided operator overloading is a must. Makes things so much easier and concise.
Plus, Java is a dynamic language in a static world. It needs eval()!
I agree, I like operator overloading in C#. :)
I remember when I first started programming in C# (I stepped up from Javascript). I referenced the JScript .NET assemblies in my project, just so I could use the eval() function. Now I say, "run away! run away!"
Quote from: DaRk-FeAnOr on May 19, 2004, 07:14 PM
I believe that 1.5 is still beta.
yeah... you can download here: http://java.sun.com/j2se/1.5.0/download.jsp
and... api specs here: http://java.sun.com/j2se/1.5.0/docs/api/index.html
I disagree - I *hate* operator overloading. It makes things happen that shouldn't happen which just confuses things.
std::string a ="123test" + 3;
That should make a point to the character array "test", and it's impossible to figure out what's going on without the documentation because of the two overloads (= and +).
But you can't do syntactically beautiful things in Java!
Quote from: iago[yL] on May 20, 2004, 07:16 AM
I disagree - I *hate* operator overloading. It makes things happen that shouldn't happen which just confuses things.
std::string a ="123test" + 3;
That should make a point to the character array "test", and it's impossible to figure out what's going on without the documentation because of the two overloads (= and +).
Operator overloading can be handy as long as you know exactly what is going on.
One of the nice things about it is that you can have template functions that work (without code changes) for both primitive and user-defined types.
Quote from: Skywing on May 23, 2004, 10:32 PM
Operator overloading can be handy as long as you know exactly what is going on.
If you could always know what's going on it might not be so bad, but, especially when using a class you didn't write, you might not be able to tell when you're using an overloaded operator or now.
Quote from: iago[yL] on May 24, 2004, 03:12 AM
Quote from: Skywing on May 23, 2004, 10:32 PM
Operator overloading can be handy as long as you know exactly what is going on.
If you could always know what's going on it might not be so bad, but, especially when using a class you didn't write, you might not be able to tell when you're using an overloaded operator or now.
That's what documentation is for. You can't really tell exactly what a particular function call does without documentation, either.
Besides, STL is very well documented...
Quote from: Skywing on May 24, 2004, 09:42 AM
Quote from: iago[yL] on May 24, 2004, 03:12 AM
Quote from: Skywing on May 23, 2004, 10:32 PM
Operator overloading can be handy as long as you know exactly what is going on.
If you could always know what's going on it might not be so bad, but, especially when using a class you didn't write, you might not be able to tell when you're using an overloaded operator or now.
That's what documentation is for. You can't really tell exactly what a particular function call does without documentation, either.
Besides, STL is very well documented...
But if you see a function like "dosomething(a)", you'll always know that a function is being called, but if you see "a = 17" you might not be able to tell that it's calling an overloaded function.
I just think that code clarity is lost when you overload operators..
When I was a Java programmer, I said that too.
Quote from: iago on May 24, 2004, 11:14 AM
I just think that code clarity is lost when you overload operators..
Code clarity can be gained or lost. Many things look much clearer when you can use overloaded operators. Large number classes is an excellent example of that.
bignum a, b, c;
a.assign(4);
b.assign(1);
c.assign(a.multiply(b));
vs
bignum a, b, c;
a = 4;
b = 1;
c = a * b;
Overloaded assignment operator and overloaded multiplication operator makes a lot of sense.
Things get confusing when you overload the dereferencing operator though.
How often do you see that? I think the std::iterator class and derivatives do an excellent job of overloading it sensibly.
I see the dereferencing operator overloaded for smart pointers, collections and similars. In most cases the meaning of the operator stays the same, but the operator can be a applied to a new data type.
If you know the data types of the variables in the expression, you'll then know that you're looking at an overloaded operator. If it wasn't an overloaded operator, it would be a compile error.
Quote from: Adron on May 28, 2004, 06:38 PM
Quote from: iago on May 24, 2004, 11:14 AM
I just think that code clarity is lost when you overload operators..
Code clarity can be gained or lost. Many things look much clearer when you can use overloaded operators. Large number classes is an excellent example of that.
bignum a, b, c;
a.assign(4);
b.assign(1);
c.assign(a.multiply(b));
vs
bignum a, b, c;
a = 4;
b = 1;
c = a * b;
Overloaded assignment operator and overloaded multiplication operator makes a lot of sense.
I don't like that -- you don't know what's going on. I don't like the extra layer of abstraction (says the Java user).
Quote from: iago on May 29, 2004, 01:40 PM
Quote from: Adron on May 28, 2004, 06:38 PM
Quote from: iago on May 24, 2004, 11:14 AM
I just think that code clarity is lost when you overload operators..
Code clarity can be gained or lost. Many things look much clearer when you can use overloaded operators. Large number classes is an excellent example of that.
bignum a, b, c;
a.assign(4);
b.assign(1);
c.assign(a.multiply(b));
vs
bignum a, b, c;
a = 4;
b = 1;
c = a * b;
Overloaded assignment operator and overloaded multiplication operator makes a lot of sense.
I don't like that -- you don't know what's going on. I don't like the extra layer of abstraction (says the Java user).
You don't like that? How can you not like a statement that clearly says that c is set to a times b, vs a complex one with a whole lot of function calls?
In Java, I would do this:
import java.util.BigInteger;
...
BigInteger a = new BigInteger(4);
BigInteger b = new BigInteger(1);
c = a.multiply(b);
I personally prefer that over your operator overloading.
Then you would like Scheme/Lisp:
(* 5 (+ 2 3))
Quote from: iago on May 29, 2004, 02:40 PM
In Java, I would do this:
import java.util.BigInteger;
...
BigInteger a = new BigInteger(4);
BigInteger b = new BigInteger(1);
c = a.multiply(b);
I personally prefer that over your operator overloading.
Some of us prefer the overloaded version, but the great thing is that you could do support both and simply have the operators call the named member functions, or vice versa.
Quote from: iago on May 29, 2004, 02:40 PM
In Java, I would do this:
import java.util.BigInteger;
...
BigInteger a = new BigInteger(4);
BigInteger b = new BigInteger(1);
c = a.multiply(b);
I personally prefer that over your operator overloading.
If you really like things being extra-verbose, you could always do c.operator=(a.operator*(b));
I hate typing for no reason.
Quote from: Skywing on May 30, 2004, 06:13 PM
Quote from: iago on May 29, 2004, 02:40 PM
In Java, I would do this:
import java.util.BigInteger;
...
BigInteger a = new BigInteger(4);
BigInteger b = new BigInteger(1);
c = a.multiply(b);
I personally prefer that over your operator overloading.
If you really like things being extra-verbose, you could always do c.operator=(a.operator*(b));
That just looks ugly..
Quote from: iago on May 30, 2004, 08:27 PM
Quote from: Skywing on May 30, 2004, 06:13 PM
Quote from: iago on May 29, 2004, 02:40 PM
In Java, I would do this:
import java.util.BigInteger;
...
BigInteger a = new BigInteger(4);
BigInteger b = new BigInteger(1);
c = a.multiply(b);
I personally prefer that over your operator overloading.
If you really like things being extra-verbose, you could always do c.operator=(a.operator*(b));
That just looks ugly..
Well, you could settle for c = a.operator*(b); which looks rather close to your java version.
Is the = operator overloaded in java? Or does it always do some particular thing? (i.e. member-wise assignment, pointer assignment, something like that)
And I still don't understand
why you prefer function names over operators. It seems a little strange that you'd want to know exactly what happens, but at the same time you're programming in a language that is farther away from the hardware than C++ is. Is this based on bad experiences with someone using the operators to do non-intuitive things?
I was beaten with overloaded operators as a child :'(
But seriously, it's because I like code clarity, and I don't htink operators provide that.
And = in Java is always the same -- assignment. If it's a primitive type, it assigns the value to the variable, and if it's a pointer (ie, an object) it assigns the pointer to the variable.
One of the reasons I like Java is simply for code clarity -- unless you're a crappy programmer, code in Java is very clean and readable. For example, compare this C++ code:
ebp = *(DWORD *)((BYTE *)(Copy+3) - ((esi >> 5) << 2));To the equivolant Java code (as best as I could write it):
Quoteint location = 12 - ((esi >>> 5) << 2);
ebp = IntFromByteArray.LITTLEENDIAN.getInteger(Copy, location);
I rather prefer the more verbose, but clearer code in Java.
Quote from: iago on May 31, 2004, 12:39 PM
I was beaten with overloaded operators as a child :'(
But seriously, it's because I like code clarity, and I don't htink operators provide that.
And = in Java is always the same -- assignment. If it's a primitive type, it assigns the value to the variable, and if it's a pointer (ie, an object) it assigns the pointer to the variable.
One of the reasons I like Java is simply for code clarity -- unless you're a crappy programmer, code in Java is very clean and readable. For example, compare this C++ code:
ebp = *(DWORD *)((BYTE *)(Copy+3) - ((esi >> 5) << 2));
To the equivolant Java code (as best as I could write it):
Quoteint location = 12 - ((esi >>> 5) << 2);
ebp = IntFromByteArray.LITTLEENDIAN.getInteger(Copy, location);
I rather prefer the more verbose, but clearer code in Java.
I prefer the less verbose but clearer C++ code:
ebp = Copy[3 - esi / 32];
(assuming Copy has been properly declared as a pointer to DWORD or int or whatever you're pointing at)
I suppose it really does become a matter of opinion. I find it much easier to abstract away as much detail as possible, and only keep the important things. The less code I have to look at, the better.
int location = 12 - ((esi >>> 5) << 2);
ebp = Copy[location];
Quote from: impersonating members is bad! on May 31, 2004, 02:22 PM
int location = 12 - ((esi >>> 5) << 2);
ebp = Copy[location];
That won't work because of different pointer sizes.