1
0
Fork 0
Commit Graph

499 Commits (62414a4294fccd47084e2654f219120ac745d151)

Author SHA1 Message Date
Mike Gerwitz 62414a4294 Overriding vanilla prototype methods no longer errors
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.
2014-04-26 00:57:26 -04:00
Mike Gerwitz b372fcd722 ClassBuilder.isInstanceOf now defers to type
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.
2014-04-26 00:57:25 -04:00
Mike Gerwitz c31d1b3eb3 Added isCompatible method to interfaces
There is a great amount of rationale in the test case added in this commit.
2014-04-26 00:57:25 -04:00
Mike Gerwitz fd404fc69f Named trait staging object
The syntax Trait( "Name" ) now works as Class( "Name" ), permitting
implementing interfaces and extending from the staged object.
2014-04-26 00:42:29 -04:00
Mike Gerwitz 42b52bb692 Exposing keyword bit values and bitmasks
Available through property parser interface
2014-04-20 02:40:36 -04:00
Mike Gerwitz fd7e0cbef7 Support for implicit private members
Members with underscore prefixes are now implicitly private, which follows
common convention. See test case comments for rationale.
2014-04-20 02:28:38 -04:00
Mike Gerwitz 1079630bd4 Can now build multiple performance logs
`make perf` will build, by default, perf.log, but you may also build perf.*;
for example:

  $ make perf.1
  # make some changes
  $ make perf.2

This allows comparing changes easily.
2014-04-09 20:01:33 -04:00
Mike Gerwitz e85a7653e8 Generic performance test output
Styled for display to user as the tests are running, but data are written to
perf.out for additional processing.

You can style the perf.out file cleanly using:
  $ column -ts\| perf.out
2014-04-09 20:01:33 -04:00
Mike Gerwitz 85cc251adf Added baseline tests for prototype method and function call invocation 2014-04-09 20:00:54 -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 c835641dcb Private methods are no longer wrapped
This is an exciting performance optimization that seems to have eluded me
for a surprisingly long time, given that the realization was quite random.
ease.js accomplishes much of its work through a method wrapper---each and
every method definition (well, until now) was wrapped in a closure that
performed a number of steps, depending on the type of wrapper involved:

  1. All wrappers perform a context lookup, binding to the instance's private
     member object of the class that defined that particular method. (See
     "Implementation Details" in the manual for more information.)
  2. This context is restored upon returning from the call: if a method
     returns `this', it is instead converted back to the context in which
     the method was invoked, which prevents the private member object from
     leaking out of a public interface.
  3. In the event of an override, this.__super is set up (and torn down).

There are other details (e.g. the method wrapper used for method proxies),
but for the sake of this particular commit, those are the only ones that
really matter. There are a couple of important details to notice:

  - Private members are only ever accessible from within the context of the
    private member object, which is always the context when executing a
    method.
  - Private methods cannot be overridden, as they cannot be inherited.

Consequently:

  1. We do not need to perform a context lookup: we are already in the proper
     context.
  2. We do not need to restore the context, as we never needed to change it
     to begin with.
  3. this.__super is never applicable.

Method wrappers are therefore never necessary for private methods; they have
therefore been removed.

This has some interesting performance implications. While in most cases the
overhead of method wrapping is not a bottleneck, it can have a strong impact
in the event of frequent method calls or heavily recursive algorithms. There
was one particular problem that ease.js suffered from, which is mentioned in
the manual: recursive calls to methods in ease.js were not recommended
because it

  (a) made two function calls for each method call, effectively halving the
      remaining call stack size, and
  (b) tail call optimization could not be performed, because recursion
      invoked the wrapper, *not* the function that was wrapped.

By removing the method wrapper on private methods, we solve both of these
problems; now, heavily recursive algorithms need only use private methods
(which could always be exposed through a protected or public API) when
recursing to entirely avoid any performance penalty by using ease.js.

Running the test cases on my system (your results may vary) before and after
the patch, we have:

  BEFORE:
  0.170s (x1000 = 0.0001700000s each): Declare 1000 anonymous classes with
    private members
  0.021s (x500000 = 0.0000000420s each): Invoke private methods internally

  AFTER:
  0.151s (x1000 = 0.0001510000s each): Declare 1000 anonymous classes with
    private members
  0.004s (x500000 = 0.0000000080s each): Invoke private methods internally

This is all the more motivation to use private members, which enforces
encapsulation; keep in mind that, because use of private members is the
ideal in well-encapsulated and well-factored code, ease.js has been designed
to perform best under those circumstances.
2014-03-20 23:43:24 -04:00
Mike Gerwitz 744696b1a7
[copyright] Copyright update 2014-03-15 23:56:47 -04:00
Mike Gerwitz cc43f4b339 Prohibiting trait getters/setters 2014-03-15 21:16:27 -04:00
Mike Gerwitz eab4dbfe4d Throwing exception on trait static member
These will be supported in future versions; this is not something that I
want to rush, nor is it something I want to hold up the first GNU release;
it is likely to be a much lesser-used feature.
2014-03-15 21:16:27 -04:00
Mike Gerwitz 3d47443046 Refactored ClassBuilder.buildMembers (dynamic prop parse context)
The parser methods are now split into their own functions. This has a number
of benefits: The most immediate is the commit that will follow. The second
benefit is that the function is no longer a closure---all context
information is passed into it, and so it can be optimized by the JavaScript
engine accordingly.
2014-03-15 21:16:27 -04:00
Mike Gerwitz 7d27bc7969 Exposing Trait module
Oh boy oh boy oh boy!
2014-03-15 21:16:27 -04:00
Mike Gerwitz 255a60e425 Implemented and abstract with mixins properly handled
Classes will now properly be recognized as concrete or abstract when mixing
in any number of traits, optionally in conjunction with interfaces.
2014-03-15 21:16:27 -04:00
Mike Gerwitz 696b8d05a6 Class definition mixin now requires explicit extend
See the rather verbose docblocks in this diff for more information.
Additional rationale will be contained in the commits that follow.
2014-03-15 21:16:27 -04:00
Mike Gerwitz a7e381a31e Mixing method invocation performance tests
As expected, mixin method invocation is dramatically slower than
conventional class method definitions. However, it is a bit slower than I
had anticipated; future releases will definately need to take a look at
improving performance, which should happen anyway, since the trait
implementation takes the easy way out in a number of instances.

Let's get an initial release first.
2014-03-15 21:16:27 -04:00
Mike Gerwitz 433dd4fb7a Trait definition and mixin performance test cases
Does not yet include many more detailed tests, such as method invocation
times, which will be of particular interest. While definitions are indeed
interesting, they often occur when a program is loading---when the user is
expecting to wait. Not so for method invocations.
2014-03-15 21:16:27 -04:00
Mike Gerwitz 55e993a74d Non-private properties now expressly prohibited in trait dfns
:O What?! See Trait/PropertyTest for more information on why this is the
case, at least for now.
2014-03-15 21:16:27 -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 88713987e2 Mixin use method calls can now be chained
Syntatic sugar; could have previously extended explicitly and then mixed in.
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 14bd552361 Trait can now implement interfaces
Note the incomplete test case: the next commit will introduce the ability
for mixins to override methods that may have already been defined.
2014-03-15 21:16:27 -04:00
Mike Gerwitz c8023cb382 Trait method return value implementation correction and testing 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
Mike Gerwitz 8d81373ef8 Began named trait implementation
Does not yet support staging object like classes
2014-03-15 21:16:27 -04:00
Mike Gerwitz 26bd6b88dd Named classes now support mixins 2014-03-15 21:16:27 -04:00
Mike Gerwitz 455d3a5815 Added immediate partial class invocation support after mixin 2014-03-15 21:16:27 -04:00
Mike Gerwitz 897a4afab4 Added support for mixing in traits using use method on a base class 2014-03-15 21:16:27 -04:00
Mike Gerwitz 999c10c3bf Subtype mixin support 2014-03-15 21:16:27 -04:00
Mike Gerwitz 451ec48a5c Objects are now considered types of class's mixed in traits
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.
2014-03-15 21:16:27 -04:00
Mike Gerwitz ee46fc2182 Began testing class subtyping with mixins 2014-03-15 21:16:27 -04:00
Mike Gerwitz 513bd1a733 Added test case for visibility escalation internally
For completeness, since this is how I originally observed the issue fixed in
the previous commit.
2014-03-15 21:16:26 -04:00
Mike Gerwitz bcada87240 [bug fix] Corrected bug with implicit visibility escalation
See test case comments for details. This wasted way too much of my time.
2014-03-15 21:16:26 -04:00
Mike Gerwitz 66cab74cc1 Initial trait virtual member proxy implementation
This has some flaws that should be addressed, but those will be detailed in
later commits; this works for now.
2014-03-15 21:16:26 -04:00
Mike Gerwitz b7a314753a Began implementing virtual trait methods
These require special treatment with proxying.
2014-03-15 21:16:26 -04:00
Mike Gerwitz 40e287bfc3 Warning no longer issued when overriding weak method appearing later in dfn obj 2014-03-15 21:16:26 -04:00
Mike Gerwitz 1b323ed80b Validation warnings now stored in state object
This will allow for additional processing before actually triggering the
warnings. For the sake of this commit, though, we just keep with existing
functionality.
2014-03-15 21:16:26 -04:00
Mike Gerwitz dac4b9b3a1 The `weak' keyword can now apply to overrides
Well, technically anything, but we're leaving that behavior as undefined for
now (the documentation will say the same thing).
2014-03-07 00:47:43 -05:00
Mike Gerwitz b04a8473b8 Implemented abstract traits
This is just an initial implementation, so there may be some quirks; there
are more tests to come.
2014-03-07 00:47:43 -05:00
Mike Gerwitz 987a2b88ec Classes can now access trait protected members
Slight oversight in the original commit.
2014-03-07 00:47:43 -05:00
Mike Gerwitz c10fe5e248 Proxy methods may now override abstract methods
The method for doing so is a kluge; see the test case for more info.
2014-03-07 00:47:43 -05:00
Mike Gerwitz 548c38503f Added support for weak abstract methods
This adds the `weak' keyword and permits abstract method definitions to
appear in the same definition object as the concrete implementation. This
should never be used with hand-written code---it is intended for code
generators (e.g. traits) that do not know if a concrete implementation will
be provided, and would waste cycles duplicating the property parsing that
ease.js will already be doing. It also allows for more concise code
generator code.
2014-03-07 00:47:43 -05:00
Mike Gerwitz 18ac37c871 Added support for `weak' keyword
Note that, even though it's permitted, the validator still needs to be
modified to permit useful cases. In particular, I need weak abstract and
strong concrete methods for use in traits.
2014-03-07 00:47:43 -05:00
Mike Gerwitz 93eda3c14b Added tests proving traits' scopes are disjoint from classes' and each others'
This was the original motiviation behind, and is a beautiful consequence of,
the composition-based trait implementation (see
<https://savannah.gnu.org/task/index.php#comment3>).
2014-03-07 00:47:43 -05:00
Mike Gerwitz e44ac3190b Protected trait methods are now mixed in 2014-03-07 00:47:43 -05:00
Mike Gerwitz 3724b1bc0d Re-implemented mixin error for member name conflicts 2014-03-07 00:47:43 -05:00
Mike Gerwitz 71358eab59 Began implementing composition-based traits
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.
2014-03-07 00:47:42 -05:00