[Zope3-dev] Service - Utility - Utensil - Fork - Food - Chocolate - Candy...darn, now I'm hungry!

[Lennart Regebro]

> > Hey - how about "utensil"!?
>
> But the connotations are 'for household use', which rings the wrong bells
> for me. :)

You know, utensils, thats things you use yourself. For household use. But if
you have big problems, you call the service people. :-)
So it's not a bad distinction.

But anyway: I re-read chapter 5 of the tutorial too see if I could get some
clarity, and I didn't. This was the part that cause the most confusion:

    "Utilities can be registered in specific locations (e.g. folders) in a
    Zope object system. By passing an object to getUtility, we
    cause local utility registries, if any, to be searched."

What is ment here? This sounds suspiciously like Zope
ackui...aqcuic..aqcuision(?) magick. Are
you saying that you register utilities in the ZODB? Because if you do, I
can't see any difference between utilities or services at all. I first
thought that utilities was stored on disk and not as objects in the ZODB,
which seems logical too me, but now I'm just confused.

I also see a lot of references too how things are "looked up". I completely
fail too see in what way that is significant. If you find a service by name
(through the white pages) or by interface definition (through the yellow
pages) it's still a service. And in fact, it's a service even if it's not in
any phone book.  :-)
So whether it's registered in some other service is not important, and
neither is in what way you find it.

*** It is what it DOES that is the important thing. ***
If services and utilities should have different names, they have to BEHAVE
differently, or be USED differently. Otherwise the name split will only
cause massive confusion.

*** Summary: ***
I can see two types of objects here:

1. A class, of which instances lie in the ZODB, that has an internal state
changeable by functions or userinterface, which other objects will ask
to perform actions, which may depend on this internal state.
I would call these "Services".

2. A class, which is not instanciated in the ZODB, has no internal state,
which has functions that perform actions on objects that are passed to the
function.
I would call these Tools or Toolboxes. Or Utilities or Utensils, possibly.

I'm not sure which of these the "Postal" object in the tutorial is. It
doesn't seem to reside in the ZODB, it doens't have a user interface, and no
changeable internal state. That makes it a "Tool", but in real life, this
object would have a user interface with a view to manage the postal code to
location mappings. And then it would be a "Service".

I'm confused.