An Introduction to the Tingle Programming Language

Dirk van Deun, dirk at

Section 5: Mixins

Note again the contrast between the rule from section 2 to determine the top method in a class, and the scoping rule from section 3. The first is for when an object is accessed "from the outside", with "object.methodname()"; the second is for accesses of methods or variables inside an object, with "methodname()" or "variablename" only. ("Object.variablename" is not allowed; if it were, it would be the "top variable".)

"Virtual" function calls, to abuse C++ terminology, as well as mixin- like behaviour can be obtained by "stepping out of the scope" by using "self.methodname()" instead of "methodname()". Note that this "virtuality" here is a property of the call, not of the method itself.

In Tingle there is no technical difference between mixins and ideas, but the name mixin would typically fit an idea without any intersections, which accesses other methods of the same object through "self", so that it can be mixed into any class that provides the necessary methods. Therefore we recognize the following code snippet as a mixin. It can be mixed into classes that define isEqual and isLess:

as ordered {
   def isGreater(x) { ! (self.isEqual(x) || self.isLess(x)) }
   def isUnequal(x) { ! self.isEqual(x) }

Lacking nesting, the source code of this mixin does not show what ideas it should or should not be mixed with, nor what kind of object "self" will then refer to. As a matter of fact, in the dynamic language that Tingle is, we can mix Ordered into classes that do not provide isEqual and isLess, and so compose broken code. For a very general mixin like this one, all this is not a real problem; but often templates with clean scoping are preferable above mixins.

Contents | Section 6: Templates