Re: [HiveMind] Extension to adder example

[Harish Krishnaswamy]

Howard M. Lewis Ship wrote:

<service> --> <interface>
<extend-service> --> <implementation>
I like that, except that <service> is a "super-element" of <implementation> and I want 
to keep it
that way, since that's the normal usage.  That is, you can define a service and 
provide the
implementation (core service impl plus interceptors) all in one go.  And that loops me 
back to
<service-point> and <extend-service>.  <contribute-service>?
Exactly what I intended to say, you said it better. But why don't you 
like <service> for <extend-service>?

I think many people only give lip-service to OO ... they still think in terms of 
massive, central
"brain" objects with a bunch of helpers attached. I tend to think in terms of lots of 
smaller
objects, peers, working together ... and HiveMind lets me structure it all that way.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
 

-----Original Message-----
From: Bill Lear [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 17, 2003 10:34 AM
To: Jakarta Commons Developers List
Subject: RE: [HiveMind] Extension to adder example

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]
   



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