PROPOSAL: Lightweight Properties

[Marek Kozieł]

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.

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

http://lasu2string.blogspot.com/