At 08:32 19/12/00 -0600, Simeon H.K. Fitch wrote: >> In both cases I would say no. usability is not increased because it assumes >> a mind state of user that is programmy rather than not. > >That's not the impression I got. I seem to remember James saying that he could >support the current build file specification using his proposed architectural >approach, which means that his approach at least supports the "current user mind >state". I don't think James is stating that the *user* should think about a >build file as tasks within tasks, but that from an implementation/architectural >standpoint there are benefits.
Okay. >Since the human-computer interface for Ant is the build file (until Antidote >delivers), I believe usability arguments should be applied against the build >file spec (which I don't think James is claiming to address in his proposal, nor >has anyone else, yet). What James is addressing is the underlying architecture >for Ant, and how his approch elegantly accomidates various renderings and >formulations of the build definition. yep. Okay I agree. Perhaps it would be good if James built a sample build file for his approach - I just get a littel scared when he mentions "task stack" - while it matches my concept of task context hierarchy it seems to allow a lot more... just not sure atm. >> The proposal also blurs the distinction between container/contained - a >> huge no-no in component based design. > >A no-no in whose mind? I've never heard that one before. Best place to look for this stuff I found is OOPLSA proceedings. About 90% of it is chaff and 10% good (most of the things are written by intellectuals who don't seem to have the practical experience) however there is some interesting stuff if you can stand to wade through the crap. Think of it this way. Most things have a strict container-contained hierarchy. (--> means contains) Tomcat -->* Servlets JetSpeed (A servlet) -->* Portlets (things that represent an aggregateable part of a web-page) StockFeed ticker (a portlet) -->* Java classes It doesn't make sense to say Tomcat contains portlets - It contains the component (JetSpeed) who also happens to be a container and this container contains portlets. Now if we were to blur the relationship it would be possible that Tomcat could contain StockFeed tickers - which of course doesn't make sense. How do other frameworks deal with this (ie swing)? I expect swing would throw an exception if you tried to add bad things outside the hierarchy (like a JFrame to a JFrame or a JFrame to a JMenuBar etc). Would you advocate the same thing in our case - ie we throw an exception if develoeprs try to add a task to project or a target to a task etc. I don't like this kind of behaviour generally. It is alright to have a unified interface for it all (I am actually building this - the Camelot Container API in Avalon atm) but I don't think it is good in our case. The target/project objects have no reason to be proxied while tasks do. > How would you account for the overwhelming success of Swing? I honestly don't know ;) >It blurs the container/contained >distiction with great abandon, and with great success. As one who has >implemented significant applications in both straight AWT and Swing, it is the >latter that allows much more expressive constructs, ones that in the end are >easier to maintain and change (especially when most of my clients want to make >changes mid-developement). I don't see this as being an issue, and certainly >facilitiates the use of Iterator and Visitor patterns. Well there are differences between swing and our case. In our case we don't build a tree out of direct representations of the tasks - we use proxies to stand in place and interpret the proxies. In which case the iterator/visitor pattern could still work (or at least visitor) but as the tree is untyped you place a lot of potentially messy code into visitors (not a good thing). Besides does swing alow buttons to be contained by buttons. If so who does message handling and do you think that it is intuitive? ;) >For that matter, don't all DOM APIs also blur the distinction between container >and contained? whichs is why we have so many different APIs for validating DOM. Everyman and his dog wrote their own schema implementations before XSchema came about (thou many still do validating themselves). Some would argue that after XSchama validation then our tree is known to conform to strick container-contained relationship. The only difference is that every level has the same interface ;) >Same with most ASTs? Nope ASTs are strongly typed. A node is either a container or a component. >>While I suspect that your approach >> would be easier to initially develope it would take more effort to maintain. > >I would also argue that because James' approach results in significantly less >code than a design that has not been normalized, that the maintenance benefit >from code reduction alone is a win. I think it would be more code size - mainly because we use proxies. >With respect to your statement that James' approach may be easier to develop >initially, I would agree, but that seems to counter at least one statement I >heard here recently that argued that highly generalized solutions are "good for >the brain" but never end up in a delivered product (to paraphrase). depends on the particular design traits used. Inversion of Control (IOC) does considerably slow down development progress - which is why I usually start with monolithic objects that evolve towards componentized IOC objects ;) Other design patterns don't seem to effect developement time as much - some even accelerate the product progress ;) >With the >exception of all the specialized tasks, I could imaging a rendering of James' >proposal hitting the ground running in no time. I agree. 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 | *-----------------------------------------------------*
