How to emluate "properties" in Java?
in [Java Programming]
|
From: markspace on 25 Feb 2010 20:57 Peter Duniho wrote: > That said, if all this were was about syntactic sugar and naming > conventions, I'd agree. Properties wouldn't add much, if anything, over > simply having a naming convention in Java. This much I agree with. Even if Java were to add some sort of first class property support, I'd still like to see them keep the set/get naming convention. It's familiar to Java programmers, at least, and as mentioned it doesn't really save anything. I find it very readable. > Note, however that that's not really the case. Using .NET as the > example again, properties are full-fledged class members uniquely > different from other kinds of members. This enables, for example, a > more robust data binding model, where you can specify the name of the > property and be assured that you are really getting a property, rather I'm not familiar with .net forms or WPF. Could you give an example where this matters? What if a "property" doesn't correspond to an actual field? How would you incorporate that into this robust data binding?
From: Arne Vajhøj on 25 Feb 2010 21:33 On 25-02-2010 20:15, Peter Duniho wrote: > Joshua Cranmer wrote: >> Right now, in Java, "a.b = 5" is always going to set a field in the >> object A to 5. If you had properties, the same syntax could also mean >> to call a function with an argument of 5, which may or may not set a >> field to 5. It could also just decide to sneer in your face for the >> heck of it. >> >> Let's compare: >> a.b = 5; >> a.setB(5); > > How does the second line of code in any way tell you what the method is > doing? If anything, a property carries with it a strongly implication > that the _object_ itself will be modified. A method named "setB()" could > do anything. They have the same abilities and they causes the same expectations. > Granted, in Java we have the convention that a method named "setX" is > going to set some property-like state in the object. But then you're > just back to the whole property thing. Yes. We are back to the problem that a property is adding a new syntax feature, but is still relying on a convention just like getters and setters. more syntax + same problems = bad solution > That said, if all this were was about syntactic sugar and naming > conventions, I'd agree. Properties wouldn't add much, if anything, over > simply having a naming convention in Java. > > Note, however that that's not really the case. Using .NET as the example > again, properties are full-fledged class members uniquely different from > other kinds of members. This enables, for example, a more robust data > binding model, where you can specify the name of the property and be > assured that you are really getting a property, rather than just a > method that happens to look like the method that would exist had that > property actually been present. > > Going the other direction, it enables in GUI designers (don't even get > me started at the vast gulf between designers for .NET Forms and WPF > applications, as compared to those available in Java) the ability to > confidently display property values to be initialized as part of a > designed object, again without worrying about whether something is > displayed because it just happened to look like a property when it > wasn't, or failing to display something because it's still basically a > property but for some reason someone failed to follow the correct naming > convention. Have you ever heard of a problem being caused by that? Arne
From: Peter Duniho on 26 Feb 2010 01:22 markspace wrote: > [...] >> Note, however that that's not really the case. Using .NET as the >> example again, properties are full-fledged class members uniquely >> different from other kinds of members. This enables, for example, a >> more robust data binding model, where you can specify the name of the >> property and be assured that you are really getting a property, rather > > I'm not familiar with .net forms or WPF. Could you give an example > where this matters? I'm not entirely sure I understand the question. But, for example, consider method names like "setTable()" or "setBrake()", where "table" actually refers to an actual tabletop (or a data structure modeling one), or "brake" refers to the brake of some vehicle. Or maybe you've got methods like "getBetter()" (modeling an illness) or "getShorty()" (a hit-man). The bottom line is that the words "get" and "set" are not restricted to the use of things that actually behave like properties, and while it's well and good to say that one can be disciplined oneself about usage, the fact is that not all programmers are like that. In fact, I'd say that anyone reading, never mind participating in, this discussion is far from being a typical programmer. That group of people is far more interested in the philosophy and mechanics of programming than your average programmer, the latter being someone who is just happy to have a job and have someone pay them to sit at a computer and wrestle with getting the code to do what someone's specification says it should. Languages work better when they take that latter type of programmer into account. > What if a "property" doesn't correspond to an actual field? How would > you incorporate that into this robust data binding? Just as in Java, a property in a language like C# has no need to correspond to an actual field. The data binding mechanisms always go through the getter and setter methods, and what's behind those methods is completely irrelevant. You can do the exact same kind of data binding in Java. It's not like because Java lacks true properties in the language, that it is somehow constrained in what it can accomplish. The only practical difference is the extra layer of abstraction that would give the language a bit more usability and usage-safety. But, that's the main point of a high-level programming language: to abstract concepts to make them more accessible and usable. Just as a language like Java abstracts the concept of an object reference as compared to pointers in C, so too does a language like C# abstract the concept of an object property as compared to explicit getter and setter methods in Java. This abstraction is a _good_ thing. Note that my main disagreement is with the assertion that extra verbosity is a good thing. Verbosity gets in the way of understanding the intent behind code, as opposed to the mechanism behind code. But more than that, if verbosity is such a good thing, why aren't we required just to type in the same code twice? I mean, I visit web sites that require me to type my new password in twice, to ensure that I've actually typed something known to be what I really meant. Just think of how many typographical errors could be eliminated from code if we simply required the programmer to type (not copy/paste, and without being able to see the previously typed line) every line of code twice. I mean, those kinds of errors don't come up often, but they could be almost completely eliminated by adding enough verbosity to the code to catch them. No, that's a terrible idea. Instead, it makes more sense to reduce verbosity as a way of enhancing programmer efficiency and effectiveness, and then rely on other tools to provide for correctness. In fact, I'd argue that the _less_ you make the programmer type in, the more likely it is they can express their intent correctly without making a mistake. Programming languages aren't like human languages, as Joshua's post seems to imply. It's not like the compiler will be able to figure out from the redundancy what you really meant if you type in 50% more stuff, the way that humans can communicate better by adding redundancy. Instead, the goal should be to make it simpler and faster for the programmer to express their _intent_, minimizing the opportunity for mistakes by minimizing the amount of input required by the programmer, but doing so in a well-designed, highly expressive way (i.e. _not_ by following the example of APL). Pete
From: Peter Duniho on 26 Feb 2010 01:23 Arne Vajh�j wrote: > [...] >>> Let's compare: >>> a.b = 5; >>> a.setB(5); >> >> How does the second line of code in any way tell you what the method is >> doing? If anything, a property carries with it a strongly implication >> that the _object_ itself will be modified. A method named "setB()" could >> do anything. > > They have the same abilities and they causes the same expectations. Except that a method named "setB()" isn't required to be a property. It can't possible have the same expectations, because it's not defined as rigidly in the language. In fact, there's not even a guarantee that the word "set" is being used as a verb. You're entirely reliant on the programmer defining the method to have followed the specific convention you're expecting. That may or may not be the case. >> Granted, in Java we have the convention that a method named "setX" is >> going to set some property-like state in the object. But then you're >> just back to the whole property thing. > > Yes. > > We are back to the problem that a property is adding a new > syntax feature, but is still relying on a convention just like > getters and setters. > > more syntax + same problems = bad solution That's ridiculous. A language-supported property doesn't have the all "same problems". It's true that a property setter can be as poorly behaved as a random method named "setB()". But the point is, it takes more that just carelessness to wind up with a poorly behaved property, whereas simple carelessness can result in a poorly behaved method that just happens to look like a property. Just because some problem is shared doesn't mean _all_ the problems are shared. > [...] >> Going the other direction, it enables in GUI designers (don't even get >> me started at the vast gulf between designers for .NET Forms and WPF >> applications, as compared to those available in Java) the ability to >> confidently display property values to be initialized as part of a >> designed object, again without worrying about whether something is >> displayed because it just happened to look like a property when it >> wasn't, or failing to display something because it's still basically a >> property but for some reason someone failed to follow the correct naming >> convention. > > Have you ever heard of a problem being caused by that? Caused by what? Are you talking about my example of use of properties in designers? If so, that's kind of a silly question, because good support for properties has been correlated with good designers, and poor support for properties has been correlated with bad or non-existent designers. But sure, I've seen plenty of code that _would_ have failed the designer test, had it been written in the context of a good designer. Especially things that are property-like but not following the proper convention for properties, but also occasionally a method named like a property might be named, but which turned out to not really represent a property of the object used to call the method. It happens. Pete
From: Wojtek on 26 Feb 2010 11:10
Peter Duniho wrote : >> Right now, in Java, "a.b = 5" is always going to set a field in the object >> A to 5. If you had properties, the same syntax could also mean to call a >> function with an argument of 5, which may or may not set a field to 5. It >> could also just decide to sneer in your face for the heck of it. >> >> Let's compare: >> a.b = 5; >> a.setB(5); > > How does the second line of code in any way tell you what the method is > doing? If anything, a property carries with it a strongly implication that > the _object_ itself will be modified. A method named "setB()" could do > anything. And if Java had properties, an implied function (um, method) would be called which: "could also just decide to sneer in your face for the heck of it." The difference is that a.b=5 WILL set b to 5, whereas having properties it may or may not. Exactly as a setB() could do. I do not like implied actions (and I really do not like operator over-loading). By contract setB() will eventually set b to 5, though it may do some other processing along the way. And that is just fine, as the class has the right (and responsibility) to make sure that the 5 is a valid value. It may also decide to add 5 to some other internal field which is hidden from view. Consider: a.setName("Wojtek"); A.setName(String theName) { this.theName = theName; } The class is distributed, then users complain that the values sort funny. Investigation shows that a sort value is never set by some end programmers (silly people). So now you can send out a strongly worded letter to all the programmers using your class, OR: A.setName(String theName) { if(getSort().length()==0) setSort(theName); this.theName = theName; } The class ensures that if a name is set, and a sort value has not already been set, that there will be a sort value. You send out an update and the issue is fixed. Using a.theName="Wojtek" would completely prevent you from issuing a fix and you would need to rely on the goodness of the end programmer to use your class "properly". And if the sort is case insensitive: A.setSort(String sortValue) { this.sortValue = sortValue.toLower(sortValue); } No. I greatly prefer using get/set for ALL changes to class properties. -- Wojtek :-) |