Hi, * Troy Laurin wrote on 13.07.2004 (09:24): > Sascha Andres wrote: Added above line. Deleted too much, and don't wanted to use undo after I wrote all of the text ;)
> > can be accessed from all tasks. The last function adds a protected > > object to the store only readable from a task of the same type. The > > protected Load operations would work analog to this. > > The idea of protected data items sounds interesting, but could it be > implemented without extending Project, just through static properties in > the task class? What do public data items offer that can't be done with > properties? Would it be better (or is it equivalent?) to implement > references, similar to Ant? Just short, cause I'm on my way to work: I think there should be a difference between public data and properties. Public data would be part of the communication, the other is generally part of the build file, used to control how the build is done. The risk overwriting a user property and what may result (broken build, hard build file debugging) led me to propose public data seperated from properties. > > A few words to persistence. Imagine two more overloads, that indicate > > using a boolean variable if an object should be persistent. When a > > data store property on the project is set, a datastore with all > > variables marked persistent will be saved to the given file (and > > loaded at the beginning of the next run). > > Just a comment on overloads: They're generally evil. If two methods do > different things, they should have different names. Compile errors are > preferable to strange program behaviour if you call a method > incorrectly. I agreee that there is potential for wrong calls. I don't have a problem splitting it into Save, SaveProtected, SavePersistent and the respective Load methods. Perhaps something like Protected.Save Public.Save Persistent.Save > Whether storing xml or storing objects, I'm a little wary about the idea > of adding "magic" communication to a build system. It feels too much > like accessing the internal API of a system. If one task relies on the > output of another task to be in a particular format, then there's > usually a good chance that the task will break if the other task changes > its output format. You're right on this point. But using a tasks output is a risk. And changing a tasks output should occur only in beta and / or a major release change. A communication system would be most helpful when there is a large number of user defined tasks - where you could use public and/or protected information. The magic may be useful for debugging issues (a crash in the csc task that occurs only from time to time). -sa -- sa at programmers-world dot com http://www.livingit.de Internet sites: http://www.not2long.net - Make long links short Boomarks online: http://www.mobile-bookmarks.info ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
