From: "Peter Donald" <[EMAIL PROTECTED]> > On Sat, 20 Oct 2001 12:34, Jose Alberto Fernandez wrote: > > Well, datatype instances are not properties (at least not in ANT1). > > Ant1 does not do a lot of things. > > We voted to unify in ANt2 them last round...
Yes we did. I am not sure whether we decided on an unified syntax (i.e. task covering both) what we did decide was that they will be treated the same way, they will follow the same inheritance rules and one would be able to pass them as parameters on <ant*> invocations. But I am not sure we decided they had to be declared inside a <property> task. > > > 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. We can do that today because we now have TaskContainer. Now, I am not necessarily advocating that we do this. But such an architecture would allow other projects to define their own concept of <target> with maybe specialized attributes for some particular problem. > > 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? > > 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. Jose Alberto
