Either using public fields or simple getters and setters, it's not encapsulating anything! Most people use beans as simple containers of data, why not to make all fields public? What do you think you are "encapsulating" by making a get/set?

Getters and Setters are needed in many cases.Why?-for validity checks-for property change notifications-to add a layer of protection so you can keep the same interface (contract?) but change the implementation as needed

I'm generally against the buzz around adding "true" properties to the Java language... I just don't see the problem with the way things are now. writing getters and setters coudl be tedious - if anyone still does that by hand... IDEs generally do it for you, and then of course you fill in the extra bits that a built-in property feature can't handle anyway (e.g. range/security checks, logging, etc.).

Making everything public may let you patch a library.. but then it cripples the library author's ability to make changes that don't break your code.

BTW for #4 in Cas' original list.. Did anyone catch the recent library mentioned on java.net https://nlink.dev.java.net/. It looks very interesting to me.

I'm starting to think that MS made a really good decision to separate out the bytecode / CLR section of .Net from the actual language specifications (eg. C#). That way everyone can go off and make their own crazy modifications to the actual languages without forcing them down everyones throat. You could have Java++ with operator overloading, proper const, null checking at compile time, etc. At the moment we get a half-way version of this where people stick with a particular Java version instead.

I'm starting to think that MS made a really good decision to separate out the bytecode / CLR section of .Net from the actual language specifications (eg. C#). That way everyone can go off and make their own crazy modifications to the actual languages without forcing them down everyones throat. You could have Java++ with operator overloading, proper const, null checking at compile time, etc. At the moment we get a half-way version of this where people stick with a particular Java version instead.

Well why can't Java syntax be made that allows you to silently intercept direct variable accesses and pass them through a setter/getter. Then we get the best of both worlds.

Not really... then you get mysterious side effects when you thought you were doing a simple assignment. Also, how would you implement the setter without making it infinitely recursive? :-)

Getters and setters are part of a pattern that is so well recognised that it is natural for Java programmers. Changing that isn't really helping anyone. IDEs do most of the typing for you,so saving a few keystrokes is almost 100% irrelevant. It also is a great feature to be able to type myVar.set<ctrl-space> and get a pop-up list of all the things that I'm allowed to set on that class. What happens to that awesome auto-documentation showing super timesaver when suddenly I'm forced to wade through everything because there are no setters anymore?

Nobody commented on NLink. I thought it was a really great way to do JNI and I think there would be a much greater pay-off if something like it, or better, was integrated into Java to improve the whole JNI experience.

You don't get what I am saying, nor the cool thing about C# properties.

In JAVA you have to create a get and set to encapsulate your data. A class that provides a get does not have to just pass back a reference. It could generate an object on the fly etc. Or when a set is called you could notify listeners the state has changed. In java if you make all your fields public (which I often do becuase I am lazy), you can never encapsulate the state of those objects at a later date.

However, in C# you can be lazy i.e. Create public variables initially. When your design has evoleved and you need to either refactor out the variable or replace the storage mechanism or add an event model or whatever, you simply replace the variable with a property. Properties look syntactically exactly the same as variables. So no source code outside needs to be changed (becuase of the strong form of auto-boxing C# implements), however you can write a specialized set and get for it, it does not even need to delagate to a variable for storage of anything. They are just like mini classes, so your design can evolve unhindered.

This is exactly what encapsulation is about, hiding your internals, so it doesn't matter how you actually carry out requests. C# allows you to do this at essentially the variable assignment and retrieval level, where as java can only do it at a method invocation level.

Wait a minute, you are NOT encapsulating anything by adding a getter/setter. Getters/setters don't give you magically "encapsulation" by their mere existence alone. How can you be hiding something and providing a getter/setter at the same time? Is this a quantum computer? This is like saying the bit is 0 and 1 at the same time, you are going down and up the stairs at the same time, you are in and out of the house at the same time!

If you want to do validation then a method is the ideal place for it, since it will perform some logic. Besides, with properties the developer can't tell if that is a public field or a private one, it means, he won't be able to understand the code just by looking at it, because it might call a method or not.

This is just overloading the meaning of the operator '=', the same problems of not being to tell what is going on will happen. Operator overloading? That's how it should be called.

And I think the compiler will have a hard time getting the same performance out of something like this instead of primitives. I feel lots of object overhead coming our way, String-like constant pools, more strain on the GC and other things I don't want.My opinion is that I'm doing enough number crunching that I want my calculations to be:a) readableb) fast, with guaranteed no object overhead whatsoever (I'm not sure a compiler would be able to get rid of that overhead in all cases).

And again, what do you gain by having primitives as Objects? If it's collections and such, there's already autoboxing there (which introduced a couple of new performance pitfalls).Math, numbers etc are such a well defined concept that I personally don't see any benefit in having them represented as objects.

Your counter example still appears to have primitives (the arguements for the constructors).In terms of consistency the analogy would be String :

1

Strings = "blah";

Quote

And which problem does this solve?

Two I think. #1 if I write a bit of number crunching code, and I don't care whether the parameters are floats or doubles (or in fact ints or longs), I can define those parameters to be the Number class. I can then write readable math code using +*/-. The compiler could under-the-hood turn stuff into primitives to make it just as fast.I imagine there is lots of game code out there that has primitive types in their signatures, changing from say float to double could be very painful but this way it wouldn't.Taking it further you could define interfaces such as Addable, Divisible etc.. so more complex objects such as Vectors could participate. Where this descends into operator overloading I'm not sure.

#2 Methods that take any input, currently have to have a version for Object plus all the primitive types. e.g JUnits assertEquals, could be condensed from 20 to 2 methods.

Quote

And I think the compiler will have a hard time getting the same performance out of something like this instead of primitives.

My idea is that the compiler would be more clever and be able to convert to primitives where necessary. However I don't write compilers so I don't know if this is feasible.

You are aware, that the above compiles fine with 1.5, are you? The only difference is, that the second line is not equivalent to five.multiplyBy(2) but to Integer ten= new Integer(5*2), but since you can even write

#1 if I write a bit of number crunching code, and I don't care whether the parameters are floats or doubles (or in fact ints or longs), I can define those parameters to be the Number class. I can then write readable math code using +*/-. The compiler could under-the-hood turn stuff into primitives to make it just as fast.I imagine there is lots of game code out there that has primitive types in their signatures, changing from say float to double could be very painful but this way it wouldn't.Taking it further you could define interfaces such as Addable, Divisible etc.. so more complex objects such as Vectors could participate. Where this descends into operator overloading I'm not sure.

#2 Methods that take any input, currently have to have a version for Object plus all the primitive types. e.g JUnits assertEquals, could be condensed from 20 to 2 methods.

My idea is that the compiler would be more clever and be able to convert to primitives where necessary. However I don't write compilers so I don't know if this is feasible.

Most games do a load of maths with say floats. The code doesn't really care it's using floats - it would look the same if it were crunching doubles. Therefore if you could write your methods using a higher level abstraction, e.g. Number it would work for both floats and doubles. Therefore if you decide to change your game to use doubles instead of vice-versa, it is much easier. Also library code written this way could be used for games that uses doubles or floats - it is more reusable.Of course to do this, you need to not use primitives as they are not polymorphic.

While this is true for java's type system as it is, it is not necessarily true in general. There are strong type systems where you don't have to decide whether you're using floats or ints in an expression, this is inferred by the compiler automatically. Some functional languages like Haskell have this feature and it works great (in most situations). This feature is called type classes which has nothing to do with OO-classes.

For example 34 + 4 * 2 would have a type (Num a) => a, which tells us that it gives us a polymorphic type a (any type a), wich is in the 'Num' class. Had I used a 'floating point' somewhere, e.g. 34 + 4 * 2.2, the type would've been (Num a, Fractional a) => a. Note that Fractional also implies Num, so one can leave out the 'Num' class.

You might be right for #2 ("Methods that take any input, currently have to have a version for Object plus all the primitive types. e.g JUnits assertEquals, could be condensed from 20 to 2 methods"). I don't understand what exactly he wants to have here, so it would be hard to judge wether it would be possible with a strong type system.

I want this class to work for int, floats, doubles, BigIntegers, bytes etc... So if my range is an int range (min and max are ints) then size returns an int, if my range is a double range, then size returns a double. How do I implement the size method?The ways I can see are ugly - mutliple implementations of the size method either as subclasses or a big if statement - yuck.This is not an isolated problem, check out Rectangle, Rectangle2D.Double,and Rectangle2D.Float and Point, Point2D.Double and Point2D.Float.

I want this class to work for int, floats, doubles, BigIntegers, bytes etc... So if my range is an int range (min and max are ints) then size returns an int, if my range is a double range, then size returns a double. How do I implement the size method?The ways I can see are ugly - mutliple implementations of the size method either as subclasses or a big if statement - yuck.This is not an isolated problem, check out Rectangle, Rectangle2D.Double,and Rectangle2D.Float and Point, Point2D.Double and Point2D.Float.

You'd think that would work, wouldn't you - shame autoboxing was implemented as a hacky after-thought.The '-' operator is defined for all of the Number classes sub-classes, but not for the Number class itself, hence it doesn't compile.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org