[Zope3-dev] directory hierarchy proposal

[Gary Poster]

All in all I like it a lot as a general direction.  Certainly the 
shorter names will be a blessing, as long as they do not become too 
obscure.  Here are a few niggles.

---

"Don't shy away from using acronyms in package/module names."

This makes me nervous.  That seems an invitation to excessive obscurity. 
  Certainly "zpt" and "dtml" are ok, but what are some unreasonable 
acronyms according to this naming convention?  I think acronyms such as 
zpt will arise of their own accord, while I noticed the proposal itself 
didn't choose "ca" but "component" for ComponentArchitecture...

-1 on this one, or at least elaborate.

---

"Collapse small packages into modules. Interfaces will move into 
interfaces.py of the surrounding package; tests will move into tests  of 
this package."

I did not like seeing zope/app/services/event.py and so on.  I think an 
important elaboration of this is that packages that cannot have 
arbitrary parts added in and removed are ok to compress as the quoted 
recommendation describes, but that "services", and to a lesser degree 
"content", should be allowed to have smaller distinct packages for the 
convenience of being able to drop things in and pull things out.

Discussion points:

   * reading the code, I'm willing to go to one interfaces.py for a 
given subsystem (i.e. service), but I don't want to go to a service 
interfaces.py to muck through *all* the service interfaces in there. 
These are completely different components!

   * a number of the service packages contain a decent amount of code 
and/or interfaces, and the majority of them have no "global" counterpart 
in which to store extra interfaces (as event does).  Being able to group 
them in a directory is good.

   * I feel particularly strongly about this for the two services with 
which I am most familiar, the object hub and the event service.  I'll 
elaborate if requested.

Can we agree on that distinction, or is there a similar compromise that 
might work?

---

what is zope.app.software?  The replacement for ZopeProducts?  That's 
fine, but it wasn't crystal clear to me.

---

I guess the whole magical zcml ending "." thing that duplicates the last 
name until it resolves into a class can now go the way of the dinosaur? 
  I didn't describe that very well: I'm trying to describe 
"Zope.Events.GlobalEventService." resolving to 
"Zope.Events.GlobalEventService.GlobalEventService" and so on.  We can 
get rid of that now?  Or is that still useful somehow?

---

+1 on the rest, as far as I can tell.

Thanks!

Gary



Martijn Faassen wrote:
> Hi there,
> 
> As promised, here's the directory hierarchy renaming proposal. This is
> based on discussions I had with Jim and others last week at the
> Infrae Sprintathon.
> 
> Here are the guidelines used:
> 
> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DirectoryHierarchyReorganization
> 
> and this is the new tree:
> 
> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ProposedDirectoryHierarchy
> 
> Please discuss!
> 
> Please defer discussions of the separation of the view hierarchy in
> particular to a separate thread I'm about to post. Discuss everything
> else here. :)
> 
> Regards,
> 
> Martijn
> 
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev
> 
>