Simple TclOO and static class variables

The discussion of class-side slots for TclOO is instructive in light of Carl Sassenrath's blog on defining "simple" in Rebol and in-the-large.  But in the real world things are not so simple.

The TclOO architect offers his snippet from the view of the code internals of his framework.

Tcl 8.6 is in a slow beta while Rebol3 remains alpha - and in fairness TclOO was already a library for 8.5

A Curl (as in www.curl.com) architect in Boston once gave me his take on Tcl ... but again, in fairness, not having access to the internals of how mixins are implemented in Curl ...

The simple view: use traits where they are useful in maintaining separation.  Much harder: to get a project to adopt traits effectively (e.g., non-HTML output for Smalltalk Seaside or Scala Lift.)  Perhaps not possible: getting traits into ObjectIcon.

Anecdote: the Avro Arrow had a compontentized "open-bay" in its belly - long before the ISS universal docking spec.

Question: is re-motoring aircraft types always "simple" ?  DC-8?  And new wings for C5 Galaxy?  Will the Shuttle engines be re-used?

Question: Should the Canadarm2 have been coded in Erlang or Oz instead of Ada? Erlang would offer X, Oz X, Y and Z.  But for Ada there are tools and staff.

What is the "simple" approach to handling text in the age of Unicode?  My test candidate: Octavio Paz' "Blanco" as the intended "dynamic text".

Curl ValueControl

Here's a challenge for class hierarchies without Traits.

The Curl class ValueControl is noted as follows in the docs:

ValueControl (class)

public abstract ValueControl {inherits Control}

Import from: CURL.GUI.STANDARD. Defined in package CURL.GUI.CONTROL-BASE.

Direct Known Subclasses: ValueControl-of

A superclass for any Control that has a value.

Description

All the Controls with values inherit from this class. It provides abstract accessors for the value, as an any, and an accessor for the expected Type of the value.

Overriding

Don't subclass this class. Subclass ValueControl-of instead.

I added emphasis to the advice. My question is, how might such an intent be enforced in a class hierarchy?  What would you call such a modifier or a macro used to create such a class?

The class in question has the 2 abstract methods value-type and value-as-any but it also implements 2 methods: form-value and has-value?.  In addition, it has a class procedure form-string.  The default constructor for the class is noted as

... : Rest arguments are passed up to Control, which passes them to Visual.

The method form-value is documented as intended for use with controls embedded in HttpForm instances.
It is documented as a getter but not as being abstract yet as intended to be overridden by subclasses.

Here is a snippet from those docs;

The value returned by this getter must be one of the following:

 • String

 • array of String

 • null

Notes

Each control overrides this method to return the value that needs to be sent when the HttpForm that contains this control is submitted.

So why is the method not abstract? Well, because it returns a value of type any - but its subclass is parameterized for types of values.  And here is one more thing that makes Curl fascinating: the leaf classes of these hierarchy branches are not themselves declared as parameterized for a type - and in the case of DateField, the value keyword parameter to the default constructor may be of a possibly-null type - a #DateTime type.

What this may show is that multi-inheritance with partially-abstract classes as mixins or otherwise can be very flexible:

public abstract MultiUIValueControlFrame-of {inherits 

   MultiUIControlFrame, 

   {ValueControl-of tValue}}