PROPOSAL: Lightweight Properties

[David Goodenough]

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> field = new Container<Field>();
>
> }
>
> where Container:
>
> class final Container<Type>{
>
> 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