How to emluate "properties" in Java?
in [Java Programming]
|
From: Pitch on 1 Mar 2010 09:10 In article <Mcjin.66943$Db2.9773(a)edtnps83>, dcest61(a)hotmail.com says... > It's just that, try as I might, I don't see that there is anything more > to C# properties than syntactic sugar. There is a convention. You use properites for values that define an object's state, values that probably should be serialized. If you have anything else that needs to be computed depending on the object's state you use methods. Setters/getters are not so readable. I believe properties in .NET came from Delphi where their role was also to expose these values in the IDE's Object Inspector. Oter than that there is no extra functionality but since it makes code more readable, I miss properties in Java. -- stirr your cofee properly
From: David Lamb on 1 Mar 2010 12:17 Arved Sandstrom wrote: > Peter Duniho wrote: >> Arved Sandstrom wrote: >>> The fact is that you can replace every use of a C# property with >>> either a public member field and/or a public method. >> >> No, you can't. If you do that, then you sacrifice a big part of what >> makes properties useful. > [ SNIP ] > > Educate me then. I don't know if this applies to any of the specific implementations previously mentioned, but one characteristics of "properties" as I understand them is that they have the mathematical property that, in the absence of parallelism (or with certain restrictions on how parallel threads/processes can access them, a "property" means that after a.b = e; ... (code not assigning to a.b) ... x = a.b; you can deduce x=(the value of e at the indicated point in the program). This can in principle make possible certain optimizations (and the proofs they depend on). Using arbitrary methods instead of "properties" at least makes it harder to analyze. Now that run-time analysis is common that may no longer be relevant.
From: Peter Duniho on 1 Mar 2010 12:43 news.telesweet.net wrote: > Functionality is defined by what the end-user sees. If what the > end-user sees is the same, then it is the same functionality. The only way that statement makes sense is if by "end-user" you mean the programmer. By your definition, nothing in any language is anything except "syntactic sugar", since I can write a program in assembly language that presents exactly the same output as a program in Java, C#, etc. And of course, if we define "end-user" to be the programmer, then what the "end-user" sees in the example of properties is _not_ the same as without. Ergo, properties in .NET are not "syntactic sugar". So, take your pick: either everything about every programming language is "syntactic sugar", or properties in .NET are not. Pete
From: Peter Duniho on 1 Mar 2010 12:45 Thomas Pornin wrote: > According to Peter Duniho <NpOeStPeAdM(a)NnOwSlPiAnMk.com>: >> That's the GetProperties() method from the System.Type class (equivalent >> to Java's java.lang.Class class). There's simply no way to write that >> method in Java simply by implementing properties as conventionally named >> methods. > > But it is simple enough to do with annotations. Simply define this: > > @Retention(RetentionPolicy.RUNTIME) > @Target(ElementType.METHOD) > @interface Property { } > > and tag getters and setters with the '@Property' annotation. If 'm' > contains a reference to a Method instance, then just call > m.isAnnotationPresent(Property.class) to see if the method has been so > annotated. [...] First, I have said all along that the comparison is with a property implementation depending _only_ on naming methods conventionally. Second, as Stefan points out, your suggestion is not a language standard, and thus it's not possible to write arbitrary code that takes advantage of it in a reliable way. It's well and good to be able to implement that sort of thing in one's own code base, but it's not a general purpose solution. Pete
From: Peter Duniho on 1 Mar 2010 12:48
David Lamb wrote: > Arved Sandstrom wrote: >> Peter Duniho wrote: >>> Arved Sandstrom wrote: >>>> The fact is that you can replace every use of a C# property with >>>> either a public member field and/or a public method. >>> >>> No, you can't. If you do that, then you sacrifice a big part of what >>> makes properties useful. >> [ SNIP ] >> >> Educate me then. > > I don't know if this applies to any of the specific implementations > previously mentioned, but one characteristics of "properties" as I > understand them is that they have the mathematical property that, in the > absence of parallelism (or with certain restrictions on how parallel > threads/processes can access them, a "property" means that after > a.b = e; ... (code not assigning to a.b) ... x = a.b; > you can deduce x=(the value of e at the indicated point in the program). > This can in principle make possible certain optimizations (and the > proofs they depend on). Using arbitrary methods instead of "properties" > at least makes it harder to analyze. Now that run-time analysis is > common that may no longer be relevant. That would be a wonderful property of properties (sorry for the pun :) ), but unfortunately the _implementation_ of .NET properties really is just special get and set methods. Those methods can do anything, including having various side-effects, and requiring synchronization for shared state from which they retrieve or assign state. So it turns out that properties in .NET don't provide that concurrency advantage that you're describing. There may be other languages that do use properties in _that_ way. I'm not aware of them though (or at least, if I'm aware of the language, I'm not aware of that particular feature). Pete |