From ant-dev-return-35520-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org Thu Jul 11 14:26:31 2002 Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 40799 invoked from network); 11 Jul 2002 14:26:31 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 11 Jul 2002 14:26:31 -0000 Received: (qmail 9999 invoked by uid 97); 11 Jul 2002 14:26:37 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 9823 invoked by uid 97); 11 Jul 2002 14:26:35 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 9799 invoked by uid 98); 11 Jul 2002 14:26:35 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D2D9567.1060506@apache.org> Date: Thu, 11 Jul 2002 16:25:43 +0200 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org Organization: Apache Software Foundation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ant Developers List Subject: Re: enhancement, it's done, but do you like how it works? References: <20020711134523.22214.qmail@web10801.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Jose Alberto Fernandez wrote: > --- Nicola Ken Barozzi wrote: > >>dion@multitask.com.au wrote: >> >>>Nicola Ken Barozzi wrote on >> >>07/11/2002 05:48:41 PM: >> > >> >>>>dion@multitask.com.au wrote: >>> >> >> >> >>>>>Is super.mytarget a 'special' keyword? Given that >>>>>you're 'redefining' that >>>>>target (mytarget), what does antcalling it do? >>>>>This is confusing IMHO for an end user. >>>> >>>>Hmmm... >>>>It works like in java. >>> >>>Well java methods don't have dependencies..... and >>>this will break >>>compatibility with all targets that are defined as >>>'super.XXXX'. >> >>Hmmm... > > I see no reason why you need to consider "super" as > special, from the point of view of the ANT engine. The > implementation just needs to do a syntactic rewrite. > > You ask about backward compatibility. I see no > compatibility issue at all. If you have targets called > "supper.XXXXX" they are just there. > > If you have "super.XXXX" and "XXXX" there is no issue > either. > > If you import such a buildfile into another AND > redefine "XXXX", then the rewriting rule will renamed > the original "XXXX" to "super.XXXX" which should cause > a parsing error since you have two targets with the > same name (just as it complains today). > > Is this a backward compatibility issue? NO. In this > situation you are modifying the build, directly or > indirectly. Backward compatibility only means that old > buildfiles have to keep on running as intended. > It does not mean that I can start using anything new > and not have to change something. > > Actually declaring targets "XXXX" and "super.XXXX" on > the same file could be considered a hacky way to > forbid overiding of "XXXX" on any imports. > > >>>>super. is a special prefix. >>>>If I redefine mycooltarget two times I can call >>> >>the first version via >> >>>>super.super.mycooltarget , and the second version >>> >>super.mycooltarget . > > This actually I do not like. I do not mind that it is > an unintended consequence, but I do not think it > should be promoted. Currently it's not doing it. It does have a loop to write super. n times, but n is now fixed to 1. I don't see it as particularly needed, but not as a liability either. >>>>Any suggestions on how it can be made better? >>> >>>Don't use antcall and target..... add a new tag to >>>call the overidden >>>one.....lots of other possibilities...?? >> >>Ok then how about: >> > > All the alternatives below require not only providing > a new project-helper but also modifying ANTs engine. Not AFAIK. > Which means it cannot be used as an add-on to ANT1.5 > and most probably would only work as part of ANT2. > > I still think there is room for doing it syntacticly > (i.e., in ProjectHelper). It may not be as perfect as > it could, but I think it can be done. The below things can all be done within projecthelper, and maybe we would need to add a new Task, but it still can be used in 1.5. > See ideas below. > > >>(a) >> >> >> >> >> >> >> >>(b) >> >> >> >> >> >> >> >>(c) >> >> >> >> >> >> >> >>(d) >> >> >> >> >select="this|super|super.super|..."/> >> >> >> >>(e) >> >> combinations of the above. >> > > > One pattern you guys forgot is: > > > > > > which adds more things to do on the target. And: > > depends="mytarget-local,super.mytarget"/> > > > > > > which executes super after. Both will mix the > dependency trees. This I think uses more of the power > of ANT than just limiting ourselves to > of course should be supported. Ah ok, cool :-) > With respect to the syntax of "super" what I would > probably do instead of denoting it just as the string > "super.XXXX" I would use some different notation, > for example: > > depends="${ant::super(mytarget)}"> > > For Java writers super. is more easy to see, and less intimidating than :: ... Hey, but it's a property... hmmm... > now, I doubt anybody has a property called like that. > So I think the backward compatibility issue is > negligeable. The advantage I see with this notation is > that it allows ProjectHelper to do more powerfull > rewriting. In the following situation, for example: > > File: ${basedir}/includes/A.xml > > > > > File: ${basedir}/build.xml > > depends="${ant::super(mytarget)}"> > > > > The rewriting done by ProjectHelper will look like: > > depends="a,b,c"> > > > > depends="include/A.xml::mytarget"> > > > > Notice that all the rewriting can be computed > statically, so there is no issue here. > > This particular mangling rule for the overriden > targets has the advantage that when we see the > execution of the build we will be able to identify > which version of the target is under execution at any > time. Notice that everthing stays syntactic with no > changes on any of the tasks, in principle. > > And as with my comments above, if after rewriting > something clash, then the files are not upward > compatible, which is OK. > > comments, Well, it's basically what the patch does (or should do ;-), but IMHO what the patch does is simpler. I don't understand what using a property versus super.taskname brings you, could you explain? -- Nicola Ken Barozzi nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: