This is not necessary in practice: not only does it break encapsulation, but
it muddies the point of ProtoField---to produce a class prototype.
Yes, decomposition back into a ProtoField type allows for analysis of that
datum, in principle; and that will be the case for certain data (contained
within the opaque compiled datum). But in the case of ProtoField, we do not
need to expose the original datum. Ever.
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.
This fixes a bug that causesd virtual definitions with parameters on classes
that a trait is mixed into to fail, and prevented proper param length
validations in the reverse case.
See test case description for a less confusing description.
When extending a class that is a subtype of a prototype, it would clobber
___$$vis$$, yielding a useless class. See the test case for a detailed
description.
Now that ease.js is a GNU project, it has much broader reach than before.
Since its very existence is controversial, it would be wise (and polite) to
provide a means for others to integrate with libraries written using ease.js
without being forced to use ease.js themselves. Further, ease.js users
should be able to build off of the work of other libraries that do not use
ease.js.
This set of changes introduces a number of interoperability improvements,
documented in the new manual chapter ``Interoperability''. Since it is
documented in the manual, this commit message will not go into great detail;
I wish to only provide a summary.
Firstly, we now have the concept of interface compatibility; while ease.js
classes/etc must still conform to the existing interface requirements, the
rules are a bit more lax for other ECMAScript objects to permit
interoperability with type-checking ease.js code. For example:
var I = Interface( { foo: [ 'a' ] } ),
obj = { foo: function( a ) {} };
Class.isA( I, obj ); // true
This is also a powerful feature for implementing interfaces around existing
objects, as a preemptive interface check (rather than duck typing).
Prototypally extending ease.js classes is potentially problematic because
the constructor may perform argument validations (this is also an issue in
pure prototypal code). As a solution, all classes now have a static
`asPrototype` method, which defers constructor invocation, trusting that the
prototype constructor will do so itself.
Aside from a few bug fixes, there is also a more concise notation for
private members to allow prototypal developers to feel more at home when
using GNU ease.js: members prefixed with an underscore are now implicitly
private, which will satisfy the most common visibility use cases. I do
recognize that some (mostly in the Java community) use underscore *suffixes*
to denote private members, but I've noticed that this is relatively rare in
the JS community; I have therefore not included such a check, but will
consider it if many users request it.
There are many more ideas to come, but I hope that this will help to bridge
the gap between the prototypal and classical camps, allowing them to
cooperate with as little friction as possible.
This was a nasty bug that I discovered when working on a project at work
probably over a year ago. I had worked around it, but ease.js was largely
stalled at the time; with it revitalized by GNU, it's finally getting fixed.
See test case comments for more information.
This is something that I've been aware of for quite some time, but never got
around to fixing; ease.js had stalled until it was revitalized by becoming a
GNU project.
This allows separation of concerns and makes the type system extensible. If
the type does not implement the necessary API, it falls back to using
instanceof.
I missed this in the 0.2.0 release and did not notice in code I've been
writing using traits because the test cases are executed by Node. Sorry to
anyone who may have had trouble client-side.
Mike Gerwitz