I stumbled upon this thread late, and have tried to catch up, but am far
from there, sorry.
My perspective is I import (include) things for "scriptlet re-use", I am not
trying to override. I guess w/ property immutability I'd just assumed target
immutability (although I know importing can change the root target). I worry
about unintentional clashes much more than I like the ability to over-ride.
I think you are addressing that w/ different tasks, and if so, great.
> Maybe it would be better to think in the term of "mixin" as some
languages
> (e.g. some Lisp flavours and Ruby) use. The following two exerpts are
from
> the Modules chapter of the free book "Programming Ruby: The Pragmatic
> Programmer's Guide"
(http://www.rubycentral.com/book/tut_modules.html):
...
> Maybe it would be possible to borrow some ideas and concepts from
Ruby...
So you are suggesting namespaces? That seems very reasonable. Centipede uses
prefixes on all properties and such in the scripts it creates intended for
inclusion, in a manual attempt to achieve this, but doing so automatically
on properties as well as tasks, and types (hmm), seems eminently better.
Question is -- does one impose namespaces on the author of the script, or
the consumer? When managing large sets of scripts I suspect the author, but
when simply managing ones own few scripts I would suspect the consumer.
Something like:
<import file="script.xml" namespace="mystuff" />
where namespace is optional could perhaps lead (during script parse) to
properties being put into namespace "mystuff", tasks prefixed as
mystuff.mytask, and so forth.
Again, I can see the benefit of allowing an override -- or otherwise
includes are "brute chunk scriptlets", but I think one has to be more weary
of the inadvertent override than the intentional one.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
