[ZODB-Dev] Re: StandaloneAdaptableStorage

[Shane Hathaway]

Jeff Kowalczyk wrote:
> My interest is with a package name that reflects that there will be
> a lot of plug-ins for various parts of AdaptableStorage someday,
> and the namespace of specialized storages, mappers and other parts,
> as well as composite combinations will in time be fortunately
> crowded.
> 
> It seems that AdaptableStorage will be offering the kinds of code-
> executes-when hooks that Aspect Oriented Programming does, with a
> general focus on persistence and included support for persisting by
> ZODB.
> 
> AdaptableStorage seems hard to name because the package is (I
> think) aspect machinery. I don't know what I'd call the internals
> of the AspectJ compiler, either.

I've also been trying to figure out the relationship between AOP and AS. 
  Here is one distinction: AOP is interested in modifying the live 
behavior of classes, while AS is only interested in instance data.  AS 
could be used to modify the behavior of instances, but that's not a 
direction I've been planning.

I think AOP modifies classes, not instances, so a Python implementation 
of AOP would probably involve metaclasses.  Actually, I've had a hard 
time seeing AOP as anything but an attempt to escape the rigid 
boundaries of Java.  I'm wondering if the lack of implementations of AOP 
in other languages is due to a lack of need.

I used the name "aspect" to name one of the interfaces, though 
(IAspectSerializer).  This might not be a good decision.  On the one 
hand, you could say that AS provides object persistence aspects, a 
natural cross-cutting concern.  But on the other hand, an aspect 
serializer doesn't necessarily serialize AOP aspects--it serializes any 
part of an object.  If AS depended on AOP, I might name the interface 
ISerializationAspect instead, emphasizing that implementations of the 
interface are among many kinds of aspects.  But since AS does not depend 
on AOP, I think I should replace the name "aspect" with a synonym to 
avoid confusion.  Maybe "facet".

> If that assessment sits well, it seems that we could find a
> comfortable coexistence with aspect terminology by expecting that
> machinery implementing AS to have its own naming peculiarities, but
> that the specializations, strategies, and mappings that developers
> create with it could then be named in aspect-fashion.
> 
> Perhaps this anticipation of a great many small and large
> specializations will suggest a name more related to the resulting
> customizations than about the core and first-tier add on
> implementation components.
> 
> So, what about some brainstorming in the word family:
> 
> Persistence Aspects Library
> 
> pal
> PAL
> palib
> pasplib
> perasplib
> paf       (framework)
> PAF

Not bad, though to me, PAF is Personal Ancestral File. :-)

How about Adaptable Persistence Library?  "aplib"... or maybe "apelib", 
giving me an obvious choice for a mascot! ;-)

> Perhaps Standalone AdaptableStorage decomposes to a series of
> smaller extensible libraries:
> (aspectlib, persistlib, mapperlib, storagelib, zodblib, zopelib)
> grouped underneath a catchier top-level name.

Yes, definitely, though the "lib" suffix won't be necessary in the 
subpackages.

Shane