ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Glanville" <>
Subject RE: [PATCH] refactoring of javac task into factory
Date Sun, 17 Dec 2000 18:42:22 GMT

> -----Original Message-----
> From: Peter Donald []
> Sent: Friday, December 15, 2000 10:48 PM
> To:
> Cc: Ant-Dev (text)
> Subject: RE: [PATCH] refactoring of javac task into factory
> At 10:37  15/12/00 -0500, Jay Glanville wrote:
> >;-) I think we have a difference of opinion as to the 
> definition of a magic
> >property. ;-)  To me, a property is magic if it is implicit. 
>  A property is
> >magic if the task using it doesn't get the information from 
> it's attribute
> >values.  In my patch, the task does not have to rely on the 
> existence of a
> >"global variable" (ie: a system property), it gets all it's 
> information from
> >it's attributes.
> Ahh but you advocated the use of a global variable to solve 
> the problem.
> Remember? ;) You wanted the attribute to be assigned via a 
> global variable.
> Now the particular name and even existence of such a property would be
> project specific. So you seem to be advocating a magic 
> variable that can
> change at any time ;) It doesn't matter if the mapping from 
> magic variable
> to attribute is explicit for it would functionally and 
> conceptually be much
> the same.

Lets not forget one of our goals - to reduce/eliminate our dependence on
magic variables.  If we can get to the point where we can say that Ant
doesn't use magic variables, then we can make the statement that, logically
(not functionally), parameters do not have global scope.  I.e.: if the tasks
don't use parameters directly (they only get their information for their
attributes or nested attributes) then parameters only have logical scope
within the build.xml file.  This would be analogous to a method variable (in
the procedural world) or an instance variable within a class.

> This kind of approach may be applicable to certain facades 
> (such as the
> javacc compiler facade) but it is not applicable to javac 
> where indidual
> developers preferences make little difference to build.
> >> >The ability to provide a classname for the
> >> >compiler allows much more flexibility for users where the 
> >> core supplied
> >> >tasks don't meet their needs.
> >> 
> >> right - but I think we can do it better someother way ;)
> >
> >Like?
> At one stage there was a proposal for CSS mapping. So you 
> would apply a CSS
> sheet to the build file. Like
> javac.compiler=jikes
> javac.jikes 
> { 
>   class:;
>   pedantic: true;
>   depend: true
> }
> Or someother such thing. You could overide it in build file 
> by manually
> setting attributes but for all other purposes it did it 
> "magically" via style.
> Not sure what became of proposal (if anything ?)

Very interesting proposal.  I hadn't thought of that.  Obviously, I didn't
participate in the original discussion.  My only concern would be that this
would add an extra layer of complexity to a build mechanism.  But, before
you protest, this is only my impression.  I haven't fully thought through
the implications of such a proposal.  Personally, I believe in the KISS
theory, and thus I dislike changes that will add complexity without adding
large amounts of functionality.  But, like I said before, I haven't thought
through the implications of such a proposal.

> >To me, a magic property is analogous to a global variable in 
> C.  If you
> >designed your code right, there were very few needs for 
> global variables.
> >To me, attributes in ant are analogous to parameters in a 
> method, where the
> >task is the method.  If I can, I'd like to remove global variables.
> Right. But your solution involved passing in a global variable as a
> parameter. Except the name of global variable is potentiall 
> different in
> each different project, as is the existence of global 
> variable. Except most
> developers want the global variable so ...
> ;)


View raw message