At 08:26 15/1/01 -0500, James Cook wrote: >Peter, I re-read your reply and I was confused as to what you were stating. >I think I have it straight now. You are claiming that by moving the fetching >of properties into an engine.getProperty(name) method, this is making it too >difficult for the Task developers. > >I am receptive to this as an issue. I would propose that reflection be used >before calling Task.execute() to populate the appropriately named setters. >This should take care of that issue, no?
yep - but now why do you need the runtime tree? ;) Why not just use a proxy tree. The only advantage I see of the runtime tree is to make everything a "task". However you will eventually have to deal with "tasks" like target that can not have their proxy data evaluated when they are evaluated. Which puts you precisely back to the start where each task instance is just a convenience 20 line class. At which point the whole advantage of the "everything is a class" approach fails I believe. Feel free to convince me otherwise thou ;) Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
