131–140 of 228 posts
The lack of an official JSON API has been a huge sore point for quite some time and has spawned dozens of libraries re-implementing the same thing over and over (GSON, Jackson, and even my own nanojson). I do hope that we avoid the DocumentBuilderFactory mistakes of XML and just end up with One True JSON implementation this time.
Earlier quoted context omitted.
Why does it matter if it's binary compatible? How does that affect the programmer? I guess I don't understand the difference/significance between binary and source compatibility? I'm surprised to hear that it's not reflection compatible. As a Java programmer, I assumed that was the main point of C# properties: Create a property now because there's no logic needed, but if you need logic in the future you can change th…
> As a Java programmer, I assumed that was the main point of C# properties: Create a property now because there's no logic needed, but if you need logic in the future you can change the code and nobody outside needs to be aware of the change. That's the point, but its not directed at reflection, and reflection goes around behind the scenes of the superficial access-notation compatibility. Which does make properties a…
Consistency of access in Java is also really problematic for the same reason. Which pair of getter/setter methods represents a reified property? This is often done by naming convention, that's usually, but not always consistent (getFoo/setFoo is common, but there's also isFoo/setFoo, isFoo/setIsFoo, foo()/foo(value), etc.). Worse (and this is something both Android's flavor of Java SDK and Objective-C have fallen prey to), not all properties are written symmetrically (e.g. getText() and the various setText() methods on an EditText in Android, although there are some where all of the setters are subclasses of the only getter -- even worse).
Earlier quoted context omitted.
It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…
I disagree. A fundamental, language-level problem with Java is that clients need to know when they are accessing a member var, e.g. obj.foo, vs. calling a method, e.g. obj.foo(). This means that its much safer to always wrap things in a method, because if you ever need to change something (or do things like add logging, delegation, or some other filtering behavior), you can do it behind your method without clients ne…
Earlier quoted context omitted.
Not really. http://zeroturnaround.com/blog/goodbye-liverebel/
Oh, damn! I just started using jrebel.. (I know I asked what hotswapping was but I was curious if the OP meant hotswapping in the same way as jrebel or something else) edit: Wait, that is liverebel, not jrebel
a new json api to be released 2016. Hopefully by that time json is still relevant. I know most likely it will but at the pace of change that tech has, im not betting. is there any contender to json at the moment?
Earlier quoted context omitted.
It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…
I disagree. A fundamental, language-level problem with Java is that clients need to know when they are accessing a member var, e.g. obj.foo, vs. calling a method, e.g. obj.foo(). This means that its much safer to always wrap things in a method, because if you ever need to change something (or do things like add logging, delegation, or some other filtering behavior), you can do it behind your method without clients ne…
Others have noted that in many contexts in C# there is a difference, so clients do need to know.
As far as Ruby, clients definitely need to know, its just that since public fields can't happen in Ruby, its always method-based access for the normal cases.
Both of these lines are always calling a method on "obj" in Ruby:
foo = obj.a # equivalent to foo = obj.a()
obj.a = foo # equivalent to obj.a=(foo)
foo = obj.instance_variable_get :@a
obj.instance_variable_set :@a, foo
foo = obj.instance_eval { @a }
obj.instance_exec { @a = foo }
Earlier quoted context omitted.
I agree and I hate getters, but I am one of those who still hasn't figure out how to do OOP correctly. Do you have an example or maybe some suggested reading? For example, if I have a user object, with name, age, number, how would that work without get/set? I'd love to avoid it, I hate the bloat it creates, and also how frivolous it seems to test get/set.
Well, the answer depends on the function, the purpose. I suppose he's saying that you should encapsulate with the object. For example, you have an OrderLine object, you don't `o.setStatus(CANCELLED)`, you `o.cancel()` etc.
Earlier quoted context omitted.
This only works well if we get named parameters, too (and maybe defaults). It is too easy to make mistakes with lots of subsequent constructor arguments of the same type.
We already have that, it's called the Builder pattern.
For example, with protocol buffers you end up doing things like.
AlbumCollection collection = user.getPreferences().getFavorites().getAlbums().toBuilder().addAlbum(album).build();
Favorites favorites = user.getPrefernces().getFavorties().toBuilder().setAlbumCollection(collection).build();
Preferences preferences = user.getPreferences().toBuilder().setFavorites(favorites).build();
and then you have to work your way up the chain of builders. Such a pain in the ass for something that could be much simpler with getters and setters.
Earlier quoted context omitted.
It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…
Anyone know what the "sjavac" is about? The link just talks about improving it so it can become the new default... but what is better about it? Is it just the new javac?(why not just in-place upgrade javac then?) (link provides no real details: http://openjdk.java.net/jeps/199 )
Earlier quoted context omitted.
The other "Missing feature" is null safe ".". Other languages have it, but I don't know what the technical name is... basically: Integer val = some.other.chain.of.objects.value; In Java, this code has a huge potential for NullPointerExceptions. Instead a new operator (yes, I know) like: Integer val = some.?other.?chain.?of.?objects.?value; If any of the intermediate objects are null, the whole assignment becomes null…
Groovy does this, although frustratingly not with array accesses last I checked.
I never did fill out a GEP but you could try your luck by subbing one, see http://docs.codehaus.org/display/GroovyJSR/Groovy+Enhancemen...