| |
- With other approaches to OO in Tcl having been around for a while, why offer yet another one?
-
We aspire to stand on the shoulders of giants. In particular, TclOO, XOTcl, and iTcl are on
their own development paths, with an ongoing philosophy and design approach. The motivation
for Toe was a desire to offer a full-featured OO system that allows complexity to become
more manageable through additional structures, which are themselves maintainable, easy to use,
reusable, and crisply clear in conveying a design intent. The elementary structures include
object-oriented classes, interfaces and mixins, all of which can specify one or more
methods. These structures can be related and aggregated to build higher-order groupings
of collaborating classes, notably including frameworks. The "easy to use" aspect relies
on classes, to be constructed by specification; on interfaces, to declare an API and to define
the essential coupling in an extensible framework; and on mixins, to address cross-cutting
concerns and the separation of concerns. As with other approaches, Toe-recognized classes
can be revised after construction, and Toe-supported objects can even be revised in situ.
New features appearing in Tcl 8.5, including especially dicts and namespace ensembles,
made the development of Toe timely.
- Do I need to know Java and/or C++ to use Toe effectively?
-
You don't need to be a good programmer in Java or C++, but you should understand the
essential features of object-oriented programming languages in general. Developers
new to object-oriented programming are certainly welcome, but this is probably not the
easiest place to get started.
- How are Tcl namespaces related to the classes and objects
that Toe recognizes?
-
Each instantiation of a class corresponds to a fully populated Tcl namespace. Toe creates
and maintains an object template for each class, based on a class specification,
and then populates a namespace with the template, and proper substitutions, in order to
create an instance. Toe also adds tailored namespace ensembles,
so that object commands properly reference related namespaces and runtime services.
The organization of namespaces is implementation-dependent, but all namespaces
managed by Toe are somewhere under the root namespace, ::toe.
- How does the object-oriented approach of Toe fit with Tk widgets?
-
A fundamental and unavoidable difference exists between Tk widgets and object-oriented
design. Tk widgets are structured in a containment hierarchy, whereas OO classes are
structured in an inheritance hierarchy. To use a term of art, the impedance between
a set of related programmable objects and a set of related graphical widgets can be
reduced by design, but not eliminated.
The encapsulation of widgets in objects is encouraged anyway, so that introspection
services and cross-cutting aspects can be applied to widget-containing objects.
See, for example, the Samples section.
- Why is there no root "Object" class, as in Java, and what is lost without it?
-
This was a design decision that should only affect how certain features are implemented.
A root "Object" class provides one way to provide introspection on any object,
to support heterogenous object collections, and to support other runtime services
through an object hierarchy. It works best in a setting where everything derives from an
object. The design of this package relies instead on the notion of a "runtime" service,
which may also be accessed by conventional Tcl commands in the course of procedural
programming.
- Does the common class object provide any metaclass services?
-
The notion of metaclass really doesn't apply to this package. Toe uses the term,
"common," in a sense similar to "static" in Java and C++. Thus the common object contains
the variables and methods of the class that were specified as "common," and is accessed by
the class name as a command. By definition, when the specification for a class includes only common
members, the common object for a class implements the "Singleton" design pattern.
- When implementing an interface, can the names of method
arguments differ between the class' version and the interface's version?
-
Yes, the argument names can differ. A method "signature" in this package consists of the
method name and the number of arguments. The keyword, "args," is effectively a wild card
for one or more arguments. If no arguments are specified in the interface declaration,
then no arguments should be specified in the class definition. Also, a method's return
value is not part of its signature, and is not checked.
- How does using Toe affect executable performance?
-
In general, OO programming is not a pathway to improved performance -- of the code, that is.
Plus, the output of Toe is scripted Tcl code, so you probably won't see measurably
improved performance. However, Toe enables different designs, with trade-offs
that might affect performance favorably. The design trade-off
example shows how a design choice can affect code performance.
Improved performance is more likely in
future versions of Toe that increasingly rely on the Tcl core, including TclOO.
Real performance improvement is anticipated when an OO appoach emerges
for effectively utilizing multiple cores.
|
|
|
|
