PROPOSAL: Lightweight Properties (original) (raw)

Marek Kozieł develop4lasu at gmail.com
Thu Mar 5 09:25:07 PST 2009

2009/3/5 David Goodenough <david.goodenough at linkchoose.co.uk>

On Thursday 05 March 2009, Marek Kozieł wrote: > 2009/3/5 David Goodenough <david.goodenough at linkchoose.co.uk> > > > Rienier, > > > > Yes I know that Fields have Generics information available, but they are > > not used in the declaration of a Field object, and so the getter and > > setter to the value of the field are NOT typed, and thus can not be > > checked by the compiler/IDE. > > > > I do not have the knowledge to add this to the compiler, and the only > > documentation I have found for adding things to the compiler (as I > > have already mentioned) did not help - it only talked about adding > > operators to the compiler. The compiler is not exactly well documented > > or if it is, Google has been unable to furnish the right documents. > > > > The reason that it is needed is very simple. One of the big strengths > > of Java is that compilers and IDEs can do a really good job of detecting > > errors, and in the case of IDEs making suggestions as to what can come > > next. Using String field names in places like Bean Binding frameworks > > and API approaches to SQL and friends (like the JPA Criteria API) drives > > a coach and horses through that strength. For that reason, and the fact > > that this is a VERY simple suggestion, this proposal should be given > > serious consideration. > > > > Now if there people out there with the knowledge to help me get started > > in understanding what needs to be changed in Javac (I tried Remi Forax > > as he had already worked in this area, but he was too busy to help when > > I asked) I am more than happy to try to produce a working javac. But > > simply jumping into the source from scratch is unlikely to produce a good > > solution. > > > > So perhaps rather than spending our time throwing out reasons why this > > can not be done, lets try to work together to find a way in which is can > > be done. > > > > David > > > > On Thursday 05 March 2009, you wrote: > > > I think you'll need to spend some more time getting familiar with the > > > JLS. > > > > > > For example, Field objects DO have generics information. That's what > > > Field.getGenericType() is for. > > > > > > I -really- doubt you'll get anywhere with your proposal unless you do > > > both of the following: > > > > > > - impress everybody with an exceedingly complete proposal along with > > > a prototype implementation of javac. Which is going to take a lot more > > > working knowledge of the JLS and how javac parses source files than > > > you currently have. > > > > > > - either a grassroots campaign of many java programmers that > > > vindicates your insinuation that properties are so important, they > > > need to be added to java7, even with this bandaid solution, or > > > alternatively, convince a number of property evangelising people in > > > the java community to openly speak in favour of this proposal. > > > > > > I imagine that's going to cost you a week or 5 at the very least of > > > your time, including getting more familiar with the JLS. March is > > > going to be over by then. > > > > > > --Reinier Zwitserloot > > I do not see the problem you have. > > If you have 'static' name of field (only then compiler can check it) then > you can simply use field. Well no, because if you need to use an explicit getter or setter to do some extra processing or in the setter you want to fire a PropertyChangeEvent then the Field on its own is not enough.

The Field setter could be extended, but as it does not know the parent object (the think of which this is a Field) it can not look for a PropertyChangeSupport object. The Field set method does not try to fire PropertyChangeEvents, and does not provide to use an explicitly coded setter. That could be got around by passing the Field object into a Property constructor, rather than the field names, but again we do not have access to the parent object which makes searching for getters and setters and PropertyChangeSupport objects rather difficult. > > If u do not have that information (it's dynamic) then also compiler is > unable to determine it's type before execution. true > > That why I do not see why we need any other solution than linking 'Fields' > with fields to make it refactor friendly and easy to use. I do not see (maybe I did not understand FCM) how I could handle foo#bar#ali. In this case you need a Field array, not just a field. Additionally the FCM case only seems to handle the Foo#bar case, not the foo#bar case. That is not the end of the world - it would work in the examples I need, but it is less than my proposal covers. > > Am I wrong? Either I have missunderstood the FCM (which is quite possible) or it does not match what my proposal offers. David

So why not use Fields when it's needed.

And mix it with:

class YoursClass{

private final Container field = new Container();

}

where Container:

class final Container{

private Type element;

public Type get(){ return element;}

public void set(Type element){ /* validate / / evens before / this.element=element; / evens after */ }

}

Pesonaly I use Container mixed with validators.

-- Pozdrowionka. / Regards. Lasu aka Marek Kozieł

http://lasu2string.blogspot.com/

More information about the coin-dev mailing list