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.
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.
As described in <https://savannah.gnu.org/task/index.php#comment3>.
The benefit of this approach over definition object merging is primarily
simplicitly---we're re-using much of the existing system. We may provide
more tight integration eventually for performance reasons (this is a
proof-of-concept), but this is an interesting start.
This also allows us to study and reason about traits by building off of
existing knowledge of composition; the documentation will make mention of
this to explain design considerations and issues of tight coupling
introduced by mixing in of traits.
This is a rough concept showing how traits will be used at definition time
by classes (note that this does not yet address how they will be ``mixed
in'' at the time of instantiation).
On Sun, Dec 22, 2013 at 03:31:08AM -0500, Richard Stallman wrote:
> I hereby dub ease.js a GNU package, and you its maintainer.
>
> Please don't forget to mention prominently in the README file and
> other suitable documentation places that it is a GNU program.
This project was originally LGPLv+-licensed to encourage its use in a community
that is largely copyleft-phobic. After further reflection, that was a mistake,
as adoption is not the important factor here---software freedom is.
When submitting ease.js to the GNU project, it was asked if I would be willing
to relicense it under the GPLv3+; I agreed happily, because there is no reason
why we should provide proprietary software any sort of edge. Indeed, proprietary
JavaScript is a huge problem since it is automatically downloaded on the user's
PC generally without them even knowing, and is a current focus for the FSF. As
such, to remain firm in our stance against proprietary JavaScript, relicensing
made the most sense for GNU.
This is likely to upset current users of ease.js. I am not sure of their
number---I have only seen download counts periodically on npmjs.org---but I know
there are at least a small number. These users are free to continue using the
previous LGPL'd releases, but with the understanding that there will be no
further maintenance (not even bug fixes). If possible, users should use the
GPL-licensed versions and release their software as free software.
Here comes GNU ease.js.
The concept of proxy methods will become an important, core concept in ease.js
that will provide strong benefits for creating decorators and proxies, removing
boilerplate code and providing useful metadata to the system. Consider the
following example:
Class( 'Foo',
{
// ...
'public performOperation': function( bar )
{
this._doSomethingWith( bar );
return this;
},
} );
Class( 'FooDecorator',
{
'private _foo': null,
// ...
'public performOperation': function( bar )
{
return this._foo.performOperation( bar );
},
} );
In the above example, `FooDecorator` is a decorator for `Foo`. Assume that the
`getValueOf()` method is undecorated and simply needs to be proxied to its
component --- an instance of `Foo`. (It is not uncommon that a decorator, proxy,
or related class will alter certain functionality while leaving much of it
unchanged.) In order to do so, we can use this generic, boilerplate code
return this.obj.func.apply( this.obj, arguments );
which would need to be repeated again and again for *each method that needs to
be proxied*. We also have another problem --- `Foo.getValueOf()` returns
*itself*, which `FooDecorator` *also* returns. This breaks encapsulation, so we
instead need to return ourself:
'public performOperation': function( bar )
{
this._foo.performOperation( bar );
return this;
},
Our boilerplate code then becomes:
var ret = this.obj.func.apply( this.obj, arguments );
return ( ret === this.obj )
? this
: ret;
Alternatively, we could use the `proxy' keyword:
Class( 'FooDecorator2',
{
'private _foo': null,
// ...
'public proxy performOperation': '_foo',
} );
`FooDecorator2.getValueOf()` and `FooDecorator.getValueOf()` both perform the
exact same task --- proxy the entire call to another object and return its
result, unless the result is the component, in which case the decorator itself
is returned.
Proxies, as of this commit, accomplish the following:
- All arguments are forwarded to the destination
- The return value is forwarded to the caller
- If the destination returns a reference to itself, it will be replaced with
a reference to the caller's context (`this`).
- If the call is expected to fail, either because the destination is not an
object or because the requested method is not a function, a useful error
will be immediately thrown (rather than the potentially cryptic one that
would otherwise result, requiring analysis of the stack trace).
N.B. As of this commit, static proxies do not yet function properly.
- In doing so, abandoned the super identifier (sid) for a more elegant solution with class ids (cid's)
- This permits fast and easy private member swapping via getMethodInstance() in class.js
Mike Gerwitz