This has turned out to be a very large addition to the project---indeed,
with this release, its comprehensiveness remains elusive, but this is a huge
step in the right direction.
Traits allow for powerful methods of code reuse by defining components that
can be ``mixed into'' classes, almost as if the code were copied and pasted
directly into the class definition. Mixins, as they are so called, carry
with them the type of the trait, just as implementing an interface carries
with it the type of the interface; this means that they integrate into
ease.js' type system such that, given some trait T that mixes into class C
and an instance of C, it will be true that Class.isA( T, inst ).
The trait implementation for GNU ease.js is motivated heavily by Scala's
implementation of mixins using traits. Notable features include:
1. Traits may be mixed in either prior to or following a class definition;
this allows coupling traits tightly with a class or allowing them to be
used in a decorator-style manner prior to instantiation.
2. By mixing in a trait prior to the class definition, the class may
override methods of the trait:
Class( 'Foo' ).use( T ).extend( { /*...*/ } )
If a trait is mixed in after a class definition, then the trait may
instead override the functionality of a class:
Class( 'Foo', { /*...*/ } ).use( T )
3. Traits are stackable: By using the `abstract override' keyword
combination, a trait can override the concrete definition of its
parent, provided that the abstract definition is implemented by the
trait (e.g. by implementing a common interface). This allows overrides
to be mixed in any order. For example, consider some class Buffer that
defines an `add' method, accepting a string. Now consider two traits
Dup and Upper:
Buffer.use( Dup ).use( Upper )().add( "foo" )
This would result in the string "FooFoo" being added to the buffer.
On the other hand:
Buffer.use( Reverse ).use( Dup )().add( "foo" )
would add the string "Foofoo".
4. A trait may maintain its own private state and API completely disjoint
from the class that it is mixed into---a class has access only to
public and protected members of a trait and vice versa. This further
allows a class and trait to pass messages between one-another without
having their communications exposed via a public API. A trait may even
communicate with with other traits mixed into the same class (or its
parents/children), given the proper overrides.
Traits provide a powerful system of code reuse that solves the multiple
inheritance problems of languages like C++, without introducing the burden
and code duplication concerns of Java's interfaces (note that GNU ease.js
does support interfaces, but not multiple inheritance). However, traits also
run the risk of encouraging overly rich APIs and complicated inheritance
trees that produce a maintenance nightmare: it is important to keep concerns
separated, creating classes (and traits) that do one thing and do it well.
Users should understand the implications of mixing in traits prior to the
class definition, and should understand how decorating an API using mixins
after a class definition tightly couples the trait with all objects derived
from the generated class (as opposed to the flexibility provided by the
composition-based decorator pattern). These issues will be detailed in the
manual once the trait implementation is complete.
The trait implementation is still under development; outstanding tasks are
detailed in `README.traits`. In the meantime, note that the implementation
*is* stable and can be used in the production environment. While
documentation is not yet available in the manual, comprehensive examples and
rationale may be found in the trait test cases.
Happy hacking!
These will be supported in future versions; this is not something that I
want to rush, nor is it something I want to hold up the first GNU release;
it is likely to be a much lesser-used feature.
The parser methods are now split into their own functions. This has a number
of benefits: The most immediate is the commit that will follow. The second
benefit is that the function is no longer a closure---all context
information is passed into it, and so it can be optimized by the JavaScript
engine accordingly.
As expected, mixin method invocation is dramatically slower than
conventional class method definitions. However, it is a bit slower than I
had anticipated; future releases will definately need to take a look at
improving performance, which should happen anyway, since the trait
implementation takes the easy way out in a number of instances.
Let's get an initial release first.
Does not yet include many more detailed tests, such as method invocation
times, which will be of particular interest. While definitions are indeed
interesting, they often occur when a program is loading---when the user is
expecting to wait. Not so for method invocations.
The concept of stacked traits already existed in previous commits, but until
now, mixins could not be stacked without some ugly errors. This also allows
mixins to be stacked atop of themselves, duplicating their effect. This
would naturally have limited use, but it's there.
This differs slightly from Scala. For example, consider this ease.js mixin:
C.use( T ).use( T )()
This is perfectly valid---it has the effect of stacking T twice. In reality,
ease.js is doing this:
- C' = C.use( T );
- new C'.use( T );
That is, it each call to `use' creates another class with T mixed in.
Scala, on the other hand, complains in this situation:
new C with T with T
will produce an error stating that "trait T is inherited twice". You can
work around this, however, by doing this:
class Ca extends T
new Ca with T
In fact, this is precisely what ease.js is doing, as mentioned above; the
"use.use" syntax is merely shorthand for this:
new C.use( T ).extend( {} ).use( T )
Just keep that in mind.
More information on this implementation and the rationale behind it will
appear in the manual. See future commits.
(Note the TODOs; return values aren't quite right here, but that will be
handled in the next commit.)
This is a consequence of ease.js' careful trait implementation that ensures
that any mixed in trait retains its API in the same manner that interfaces
and supertypes do.
There does not seem to be tests for any of the metadata at present; they are
implicitly tested through various implementations that make use of them.
This will also be the case here ("will"---in coming commits), but needs to
change.
The upcoming reflection implementation would be an excellent time to do so.
This will allow for additional processing before actually triggering the
warnings. For the sake of this commit, though, we just keep with existing
functionality.
Mike Gerwitz