From: "Stefan Bodewig" <[EMAIL PROTECTED]> > On Thu, 7 Feb 2002, Jose Alberto Fernandez <[EMAIL PROTECTED]> > wrote: > > > The agraviating issue is that any mistake that escapes our eagle > > eyes, inmediatelly becomes a feature and there is no way out of it. > > One of the policies I'd like to see employed is that there is > absolutely no provision that we keep backwards compatibility between > nightly builds, not even to beta builds or release candidates, only to > released versions. >
+1 > I thought we had this policy, but I seem to be wrong. > Has ever been a written down policy stating such things for nightly builds? I am shocked!!! ;-) > Maybe we'd need a longer beta cycle (and a shorter alpha cycle?) to > make sure enough people have been exposed to certain features so that > we may be able to remove them in time. > +1 > > And I fear that we will start ANT2 with a clean slate and in less > > that a year we will be back facing the same backward compatibility > > isues we are facing today. > > This is a very valid concern - obviously it cannot be addressed > completely, at least not until I can get my crystal ball to work. > See that is what happens when you get your Cristal ball at the supermarket, same happen to me, it is such a ripoff. :-) > >> > We could define a DataTypeTaskAdaptor which takes an object, > >> > defined as a datatype, and produces a Task that can be passed to > >> > the TaskContainer. > >> > >> If an element is not known at parser time, you don't know whether > >> it will be task or a data type later - how would you address this? > > > > By using UnknownElement. Not as a task per-se, but as a placeholder, > > Which kind of is what happens today - it does so by accident, but > that's how it works. > My problem is with the working by accident bit, we need to move away from that (and try to regain control of what is currently at fault). > >> Isn't UnknownElement exactly this type of adaptor? It inherits > >> from Task and manages data types at execution time as well. > >> > > > > I really think we are overloading the meaning of UnknownElement > > which produces really confusing code. > > I didn't mean to add something to UnknownElement, I was just stating > how it is working right now. > I know, and I although it works, I would prefer if we had a solid conceptual definition not only of why it works, but also of why it is suppose to work. Today we do not have the second, we actually have a violation of the type system. This is why, in my comming proposal, I am trying to start to address this issue. I may not get it in on the first go, but that is my intension. Once we ave a solid base for why this or that is allowed, then we can move forward with a solid footage. Lets see what I come up with ... Jose Alberto -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
