Abstract

This TIP proposes a system that enables a more flexible system of handling all
declarations relating to classes and objects that resolve to control over a
list of things. This system, which will use TclOO to configure itself, will
enable the scripting of additional mechanisms for manipulating declarations
and will also include a change to the default behavior of the filter and
variable declarations, where the standard "replace everything" behavior
was found to be non-obvious in practice. In order to enable this, the exact
behavior of the unknown method mechanism will be slightly varied.

Rationale

Substantial deployment experience with TclOO now exists, and one of the things
that has been consistently found to be surprising has been the way that the
variable declaration (part of oo::define and oo::objdefine)
replaces the current list of declared variables. Personal experimentation has
indicated that the filter declaration is just as surprising, though it
is admittedly less frequently used. Therefore it is desirable to alter the way
such declarations work so that they append to the list of variables (or
filters, depending on what is being declared).

However, if this is being done then there is a need for substantial complexity
to be added; there must be some way to set the list of things being
declared or clear it as well as appending to it. Moreover, at the base level
both superclass and mixin declarations are basically the same
structure; a list of things. For moral consistency, it becomes necessary to
apply the same basic rules there, though with different defaults; in practice
the default "replace" rule is suitable in for both those two cases.

Note that for the declarations not mentioned, their natural model is not that
of a list so there is no underlying unity of declaration system possible at
this level. They will be left unchanged by this TIP.

Proposed Change

My proposed solution is the introduction of a new standard class,
::oo::Slot, whose instances will provide configuration services to the
oo::define and oo::objdefine commands. The proposed definition of
the class will be this:

It will be up to the instances (whose names do not form part of this
specification) to define appropriate interpretations for the Get,
Set and --default-operation methods, with the last being envisaged
as an ideal fit for being done by one of the other methods, with the
connection being made by forward.

In order to enable this, a small change is required to the unknown
method mechanism. This change is that in the case that there is no method name
at all passed to a call into an object, that will have to be handled by
passing into the unknown method mechanism. This will only have a significant
impact on declarations of the unknown method where the formal argument
list was args; in the other cases there is typically a required first
formal argument and that leads under the current implementation of methods to
the same error message as currently defined. Since this is a rare case of a
rarely used mechanism, I judge that this is likely to be an acceptable
semantic change.

The real major change here is that for certain things (i.e., variable,
superclass, mixin and filter declarations) it becomes
trickier to use these with named things whose names start with a "-"
character. I believe this to be a reasonable and minimal trade-off, given that
in return we are getting more natural usage for many users while maintaining a
standard mechanism for a whole way of handling declarations.