[Zope-dev] Why Racks And Specialists Are DataSources (Re: Specialists in Specialists) Specialists)

[mike]

There are three reasons:

Reason #1. There Are No Number 3.

I like very much polynesian counting system which includes only numbers
'one', 'two' and 'many'. It has much sense in computing environment. One
is simple variable. Two is a pair: {key:value}, (a,(b,(c,d))),
object.method and so on. The many is all the rest. How it related to
ZPatterns? Look: 
1. we have *Rack* (level 1)
2. Rack is inserted into (used by) *Specialist* (level 2)
3. Specialist can be inserted into other Specialist, but to do it we
have change Specialist's type (by replacing retrieveItem method). This
is definitely changing of the type because the Specialist gets new
message handler (and changes the signature). Doing this we get new
*ModifiedSpecialist* (level 3).
If we think about two chained specialists we see all the three
levels--not one, not two, not many. There should not be 'three' or
'four' or 'twenty five' levels, I repeat again: one, two, or many.

Reason #2. Allow People Implement ZPatterns Algebra!

Specialists are Aspects. They are much like colored filters which breath
the life into black-and-white pictures. Let's think about the stack of
filters (chain of Specialists again). What do we see? First filter in
the stack (Rack) slightly differs from others. It is much like
terminator in the chain or, from the other end, the source of pictures.
See again. Second filter differs from third and four. Why? Third and
four have added 'retrieveItem' method and second has not. This should be
reimplemented in way which allow painless stacking of the Specialists,
and Rack should be special case of Specialist, which allow no further
cascading. Moreover, Rack is 'colorless' filter with the 'image'
(DataSkin) on its back side, which 'weaves' no aspects but
StorageIndependentPersistence.

Let me invent a small algebra.

1. Let us define a space of roles with points having coordinates
R=(r1,r2,...) where R is 'role meanings' vector or somewhat in this
sense. 
2. There is a zero value with sense 'no role'. If object (point) has no
roles at all it's in the (0,0,...) point. The ZPatterns zero is
DataSkin.
3. Let us define set of operators F which are transforming point
coordinates by changing role meanings. R' = F( R, P), P = (p1,p2,p3...)
where P is parameter vector.
4. Let our operators be instantiable: Fp(R) = F( R, P), P=(p1,p2,...)
5. Now we can do composition: R' = Fa( Fb( Fc( R))), which can mean in
real life:

ThisContextRole = ShoppingCart( Client( ZSession( Rack( DataSkin))))

Looks good? I think yes. The only obstacle is the Rack-Specialist
incompatibility.

Reason #3. I'm too lazy to write retrieveItem each time I need compose
Specialists - I do it too often :-)


==================================

> (Note, by the way, that the DataManager interface doesn't support
> getItem/newItem, so I can't just make Specialist use DataManagers.
> Customizers, for example have no idea what objects they're customizing, so
> they can't support getItem.)


I suggest you set up this (or similar) hierarchy which solve the
problem:

DataManager
    DataSouce
	Specialist
	Rack
	    
and replace 'Racks' tab with the 'DataSources' tab.


Mike