Jean-Louis Boudart wrote:
I think the idea of implementing an augment features (idea initiated by Matt
Benson as described
https://issues.apache.org/bugzilla/show_bug.cgi?id=48798or in the
previous thread) make sense.
This idea was to provide a task that allows augmentation of previously
declared references.
There is many places where it can be useful, and as far as i know nobody was
opposed on the main idea.
By the way there was one point still in discussion lost in the whole thread.
Many person was in favor of an opt-in approach to keep backward
compatibility.
I guess, you can only use <augment> feature on references that as been
designed for extention (by adding an argument like final="false" on the
reference for example).
Antoine Levy Lamber was highlighting that ant datatypes are currently
de-facto mutable by default. And maybe we were complexifying too much this
feature.
Maybe you could spread the discussion in two different parts :
- adding an augment task
- adding a new attribute final to datatypes
With AspectJ it would be possible to add an attribute final and make it
be really enforced by all tasks.
I am reluctant for complex features also because I am afraid we could
start something that we will not have the time to finish 100% and will
deliver with bugs.
The objective of this thread is to take a decision on :
- restriction on augment feature
- and if the vote is in favor to choose one implementation design to do
it
So, What's your opinion ?
Should we introduce kind of restriction on the <augment> feature (like
"final=false") ? Or should we keep this usable on ALL existing reference ?
If the answer is yes How would you like to we restrict this ?
- by adding a new attribute (like final="false") on datatype ?
- by adding magic properties ?
- taking in consideration that taks and types are java objects, can we
reuse a java property "final" as a configuration attribute?
Exemple: private final String myProperty;
- with another alternative ?
IMHO the augment feature can live without any restriction.
As highlighted by Antoine, with current code base "reference can be modified
by user developed ant tasks or script fragments."
But, it could make sense to provide a way to make reference unmutable. Doing
this a given reference cannot be modified by <augment> task (or by any user
developped ant task / script fragment).
For example :
- if you design a target (or a datatype) used in a multithread context
you probably don't want to make it extensible (because it's gonna be a hell
to maintain).
- if you are designing kind of generic build file, you may want to have
part of this generic stuff extensible but maybe you want to restrict
extension on some of your targets/datatypes that are deeply used internally.
Part of the generic script can be kind of "blackbox".
Maybe this means that there should be private references which are only
accessible within a certain scope.
If I understand well, in easyant you develop standard build files, which
contain datatype instances with id(s)
and you do not want your users to fiddle with these datatype instances.
Even if there is an attribute "final", users who want to change the
datatype instances will find a way around it.
Unless the enforcement of final="true" is at the java runtime level (for
instance with AspectJ).
About implementation details, i would be in favor of adding a new attribute
to datatypes (like final="true"), cause it make it easy to understand /
read.
Considering that current code base allow to modify any references and to
avoid any side effect, i suggest to make the make this restriction optional
.
I guess if you want to make a reference unmuttable you should set it
explicitly (with a final="true").
<!-- Example of an unmuttable reference -->
<myDataType id="my.reference" final="true"/>
In any case i really hope to use the <augment> feature soon in easyant :).
My 2 cents
Regards,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
