This is intended mainly to handle cases where the user forgets the second
argument when extending a class:
Class.extend( Base ) // missing second argument (definition object)
* lib/ClassBuilder.js
(exports.isClass): Move from lib/class.js.
(exports.prototype.build): Throw error if definition object is a class.
* lib/class.js (module.exports.isClass): Reference `ClassBuilder.isClass'.
* test/Class/ExtendTest.js: Add respective test case.
The previous commit's test case failed in ES3 environments. I'd amend that
commit, but Savannah refuses force pushes, and I can't work around that on
`master'.
* lib/Trait.js (tctor): Assign `__inst' to the public visibility object
rather than `vis'.
Despite working with ES3+, the perceived age of the project is probably a
deterrent, and we really should be showing users the modern way of doing
things.
`impl-details.texi' was _not_ modernized because those details are indeed
specific to ES3.
* doc/classes.texi:
* doc/integration.texi:
* doc/interop.texi:
* doc/mkeywords.texi: Update documentation.
`this.__inst' within trait methods will now correctly resolve to the public
visibility object of the class we're mixed into, rather than
`undefined'. This behavior is consistent with the rest of the system.
* lib/ClassBuilder.js (initInstance): Add `inst' to private metadata. This
is the public visibility object.
* lib/Trait.js (tctor): Initialize concrete trait `__inst' to aforementioned
`inst' metadata value.
* test/Trait/LinearizationTest.js: Add respective test.
* lib/class.js (assertInstanceOf, assertIsA): New methods.
* test/Class/GeneralTest.js: Add respective tests.
* doc/classes.texi (Type Checks and Polymorphism): Add reference for
methods. Update and format text. Add indexes for "polymorphism",
"type checking", and "duck typing".
Having both is confusing. I also think it might be confusing npmjs.org
(which isn't a good reason to modify my tree, but hopefully it'll be a nice
side-effect).
* README: Remove file.
* README.md: Absorb README.
This behavior is consistent with other OO languages like C++ and C# that do
not have virtual methods by default.
This solution isn't ideal, but I don't have time for a larger refactoring
right now. I sat on this change for a good few weeks before committing it
unchanged.
* lib/MemberBuilderValidator.js (validateMethod): Allow override of
supertype overrides.
* test/*: Stripped `virtual' keyword where appropriate.
* doc/classes.texi (Inheritance): Update to state that `override' implies
`virtual'.
Supertypes that extend constructors may now be extended by traits without
completely blowing up. Good feature.
* lib/Trait.js (__tconstruct): Add function.
(createVirtProxy): Use it.
* test/Trait/ClassExtendTest.js: Add test.
My writing style has changed quite a bit since this was first written.
* doc/classes.text (Constructors):
Reword section.
Remove reference to static classes and singletons (we do not want to
encourage such things).
Add mention of good constructor practices.
We can call this a bugfix...it's more of a neglected feature that's
otherwise completely inconsistent with the rest of the system. :)
* lib/Trait.js (createNamedTrait): Support base.
(_createStaging) [extend]: Support base.
* test/Trait/NamedTest.js: Add test.
See test cases for more information. This was a pretty unfortunate and
nasty bug that I discovered while working on a project that uses easejs; it
wasn't something that was found previously because this support was only
added relatively recently, and this problem does not exist if an interface
is used.
* lib/Trait.js (bindSuperCtx): Add function.
(tctor): Use it.
* test/Trait/ScopeTest.js: Add calling context tests.
Autoconf generates INSTALL boilerplate, so I had added it to .gitignore in
the past. Unfortunately, I do include my own INSTALL file, which is present
in the distribution, but has never been committed to the repo!
Thanks to Stefan Schweter for pointing this out to me.
* INSTALL: Added.
* .gitignore (/INSTALL): Removed.
* doc/classes.texi (Defining Classes): Remove the recommendation for using
the `public' keyword always (instead of omitting it), and the reference
stating that it may be required in the future. This is not the case.
Error subtyping (creating your own error types) in ECMAScript is notoriously
crude, and getting it to work intuitively is even harder. ease.js will now
transparently handle all necessarily boilerplate when extending Error or its
subtypes.
Take, for example, the common boilerplate for creating your own Error type:
```javascript
function ErrorSubtype( message )
{
var err = new Error();
this.name = 'ErrorSubtype';
this.message = message || 'Error';
this.stack = err.stack;
this.lineNumber = err.lineNumber;
this.columnNumber = err.columnNumber;
this.fileName = err.fileName;
}
ErrorSubtype.prototype = new Error();
ErrorSubtype.prototype.constructor = ErrorSubtype;
```
There are a number of problems with this:
- That's a lot of boilerplate for any type you wish to create;
- Some of those features may not be supported by your environment
(e.g. column numbers or stack traces);
- The stack trace will include `ErrorSubtype` _itself_ (as the top frame);
and
- Consequently, the `{line,column}Number` and `fileName` will represent
that top frame---the error constructor itself.
With ease.js, it's just like extending any other class/constructor:
```javascript
Class( 'ErrorSubtype' )
.extend( Error, {} );
```
More information can be found in the "Error Subtypes" section of the manual.
Happy Error hacking. Maybe you'll actually want to create them now.
* lib/ctor/ErrorCtor.js (createCtor): Add `after' parameter to be
invoked by `__$$ector$$__' at end of function.
* test/ctor/ErrorCtorTest.js: Add respective tests.
Apparently the SPDX license list used by NPM supports an "or later"
identifier; that's good, as this is an incredibly important distinction; I
was otherwise going to drop it and use my own custom identifier.
* package.json: License field set to GPL-3.0{=>+}
GNU ease.js is a pretty trivial case with respect to reproducibility---not
much goes on during the build aside from concatenation and minification.
Non-determinism is essentially confined to filesystem operations, which can
be rectified by sorting using a static locale's collation sequence (which is
done here).
This does not resolve any concerns with autoconf-installed scripts (those in
tools/), or the distribution tarball file metadata.
Mike Gerwitz