Ha, I think we've been stonewalled. What we're talking about is great for add* methods, but I think we're out of luck for create* methods. Although I never use these anymore either. Seems kind of bad to say "refid works on all datatypes automatically, unless you use createXXX methods"... :( I may keep messing around with this just to see what happens though.
-Matt --- Dominique Devienne <[EMAIL PROTECTED]> wrote: > > From: Matt Benson [mailto:[EMAIL PROTECTED] > > > > Hmm, from all your comments it seems you have > pointed > > out that the best solution would be for types to > have > > no knowledge whatsoever of refids. > > True. > > > Of course this is > > not possible under the gaze of the BC monster. We > > could always start the mythological Ant 2 after > 1.7 to > > apply the learning of the past several years. > I'll > > keep thinking about this, though. > > But assuming that the framework starts > unconditionally handling datatype > refids, then older code keeps on working just fine. > The old setRefid() > methods never get called (by the framework), and the > manual checks > succeed, while still catching erroneous programmatic > use of setRefid(). > New types just ignore refid altogether, and are > greatly simplified. > > So on second thought, it sounds doable. The only > possible break of BC I > can foresee ATM would be for custom types, outside > of Ant, which broke > the unwritten rule that no attributes/elements are > allowed once one uses > refdid="someId", and I don't mind that ;-) --DD > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
