--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On 6/14/07, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > --- Dominique Devienne <[EMAIL PROTECTED]>
> wrote:
> > > I don't understand the SetPropertyResolver
> aspect.
> >
> > On further reflection, the Set* interface does
> make
> > sense, but only as an extension to the Get*
> interface.
> > This would be the correct way to set anything
> that
> > couldn't be stuffed into the basic
> String-to-Object
> > property map (whatever that might be) and would
> imply
> > that the entity in question could get anything it
> > could set. This also implies that the existing
> > namespace concept that exists but is unused in
> > PropertyHelper needs to go away. The
> > setter-that-can-get would parse its own
> > pseudo-namespace if applicable. Since this would
> > extend the Get version, I would think it could
> wait
> > until the main two interfaces were handled.
>
> Sorry to be a bit thick, but I still don't
> understand. I don't want
> properties to be anything but Strings. We use
> references to refer to
> something else that Strings. I'm still not buying
> the SetPR given what
> I've read so far ;-) --DD
>
Okay, I'll give you points for seeing the forest in
this case. Here's Costin's commit message from the
initial add of PropertyHelper:
<log>
"Dynamic properties" and a bit more.
This is "slightly" different from embed - if dynamic
properties will be
accepted in 1.6, it is better to do it right. Embed
uses few hacks to
trick the ProjectHelper.
PropertyHelper includes all the code related with
property manipulation
from Project (cut&paste). I added a very simple hook
mechanism ( Filter/Valve
like ) for the most common operations.
The API is obviously far from final - someone who
really understand "user"
and "inherited" properties should review it and make
few changes.
In Project, all properties fields are private - so all
can be removed.
The methods related with properties will just delegate
to PropertyHelper.
>From a user point of view - no visible change (
hopefully :-). Even grant
will continue to work ( but won't be able to use the
new features ).
Benefits:
- cleanup of Project. Less code and better organised.
- Property handling will hopefully be cleaner too
- we get to add APIs for namespace support, and maybe
support non-string
properties ( JSP-EL like - that needs to be disussed,
but IMO it would
be very helpfull ). While refs are Objects, the main
distinction is imutability.
Also:
- apps embeding or extending ant can fully customize
_all_ aspects of
property processing, including ${} replacement and
even the syntax.
- it should be very easy to hook a different storage
mechanism ( i.e.
integrated with the embeding app, without requiring
copy of properties ).
- it should be possible to avoid copy when creating
execution frames
( by using a chain that keeps changes and delegates
getters ).
- dynamic properties support ( my original itch :-)
</log>
Whether object properties are desirable can be up for
debate. We are planning here to massacre the existing
API, but for inertia's sake I would leave some things
intact, like the use of Hashtable as opposed to
Properties; that being the case it may be easier to
continue to support Object properties than to withdraw
that support.
Finally, take the toString: extension. This is a
perfect example of a PropertyEvaluator implementation.
What does it do? It renders a ref as a String. So
it may be that a StoringPropertyEvaluator would set an
Object reference on the Project created from a String
representation, no? Again, this is something we could
keep in mind but leave unimplemented for the time
being. :)
Finally, if any of the old-timers has any more
information on Costin's mention of "dynamic
properties" without my having to search the archives
(lazy), feel free. :)
-Matt
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
____________________________________________________________________________________
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
