On Sat, 20 Oct 2001 18:44, Jose Alberto Fernandez wrote: > > > Yes you > > > can say that in ANT2 they will be. I could also say that <target> > > > declarations can be processed by an ANT task (a quite simple thing to > > > do). > > > > However if you recall last round we -1'ed the idea of having targets as > > tasks... > > Which is not the same. What I meant to say was that <target> could be > implemented by a task that registers the target being defined into the > project, instead of the way is done today with special code in > ProjectHelper.
So what you are saying is that having targets implemented as tasks is not the same as having targets implemented as tasks ? Uh huh. > > > Orthogonality is one of the mayor design features of succesful > > > languages. > > > > not really. It is a side effect from other decisions. It is rare that an > > aspect is independent of other aspects and when making design decisions > > it is often the case that a set of related aspects for a higher order > > "aspect" that is othogonal to other higher order "aspect"s in system but > > the component aspects are rarely othogonal to each other except in > > exceptional circumstances. > > Eh? precisely. > > > In the particular case of Java which is our taget audience, most > > > features of the language are expresses in the language itself. They do > > > not use some secret API not available to user defined code. The String, > > > Class, IO libraries, etc. Are written in Java and use just the same > > > stuff available to user code. To define features that are not > > > expressible or usable on user difine code is to > > > > so you are advocating we don't have any task at top level and instead > > require an init style target ? > > No. I am advocating not having the string "property" hardcoded on the > parsing engine giving a special treatment to any task using such a name. > > Now, three different alternatives have been suggested for it: (1) disallow > top-level tasks; (2) allow any class at top-level; (3) "mark" those tasks > that should be allowed by for eample using a marker interface. > > I like (3), others prefer (1) or (2). You are the only voice, up to now, > advocating on keeping the hardcoded strings. I am not advocating anything. It is just that sometimes this sort of thing is needed to cut through the crap. The simple fact of the matter is that you have yet to show a reasonable use case for having a Declarable interface. In the future we only really need to keep property outside unless we allow all tasks or none. Thus Declarable is what is known as flexability syndrome. -- Cheers, Pete *-----------------------------------------------------* * "Faced with the choice between changing one's mind, * * and proving that there is no need to do so - almost * * everyone gets busy on the proof." * * - John Kenneth Galbraith * *-----------------------------------------------------*
