PROPOSAL: Lightweight Properties (original) (raw)

David Goodenough david.goodenough at linkchoose.co.uk
Thu Mar 5 09:36:07 PST 2009

On Thursday 05 March 2009, Marek Kozieł wrote:

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.

Now you have lost me. I do not understand this or how it would help.

David

More information about the coin-dev mailing list