--- 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
