--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On 6/15/07, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > I am actively working on this as we speak,
> actually,
> > and I'm pleased so far with my results.
>
> FTR Matt, I still haven't read anything to convince
> me that write
> access via <property> is desirable, needed, and
> good. I'm not trying
> to put a damper on your efforts, but so far the use
> cases I've seen
> for "write" are better handled by custom tasks.
Okay, first to be more clear: I determined that the
natural extension points for properties handling would
be, reading them, expanding them from a string (the
use case that kicked off this discussion), and setting
them. I did and do recognize that changing how
properties are set was weird, and as such have still
not even written the interface for how that would
happen. Even if the final group consensus is to allow
for them, I am putting them last, and who knows? I
might not even be the one to implement them in the
event we do go forth with them. :)
>
> What about the <*ant> tasks? These "things" which
> are not string
> properties, how do they percolate to sub-Projects?
> We have clear
> semantic for properties and references passing, so
> it would be much
> clearer and "The Ant Way"(tm) to have them as
> references, manipulated
> using custom tasks, and passed using reference
> semantic, and which
> unlike properties are not fully compartmented
> between Projects, which
> the parent and child project share the same
> referenced-object.
>
Here you've simplified "pluggable property setting" to
"supporting non-String properties" and I suppose
that's fair enough from a buildfile-only standpoint.
But the current design of PropertyHelper allows for a
given property to be set as an arbitrary object via
Ant's API. I think, even if we don't recognize that
we should allow a hook for setting properties, that
this is harmless enough, despite your well-founded
arguments regarding references. That said, it's no
concern of mine if we reduce properties to Strings--it
would simplify some things, certainly--but the user
community might feel otherwise. Then again, (1) if
we're already giving them breaking changes we can
certainly go whole-hog with those if we so choose, and
(2) I sent Wascally Wabbit from AntXtras (who seem to
be the greatest consumer of PropertyHelpers from the
list Peter sent out) a personal message inviting him
to this conversation and we still haven't seen him.
I'll follow up with a similar message to the other
admin on the project in case he's on vacation or
something. Meanwhile I'll try restricting properties
to strings and see if we break anything internal.
> Would installed PH instanced percolate to
> sub-Project automatically?
I'm not sure. I think we need more discussion of
this:
> Because if they do, Peter's argument that the
> explicit declaration of
> the PH ensures BC falls flat if one uses "external"
> reusable build
> files which would happen to use the same syntax as
> the PH prefix
> installed in another build file. That would be bad
> encapsulation.
>
> So the more I think about this, the more I feel it's
> wrong at several level.
>
I don't necessarily agree that the PropertyHelper
should be externally configurable (via, I assume,
magic properties). I think we'll be in better shape,
personally, to simply provide a reasonable set of
tasks to replace PropertyHelpers and add handling
delegates to the currently installed PH, all from
within the buildfile. It's a similar argument to why
externally declared namespace prefixes are wrong, and
so I am confident you and I will (for once) be in
agreement on this point.
> Let's stick with read access. As toString:
> demonstrates already,
> what's to the right of the PH scheme doesn't have to
> reference a
> property name, so it's flexible enough. --DD
>
Final thought wrt not allowing for setter delegates:
Because we plan to continue to allow a user to install
an arbitrary subclass of PropertyHelper we would have
to make setXXX final operations to stop a determined
user from doing I-can't-foresee-what kind of things
with property setting. Are we prepared to do this?
-Matt
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
___________________________________________________________________________________
You snooze, you lose. Get messages ASAP with AutoCheck
in the all-new Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_html.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
