I would agree with Bill here that there is only so much words can convey. I had the same problem until the bootstrapping example was published, that's when everything clicked in place. I always like the illustration kind of documents (and hence my Illustrating Tapestry!) which is always concrete and leaves little room for ambiguity.

As far as the names go, I am still with <service> and <service-point>. An interface would tend to imply that this is the definition of the interface which it is not and the same applies to implementation.

-Harish

Bill Lear wrote:

On Wednesday, September 17, 2003 at 10:08:14 (-0400) Howard M. Lewis Ship writes:


...
Yep, that's the whole point ... build the two jars and you have Adder
and Subtractor ready to go.  HiveMind will locate and parse all the
hivemodule.xml's into one consistent registry.  If you get
hivemind.examples.Adder it will combine the interface from the first
jar with the implementaion contributed by the second jar.

So ... obviously I've been failing on getting the message out about
what HiveMind does if this is coming as a surprise now.



I think the issue is very simple: programming in this paradigm is a radical departure for us not used to it. I'm not used to gluing things together with such little effort. Not only are the concepts different, but, as one might expect, the language one uses to convey the concepts is altogether new. In such cases, it's not so much a question of being clear, as providing concrete examples that cover the initial case, and then the initial case plus one --- sort of teaching by induction, if you will (prove case 1, then prove if case N is true, case N+1 is true, etc.).

So, I don't think you have missed wildly (failing); I think that
the examples could encompass this (and, critically, I think examples
need to be *structured*, starting from simple to simple + 1); and,
finally, I think a tweak to the language, as we have discussed,
would also help.

By having structured examples, it allows intellectual movement
from simple cases to those beyond, which is what learning new
things like this is all about.

[Just a thought: why "service", "service point"?  I realize that
"service" is a useful term, but why not "interface" and
"implementation"?  Those terms seem to be broad enough and easy to
understand...]


Bill


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Reply via email to