How to emluate "properties" in Java?
in [Java Programming]
|
From: markspace on 26 Feb 2010 11:50 Peter Duniho wrote: > 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. What I mean is, given the methods setTable() or setBrake(), what constitutes "more robust data binding" (your words from above) and how does this make a difference in programming? So far you've only really given examples were C# is the exactly same as Java, except for one point of syntactic sugar. The ability to type = instead of "set" doesn't strike me as any sort of useful data binding at all, let alone "more robust." Is there more that I'm missing? > Just as in Java, a property in a language like C# has no need to > correspond to an actual field. So if I declare some class in C# class C# { setN( int n ) { ... do anything I want ... } } Then I invoke that method on an instance like this instance.N = 42; that's no different from calling the method name? And that's all that this "data binding" provides me? If so then I truly don't see the usefulness. It's not worth the extra effort on the part of the compiler to bother in my opinion, and I can see why folks wouldn't want this ported over to Java. > But, that's the main point of a high-level programming language: to > abstract concepts to make them more accessible and usable. See, I don't see this as "abstraction." What I've described is literally just syntactic sugar, the mere substitution of one phrase for another. And it doesn't save a lot of characters, either, so I can't really say that I'd consider this feature useful. I was hoping to discover some interesting facts of C# and language design, but so far I'm disappointed. Just to lead the discussion a bit, what does a C# class with these sorts of methods look like under reflection? Do properties appear differently than just method names?
From: Peter Duniho on 26 Feb 2010 12:32 markspace wrote: > [...] > So if I declare some class in C# > > class C# { > setN( int n ) { > ... do anything I want ... > } > } > > Then I invoke that method on an instance like this > > instance.N = 42; You can't do that in C#. You have to do this: class Test { public int N { get; set; } } Or this: class Test { private int n; public int N { get { return n; } set { n = value; } } } (In the former case, the compiler automatically generates a backing field for you and uses it) Note that either the getter or setter can also have explicitly less accessibility from the main property, if declared that way. And of course, the getter and setter both are full-blown methods; they can do whatever you want. They aren't even required to have a backing field, if it makes sense for the property to do something else. > that's no different from calling the method name? And that's all that > this "data binding" provides me? If so then I truly don't see the > usefulness. It's not worth the extra effort on the part of the compiler > to bother in my opinion, and I can see why folks wouldn't want this > ported over to Java. I don't know whether correcting your mistaken impression about what properties in C# actually are will help. But hopefully you understand now, that they aren't just "syntactic sugar". As I already explained earlier, they are full-blown language constructs that, even after compilation, are treated differently from plain methods. >> But, that's the main point of a high-level programming language: to >> abstract concepts to make them more accessible and usable. > > > See, I don't see this as "abstraction." What I've described is > literally just syntactic sugar, the mere substitution of one phrase for > another. And it doesn't save a lot of characters, either, so I can't > really say that I'd consider this feature useful. [...] Honestly, it seems to me that you ought to learn the language and actually understand the feature before you dismiss it out of hand. Pete
From: Lew on 26 Feb 2010 22:08 Peter Duniho wrote: > Honestly, it seems to me that you ought to learn the language and > actually understand the feature before you dismiss it out of hand. How do you consider what he's doing dismissing it out of hand? He's asked you what he doesn't understand so that he can grok the value. If he dismissed it out of hand, he'd've not asked what he's missing. Telling him he has to learn the whole language instead of answering the focused question is rather weasely. Maybe he is trying to learn the language, or at least understand it well enough to interact with C# folks as we benighted Java dweebs occasionally must do. It's fine if you don't want to answer his question, but there's no reason to be condescending about it. -- Lew
From: Michael Tsang on 26 Feb 2010 22:32 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It is the programmer's responsibility to use things correctly. A good programming language should allow programmers to write anything they want. For example, in C#, you can declare a property called "name" but instead set the age. In Java, you can also declare a method called setName but set the age. The lack of properties, along with some features (like operator overloading, references (as the meaning in C++), make the life of a library programmer difficult. Consider a math library, how do the library provide the "add" operation in Java? There is no standard way to do so. In C++, the standard way is to overload the "+" operator. It is the library's responsibility to correctly overload the "+" operator. The differentiation between primitives and classes is also a big mistake in the design of Java, making writing generics that act on primitives and classes the same impossible. In C++, you can write a class that behaves nearly the same as a primitive, the user need not care whether the algorithm acts on a class or on a primitive, and happily write a template for it. In some situation, it is impossible to avoid properties/getter or setter completely. A good example is a GUI library. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkuIkjIACgkQm4klUUKw07C5sQCfYcLEkcNs0IakjQq4iqJLzJwY AUcAoIMBZKVB19pDCkJk68AGTANtcgc9 =/zlQ -----END PGP SIGNATURE-----
From: Peter Duniho on 27 Feb 2010 00:32
Lew wrote: > Peter Duniho wrote: >> Honestly, it seems to me that you ought to learn the language and >> actually understand the feature before you dismiss it out of hand. > > How do you consider what he's doing dismissing it out of hand? He's > asked you what he doesn't understand so that he can grok the value. If > he dismissed it out of hand, he'd've not asked what he's missing. Rather than learning the language, he has made an assumption about how the language works and then written (for example) "It's not worth the extra effort on the part of the compiler to bother in my opinion" on the basis of his assumption, rather than learning the facts. I call that dismissing it out of hand. > Telling him he has to learn the whole language instead of answering the > focused question is rather weasely. I have answered every question he's asked. He has made his judgment before even getting the answers. I don't see how I'm the one that comes out of that as "weasely". > Maybe he is trying to learn the > language, or at least understand it well enough to interact with C# > folks as we benighted Java dweebs occasionally must do. Had you read his post, it would be clear to you that's not what's going on here. > It's fine if > you don't want to answer his question, but there's no reason to be > condescending about it. I have not been condescending at all. However, it is true that I'm frustrated by the attitude that one can make judgments about a language before they have actually learned the _facts_ about that language. Pete |