How to emluate "properties" in Java?
in [Java Programming]
|
From: markspace on 27 Feb 2010 01:12 Peter Duniho wrote: > > 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. You've been a little condescending, imo. And I've poked at you and your opinions too, so we'll call it even. Really I'm just trying to get some information, but you seemed to stop giving out any information after your first post on the subject. There might be something important with properties, but what I've read so far just makes me go "meh." And yes, saying "learn the language yourself instead of asking me" was a little rude. You've obviously used C# far more than most of us here, and I thought I was asking an expert. If your going to just be defensive, that diminishes the value of your expertise, doesn't it? The best thing I've seen so far was the abbreviated syntax for declaring getters and setters. In Java I guess it might look something like this: class PropertiesExample { @ReadWrite @Synchronized int N; @ReadOnly final String Value = "hmm"; } LOC is directly proportional to development costs and maintenance. This syntax does appear to reduce LOC and therefore it might be worth looking at. But I'm still confused what "robust data binding" does here.
From: Peter Duniho on 27 Feb 2010 01:37 markspace wrote: > [...] you seemed to stop giving out any information after > your first post on the subject. It could only seem that way to someone not reading my posts. I have answered every question directly, and with considerable detail. The idea that I have provided no additional information past my first post is ludicrous. > There might be something important with properties, but what I've read > so far just makes me go "meh." As near as I can tell, that is simply because you have jumped to conclusions rather than acknowledging that you don't yet have the full story. > And yes, saying "learn the language > yourself instead of asking me" was a little rude. Had I said that, I could see how one might consider that rude. But I definitely did NOT say that. I have not once suggested that I am unwilling to answer questions, or that you should seek some other reference. What I _have_ said is that rather than jumping to conclusions, you should learn first. Whether you learn from me, or from some other reference, is immaterial to that point that I made. But I've written nothing that could reasonably be construed as suggesting I'm unwilling to be that source of information. > You've obviously used > C# far more than most of us here, and I thought I was asking an expert. > If your going to just be defensive, that diminishes the value of your > expertise, doesn't it? I would describe my attitude not as "defensive", but rather "exasperated". I tire quickly of trying to teach anyone who approaches the learning process with a prejudiced view. > The best thing I've seen so far was the abbreviated syntax for declaring > getters and setters. Ironically, that's the least useful aspect of properties in C#. It's helpful in defining simple classes, especially immutable data containers. But most non-trivial classes will have additional logic, especially in the setter. And of course, the abbreviated syntax is not useful if one needs to provide any specific implementation. Pete
From: Arved Sandstrom on 27 Feb 2010 09:04 Peter Duniho wrote: > markspace wrote: [ SNIP ] >> The best thing I've seen so far was the abbreviated syntax for >> declaring getters and setters. > > Ironically, that's the least useful aspect of properties in C#. It's > helpful in defining simple classes, especially immutable data > containers. But most non-trivial classes will have additional logic, > especially in the setter. And of course, the abbreviated syntax is not > useful if one needs to provide any specific implementation. > > Pete That abbreviated syntax, which for you is the least useful aspect of properties in C#, may well be the most useful aspect of properties for most C# programmers. I doubt very much that the majority of C# writers are doing anything but jamming in those { get; set; } pairs for each field they want to expose. Even MS in its API doesn't claim more for properties than: "Properties are members that provide a flexible mechanism to read, write, or compute the values of private fields. Properties can be used as if they are public data members, but they are actually special methods called accessors. This enables data to be accessed easily and still helps promote the safety and flexibility of methods." There really isn't anything deeper going on here. My opinion is that C# properties would have more of the usefulness that you impart to them, apart from the easier syntax (which as I've stated is what I think most C# programmers get out of properties), if the properties did *not* access other member fields. To me the following snippet (I borrowed it because a lot of people use it) shows off properties (and of this specific form I've seen very few examples): class Accounting { public double Price { get; set; } public int Quantity { get; set; } public double Total { get { return Price * Quantity; } } } and this (which I've seen many examples of) does not: class Accounting { private double price; private int quantity; public double Price { get { return price; } set { price = value; } } public int Quantity { get { return quantity; } set { quantity = value; } } public double Total { get { return price * quantity; } } } The second example to me is no different than Java accessors: entirely up to the programmer what they access with these methods. Using the classic form, with backing fields, has no real extra value at all. IMO. I'm also of two minds about the property Total in this example. I suppose if one were making a declaration about object state, and held that the derived read-only value Total is as much a primary component of Accounting object state as Price or Quantity, I could live with it. Myself though I'd keep Total a method, and drop the property syntax. AHS
From: Peter Duniho on 27 Feb 2010 12:28 Arved Sandstrom wrote: > [...] > That abbreviated syntax, which for you is the least useful aspect of > properties in C#, may well be the most useful aspect of properties for > most C# programmers. I doubt very much that the majority of C# writers > are doing anything but jamming in those { get; set; } pairs for each > field they want to expose. It has been my experience that that is _not_ how properties are typically used (as I've already noted). > [...] > My opinion is that C# properties would have more of the usefulness that > you impart to them, apart from the easier syntax (which as I've stated > is what I think most C# programmers get out of properties), if the > properties did *not* access other member fields. As a class member, it's my opinion that properties should have as much access to other class members as any other class member. That is to say, access to private fields is permitted. Of course, this is water under the bridge; the language already allows properties to access class members, and so must continue to do so, regardless of one's opinion on the topic. That said, I have proposed to the C# design group that the language add to properties the feature that the property can encapsulate its own implementation details. For example, allow the declaration of a class field inside the property declaration, thus hiding the field from any other code in the class. Likewise for C# events (which are similar to properties, except that they are always a delegate [function pointer] type, and have an "add" and "remove" method instead of "get" and "set"…they are used where in Java one would use a "Listener" list). My personal opinion is that would dramatically improve the usefulness of an already-useful feature. The cost of adding such a feature to the language may prevent it from ever happening, but I'm hopeful. :) > [...] The second example to me is no different than Java accessors: entirely > up to the programmer what they access with these methods. Using the > classic form, with backing fields, has no real extra value at all. IMO. There's _some_ extra value. Just not as much as if the programmer were forced to use the property. The programmer who is diligent in using the property (and this is true in Java or C#) is rewarded at a later point in time by permitting changes to the implementation of the property without having to revisit a lot of other code where a field has been accessed directly. > I'm also of two minds about the property Total in this example. I > suppose if one were making a declaration about object state, and held > that the derived read-only value Total is as much a primary component of > Accounting object state as Price or Quantity, I could live with it. > Myself though I'd keep Total a method, and drop the property syntax. But that is not relevant to the question of the usefulness of properties generally. For better or worse, illustrative examples often are too simple to fully express the benefits of a feature, or too contrived to survive a deep analysis as to whether that's really a situation where the benefits are fully realized. Pete
From: David Lamb on 27 Feb 2010 16:31
Arved Sandstrom wrote: > ... I doubt very much that the majority of C# writers > are doing anything but jamming in those { get; set; } pairs for each > field they want to expose. > > Even MS in its API doesn't claim more for properties than: > > "Properties are members that provide a flexible mechanism to read, > write, or compute the values of private fields. Properties can be used > as if they are public data members, but they are actually special > methods called accessors. This enables data to be accessed easily and > still helps promote the safety and flexibility of methods." > > There really isn't anything deeper going on here. This is one of several points where I might have jumped in, so it's really a reply to lots more people than just Arved, and I'm not really disagreeing with anybody... I have no opinion yet about whether "properties" are important in current languages. However, back in the Bad Old Days, when we had to pack a 7-bit integer, a binary flag, and two 3-bit integers into a 16-bit word (with 2 bits left over for future expansion), the ability to write a.b = c and have inline get/set methods called would have been a big deal. At least back then, we had the attitude that assignment/fetch of "fields" was enough easier for humans to understand than a.setB(c) that it was worth having. It might be worthwhile having some sort of annotation for a get/set pair that says "this is really meant to be a pseud-field, so a code walkthrough should verify it really behaves that way instead of doing the arbitrary munging around any old method could have done." |