Comments inline... -T
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Sascha Andres > > When I think a bit more of sharing information throughout tasks I come > to these points: > > In a programming language, data can be: > > * private > * public > * protected > * static > > and with a bit more work > > * persistent > > IMO there is no situation where I can think of a need for 'declaring' > something static in NAnt if there would be task communication[1]. > Correct me if you can imagine. > > How about introducing a 'DataStore' that is working comparable to the > properties: > > this.Project.DataStore.Save(object); > this.Project.DataStore.Save(name, object); > this.Project.DataStore.Save(name, object, type); > > First function would be the magic variable. If set in a task, this > value remains. If not set, the output of the task could be written to > this special variable. So a load operation always refers to the task > running before. > > Second function would lay an object in the data store with a key so it > 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? > 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. > [From a previous post] > I don't like the we-do-anything-in-xml approach. XML is a nice thing, > but it certainly adds some overhead to communications. > I would prefer an invisible property system based on keys. This would > allow to store informations in one task and to read it in another one, > without dealing with properties set by the user. 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. -T Disclaimer Message: This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. ------------------------------------------------------- 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
