1
0
Fork 0
Commit Graph

7 Commits (016bb1362bd0be1e9a1e901186a3e2b8bd0ec72d)

Author SHA1 Message Date
Mike Gerwitz 016bb1362b
Copyright year update for all files modified since 0.2.8
* lib/MemberBuilderValidator.js: Updated copyright year.
* lib/class.js: Updated copyright year.
* test/Class/ConstructorTest.js: Updated copyright year.
* test/Class/ExtendTest.js: Updated copyright year.
* test/Class/GeneralTest.js: Updated copyright year.
* test/MemberBuilderValidator/MethodTest.js: Updated copyright year.
* test/Trait/LinearizationTest.js: Updated copyright year.
* test/Trait/VirtualTest.js: Updated copyright year.
2017-11-04 15:08:02 -04:00
Mike Gerwitz bb3956f1b4
Fix trait __inst
`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.
2017-11-02 00:15:31 -04:00
Mike Gerwitz 90fd1a8d08
`override' implies `virtual'
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'.
2017-06-30 02:01:40 -04:00
Mike Gerwitz 82a02c0081 [copyright] Copyright assignment to the FSF
Thanks to Donald Robertson III for his help and guidance during this
process.
2014-04-09 19:05:07 -04:00
Mike Gerwitz 3005cda543 Support for stacked mixins
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.
2014-03-15 21:16:27 -04:00
Mike Gerwitz 8480d8f92c Added support for abstract overrides 2014-03-15 21:16:27 -04:00
Mike Gerwitz 6473cf35ae Began Scala-influenced linearization implementation
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.)
2014-03-15 21:16:27 -04:00