This is a bugfix; the bug was introduced in v0.2.3.
Notably, this caused problems in IE<=8 for non-argument traits. The problem
is that `fund.apply( x, undefined )` is not valid in ES3---we must apply an
empty array (or argument list) instead.
This is a bugfix; the bug was introduced in v0.2.3.
Initially, the implementation created a new object with the root object as
its prototype, taking advantage of ECMAScript's native
overrides/fallthroughs. Unfortunately, IE<=8 had a buggy implementation,
effectively treating the prototype as an empty object. So, rather than
alt.Array === root.Array, alt.Array === undefined.
The fix is simply to reference discrete objects.
This is a bugfix; the bug was introduced in v0.2.3.
In ECMAScript 5, reserved keywords can be used to reference the field of an
object in dot notation (e.g. method.super), but in ES3 this is prohibited;
in these cases, method['super'] must be used. To maintain ES3 compatiblity,
GNU ease.js will use the latter within its code.
Of course, if you are developing software that need not support ES3, then
you can use the dot notation yourself in your own code.
This does not sway my decision to use `super`---ES3 will soon (hopefully)
become extinct, and would be already were it not for the terrible influence
of Microsloth's outdated browsers.
Specifically, aae51ecf, which introduces deepEqual changes for comparing
argument objects---specifically, this change:
```c
if ((aIsArgs && !bIsArgs) || (!aIsArgs && bIsArgs))
return false;
```
Since I was comparing an array with an arguments object, deepEqual failed.
While such an implementation may confuse users---since argument objects are
generally treated like arrays---the distinction is important and I do agree
with the change.
This is a bug fix.
If the provided object's constructor is an ease.js type, then the
conventional rules will apply (as mentioned in the test docblock and in the
manual); however, if it's just a vanilla ECMAScript object, then the interop
compatibility checks will be used instead.
The manual already states that this is the case; unfortunately, it
lies---this was apparently overlooked, and is a bug.
A solution for this problem took a disproportionally large amount of time,
attempting many different approaches, and arriving still at a kluge; this is
indicative of a larger issue---we've long since breached the comfort of the
original design, and drastic refactoring is needed.
I have ideas for this, and have already started in another branch, but I
cannot but this implementation off any longer while waiting for it.
Sorry for anyone waiting on the next release: this is what held it up, in
combination with my attention being directed elsewhere during that time (see
the sparse commit timestamps). Including this ordering guarantee is very
important for a stable, well-designed [trait] system.
See test cases for rationale.
I'm not satisfied with this implementation, but the current state of ease.js
makes this kind of thing awkward. Will revisit at some point.
This is an important feature to permit trait reuse without excessive
subtyping---composition over inheritance. For example, consider that you
have a `HttpPlainAuth` trait that adds authentication support to some
transport layer. Without parameterized traits, you have two options:
1. Expose setters for credentials
2. Trait closure
3. Extend the trait (not yet supported)
The first option seems like a simple solution:
```javascript
Transport.use( HttpPlainAuth )()
.setUser( 'username', 'password' )
.send( ... );
```
But we are now in the unfortunate situation that our initialization
procedure has changed. This, for one, means that authentication logic must
be added to anything that instantiates classes that mix in `HttpPlainAuth`.
We'll explore that in more detail momentarily.
More concerning with this first method is that, not only have we prohibited
immutability, but we have also made our code reliant on *invocation order*;
`setUser` must be called before `send`. What if we have other traits mixed
in that have similar conventions? Normally, this is the type of problem that
would be solved with a builder, but would we want every configurable trait
to return a new `Transport` instance? All that on top of littering the
API---what a mess!
The second option is to store configuration data outside of the Trait acting
as a closure:
```javascript
var _user, _pass;
function setCredentials( user, pass ) { _user = user; _pass = pass; }
Trait( 'HttpPlainAuth', { /* use _user and _pass */ } )
```
There are a number of problems with this; the most apparent is that, in this
case, the variables `_user` and `_pass` act in place of static fields---all
instances will share that data, and if the data is modified, it will affect
all instances; you are therefore relying on external state, and mutability
is forced upon you. You are also left with an awkward `setCredentials` call
that is disjoint from `HttpPlainAuth`.
The other notable issue arises if you did want to support instance-specific
credentials. You would have to use ease.js' internal identifiers (which is
undocumented and subject to change in future versions), and would likely
accumulate garbage data as mixin instances are deallocated, since ECMAScript
does not have destructor support.
To recover from memory leaks, you could instead create a trait generator:
```javascript
function createHttpPlainAuth( user, pass )
{
return Trait( { /* ... */ } );
}
```
This uses the same closure concept, but generates new traits at runtime.
This has various implications depending on your engine, and may thwart
future ease.js optimization attempts.
The third (which will be supported in the near future) is prohibitive: we'll
add many unnecessary traits that are a nightmare to develop and maintain.
Parameterized traits are similar in spirit to option three, but without
creating new traits each call: traits now support being passed configuration
data at the time of mixin that will be passed to every new instance:
```javascript
Transport.use( HttpPlainAuth( user, pass ) )()
.send( ... );
```
Notice now how the authentication configuration is isolated to the actual
mixin, *prior to* instantiation; the caller performing instantiation need
not be aware of this mixin, and so the construction logic can remain wholly
generic for all `Transport` types.
It further allows for a convenient means of providing useful, reusable
exports:
```javascript
module.exports = {
ServerFooAuth: HttpPlainAuth( userfoo, passfoo ),
ServerBarAuth: HttpPlainAuth( userbar, passbar ),
ServerFooTransport: Transport.use( module.exports.ServerFooAuth ),
// ...
};
var module = require( 'foo' );
// dynamic auth
Transport.use( foo.ServerFooAuth )().send( ... );
// or predefined classes
module.ServerFooTransport().send( ... );
```
Note that, in all of the above cases, the initialization logic is
unchanged---the caller does not need to be aware of any authentication
mechanism, nor should the caller care of its existence.
So how do you create parameterized traits? You need only define a `__mixin`
method:
Trait( 'HttpPlainAuth', { __mixin: function( user, pass ) { ... } } );
The method `__mixin` will be invoked upon instantiation of the class into
which a particular configuration of `HttpPlainAuth` is mixed into; it was
named differently from `__construct` to make clear that (a) traits cannot be
instantiated and (b) the constructor cannot be overridden by traits.
A configured parameterized trait is said to be an *argument trait*; each
argument trait's configuration is discrete, as was demonstrated by
`ServerFooAuth` and `ServerBarAuth` above. Once a parameterized trait is
configured, its arguments are stored within the argument trait and those
arguments are passed, by reference, to `__mixin`. Since any mixed in trait
can have its own `__mixin` method, this permits traits to have their own
initialization logic without the need for awkward overrides or explicit
method calls.
This is a move to solve a couple issues:
- We shouldn't be adding a ton of non-enumerable stuff to an object---
defineProperty is slow; and
- One object containing all internal data (at least in general; more on
that later) makes ignoring it, copying it, or otherwise operating upon
it a much easier and cleaner task.
Existing functionality is maintained using toString. This is necessary to
support type checking, and to be more consistent with the native Symbol
implementation.
Technically `new FallbackSymbol` is supposed to throw a TypeError, just as
`new Symbol` would, but doing so complicates the constructor unncessarily,
so I am not going to bother with that here.
This is a security-related issue: we want to ensure that the user cannot,
without debugging tools, retrieve certain internal details that may be used
to compromise an implementation.
This will, at least in ES5 environments, prevent its general discovery and
[accidental] use. Of course, any decent debugger will still be able to see
it, so unless ES6 is used, this is not truely hidden.
I do not wholly recall why this was done initially (nor do I care to
research it, since it's not necessary now), but from the looks of it, it was
likely a kluge to handle a poor implementation of some feature.
This will help clean up a little, since it's rude to pollute a prototype
unnecessarily.
Temporary method removed and symbol now provided directly to the trait ctor;
this is needed to retrieve the protected visibility object; there is
currently no API for doing so, and there may never be (providing an API for
such a thing seems questionable).
Of course, if we eventually want to decouple the trait implementation from
ClassBuilder (which would be a good idea), we'll have to figure out
something.
Note that this patch temporarily breaks encapsulation via
ClassBuilder.___$$privsym$$ to expose necessary internal details to Trait;
this will be resolved.
This is the closest we will get to implementing a concept similar to symbols
in pre-ES6. The intent is that, in an ES5 environment, the caller should
ensure that the object receiving this key will mark it as non-enumerable.
Otherwise, we're out of luck.
The symbol string is pseduo-randomly generated with an attempt to reduce the
likelihood of field collisions and malicious Math.{floor,random} overwrites
(so long as they are clean at the time of loading the module).
This will re-run `autoconf` if it is detected that the user is within the
git repository, which will force `configure` to be regenerated; this is
necessary, since `configure.ac` contains the version macros.
This not only resolves the error triggered by the use of `super`, but also
is more proper, since that is what ease.js is being developed for; I handle
all ES3 fallback considerations myself.
Note that the build will now produce warnings, but the lines producing them
will be removed shortly in favor of a new API.
This was motivated by Git itself, which uses `git describe` output to
generate the version number relative to the last tag. The format of it fits
fairly cleanly into the existing ease.js versioning scheme, but the m4
macro had to modified slightly to handle additional dashes.
Strict mode fails on `typeof` for undefined variables, which was used
outside of strict mode for exactly the purpose of checking for undefined
variables! This check will work in either case.
During its initial development, no environments (e.g. Node.js, Chromium,
Firefox) supported strict mode; this has since changed, and node has a
--use-strict option, which is used in the test runner to ensure conformance.
See the introduced test cases for great detail; there was a problem with the
implementation where only the public API of the abstract trait object was
being checked, meaning that protected virtual methods were not found when
peforming the call. This was not a problem on override, because that proxies
to the protected member object (PMO), which includes protected members.
This allows invoking any arbitrary method of a supertype. This is needed,
for example, if some method `foo` is overridden, but we wish to call the
parent `foo` in another method; this is not possible with __super:
var C = Class(
{
'virtual foo': function() { return 'super'; }
} );
var SubC = C.extend(
{
'override foo': function() { return 'sub'; },
superfoo: function() { return this.foo.super.call( this ); }
} );
SubC().superfoo(); // 'super'
Obviously, __super would not work here because any call to __super within
SubC#superfoo would try to invoke C@superfoo, which does not exist.
Mike Gerwitz