ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Did somebody say Shut up and Write? :)
Date Wed, 20 Dec 2000 03:25:38 GMT
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
>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
>standpoint there are benefits.


>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
>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
>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
>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
>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
>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.



| "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               |

View raw message