The Zope Component Architecture: the Tetris Effect

Back to the subject: the Tetris Effect.

You are certainly familiar with the Tetris game.

The object of the game is to manipulate tetrominoes to make them fit on an horizontal line. The shapes can fit well together as long as they are oriented correctly. As the game goes on, an entire stack is created from the blocks.

I believe that this a good metaphor for the Zope Component Architecture: one defines components by using interfaces, one defines rules for connecting components (adapters) and one combines the various components to create an entire architecture (application, framework, ...).

The components have to fit well otherwise the architecture will have "gaps".

Some developers can focus on the low-level stack, others can focus on the intermediate stack and others on the top layers

I would claim that, as of today, only the lower stack exists in Zope3, with the exception of some "vertical blocks" that span from the bottom to the top. Hence the game has just begun. We still need to see how the players will create and arrange the blocks.

Replacing blocks

The Zope Component Architecture promises that all components can be replaced. As long as the new component implements the interfaces specified by the components "surrounding" it, it will fit like a glove in the structure.

This is true technically, however practically components can be replaced only once, i.e. the mechanism defined for that (called "overriding") will fail if two different component providers override the same component.

Hence the question: in which way is the mechanism designed for replacing existing components conceptually differs from monkey-patching? If two developers replace the same component, a configuration conflict will occur. The difference is that the ZCML setup will detect the conflict and the server will not start, but in which way does the CA solve the problem?

It can be argued that new components can be registered under a different name, for instance there are such things as named adapters and named utilities that makes it possible to register several components providing the same interfaces but under different names. However the problem is that other components in the rest of the architecture will not necessarily do a lookup by name, hence components registered by name will simply be ignored.

I can also be argued that local components (e.g. local utilities) can be used for customizing existing components by overriding them locally, however this is done through containment by looking for the nearest site, but if other components do a global lookup as it is often the case, the local components will never be used.

Creating a high-level stack

This is a thorny issue: casual developers want simple APIs, that lead to produce code that can be read and understood like prose. But the CA does not encourage to write prose really (see my previous post). It is clear that there is a conflict of interest. One solution would be to create an intermediate stack above the low-level stack, i.e. a simpler API for developers that are not interested in knowing about the internals of Zope3.

The problem is that creating such a "simplified" stack basically means to not leverage the components architecture by avoiding such arcane idioms as "queryUtility", "getMultiAdapter", "isProvidedBy", ... (which for a casual developer mean nothing).

But the need for a simpler API may be needed in any case but for another simple reason: such idioms as "interfaces", "utilities", "adapters" expose in many cases the implementation details of concepts, but the implementation is not equal to the concept.

There is a confusion for instance between interfaces and types: interfaces can be used to implement typing, but typing can be implemented in many other ways (as in Zope2, using class attributes). Views are implemented using multi-adapters, but they could be implemented in many other ways, also registries are implemented using utilities, ...

TO BE CONTINUED