<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>? 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]
