1
0
Fork 0
Commit Graph

1018 Commits (b372fcd722f3e2b5f3294c12ec5b9001cf90331a)

Author SHA1 Message Date
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 597ac2d7d9
Version bump 0.2.2-dev
Whoops! Meant to do this a lot sooner.
2014-04-26 00:55:18 -04:00
Mike Gerwitz f257a73e1d
Trait named staging object
This implements Trait("Foo"), analogous to Class("Foo"). This was intended
to have existed in the 0.2.0 release, but was overlooked.
2014-04-26 00:52:56 -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 bb98c9afb3
Revert "Removed unnecessary try/catch from isInstanceOf"
This reverts commit 58ee52ad4a.

As it turns out, IE9 allows use of instanceof with special object types, not
just functions. One such example is HTMLElement; its type is `object', whereas
in Firefox and Chromium it is `function'. There is no reliable way to perform
this detection.

Therefore, the try/catch here is more reliable.
2014-04-24 21:32:49 -04:00
Mike Gerwitz 8391bc007d
No longer using __dirname in requires
I feel like I originally did this because older versions of node didn't like
relative paths (unless maybe the cwd wasn't in NODE_PATH). Regardless, it works
now, and this is cleaner.

Further, I noticed that __dirname didn't seem to be working properly with
browserify. While GNU ease.js does not make use of it (ease.js uses its own
scripts), other projects may.
2014-04-20 21:11:38 -04:00
Mike Gerwitz a537721ea1
Added documentation for implicit private members 2014-04-20 02:53:02 -04:00
Mike Gerwitz d5965f4672
Added support for implicit private members
Members with an underscore prefix are now implicitly private, which follows
conventions established in many object-oriented languages. This allows for a
concise definition style familiar to prototypal (and I suppose Ruby)
programmers.
2014-04-20 02:41:21 -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 004fbd24ad Added virtual kmask 2014-04-20 02:31:28 -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 1ca7e35963
Version bump 0.2.1 2014-04-17 00:19:56 -04:00
Mike Gerwitz 86a4703a1c
Miscellaneous performance enhancements
These are the beginning of some smaller performance optimizations brought on
by the v8 profiler. This includes removal or movement of over-reaching
try/catch blocks and more disciplined argument handling, neither of which
can be compiled into machine code (permanently, at least). This also removes
some unneeded code, adds some baseline performance test cases, and begins
generic performance test output and HTML generation which will be used in
the future for more detailed analysis.

This is just a starting point; there's more to come, guided by profiling.
The trait implementation needs some love and, since its development is not
yet complete, that will be optimized in the near future. Further, there are
additional optimizations that can be made when ease.js recognizes that
certain visibility layers are unneeded, allowing it to create more
lightweight classes.

Performance enhancements will also introduce the ability to generate a
``compiled'' class, which will generate a prototype that can be immediately
run without the overhead of processing keywords, etc. This will also have
the benefit of generating code that can be understood by static analysis
tools and, consequently, optimizers.

All in good time.
2014-04-17 00:11:27 -04:00
Mike Gerwitz b5ae607096 Began performance test case result HTML generation
This will eventually yield much more useful interactive output.
2014-04-09 20:01:33 -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 58ee52ad4a Removed unnecessary try/catch from isInstanceOf
Was just being lazy.
2014-04-09 20:01:33 -04:00
Mike Gerwitz d23f34da4b Removed try/catch from Interface.extend
Permits more aggressive optimization.
2014-04-09 20:01:33 -04:00
Mike Gerwitz c76178516e Various argument handling optimizations
Permits more aggressive v8 optimization.
2014-04-09 20:01:33 -04:00
Mike Gerwitz a52fcfa1d9 Removed fallback check on each defineSecureProp call
This check was originally added because IE8's implementation is broken.
However, we already perform a test in the `can_define_prop` configuration,
so this is not necessary (it seems to be a relic).
2014-04-09 20:00:54 -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 a1cf650bac
Copyright assignment to the FSF
Copyright for the GNU ease.js project has been assigned to the Free Software
Foundation. This allows the FSF to enforce the project licenses, which is
something that I lack the time and money to do. It further ensures, through
the contract I signed with the FSF, that all distrbutions of GNU ease.js,
and all derivatives, will always ``be on terms that explicitly and
perpetually permit anyone possessing a copy of the work to which the terms
apply, and possessing accurate notice of these terms, to redistribute copies
of the work to anyone on the same terms'' and that the project ``shall be
offered in the form of machine-readable source code''.

Consequently, any contributors to the project (aside from changes deemed to
be trivial) will be required to assign copyright to the FSF; this puts GNU
ease.js on a firm legal ground to prevent complicating enforcement.
Contributors can rest assured that the code they contribute will always
remain free (as in freedom).

I thank Donald Robertson III of the FSF for his help and guidance during
this process.
2014-04-09 19:21:03 -04:00
Mike Gerwitz 6bd42986f7 Added GNU to ease.js license notice in README.md 2014-04-09 19:10:20 -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 9c70904c39
Private method wrapping eliminated
This has wonderful consequences; see branch commits for more information.
2014-03-20 23:55:32 -04:00
Mike Gerwitz 74b4525f00
Added details of private method wrapping exemption to manual 2014-03-20 23:55:16 -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 f9e8390a55
Updated homepage and git repo URLs 2014-03-20 23:42:53 -04:00
Mike Gerwitz b413343e42
Version bump: 0.2.1-dev 2014-03-20 23:41:14 -04:00
Mike Gerwitz 2ebff67b36
Package rename in configure.ac (remove dot) 2014-03-16 01:02:12 -04:00
Mike Gerwitz 38ab859a4c
Version bump to 0.2.0
From 0.2.0-dev
2014-03-16 00:11:47 -04:00
Mike Gerwitz 2665518e01
Added README.traits to distribution 2014-03-16 00:10:11 -04:00
Mike Gerwitz 3a625ccf28
Merge branch 'authors' 2014-03-16 00:06:36 -04:00
Mike Gerwitz 3f28a6ae19 AUTHORS file will now contain and sort by commit count 2014-03-16 00:06:17 -04:00
Mike Gerwitz 97f42a275c Added .mailmap
Join personal and GNU e-mail identities
2014-03-16 00:03:02 -04:00
Mike Gerwitz 10d653825a
Corrected version string generation with empty suffix 2014-03-15 23:57:02 -04:00
Mike Gerwitz 744696b1a7
[copyright] Copyright update 2014-03-15 23:56:47 -04:00
Mike Gerwitz ac1a0368cf
Preliminary support for traits as mixins
This has turned out to be a very large addition to the project---indeed,
with this release, its comprehensiveness remains elusive, but this is a huge
step in the right direction.

Traits allow for powerful methods of code reuse by defining components that
can be ``mixed into'' classes, almost as if the code were copied and pasted
directly into the class definition. Mixins, as they are so called, carry
with them the type of the trait, just as implementing an interface carries
with it the type of the interface; this means that they integrate into
ease.js' type system such that, given some trait T that mixes into class C
and an instance of C, it will be true that Class.isA( T, inst ).

The trait implementation for GNU ease.js is motivated heavily by Scala's
implementation of mixins using traits. Notable features include:

  1. Traits may be mixed in either prior to or following a class definition;
     this allows coupling traits tightly with a class or allowing them to be
     used in a decorator-style manner prior to instantiation.

  2. By mixing in a trait prior to the class definition, the class may
     override methods of the trait:

       Class( 'Foo' ).use( T ).extend( { /*...*/ } )

     If a trait is mixed in after a class definition, then the trait may
     instead override the functionality of a class:

       Class( 'Foo', { /*...*/ } ).use( T )

  3. Traits are stackable: By using the `abstract override' keyword
     combination, a trait can override the concrete definition of its
     parent, provided that the abstract definition is implemented by the
     trait (e.g. by implementing a common interface). This allows overrides
     to be mixed in any order. For example, consider some class Buffer that
     defines an `add' method, accepting a string. Now consider two traits
     Dup and Upper:

       Buffer.use( Dup ).use( Upper )().add( "foo" )

     This would result in the string "FooFoo" being added to the buffer.
     On the other hand:

       Buffer.use( Reverse ).use( Dup )().add( "foo" )

     would add the string "Foofoo".

  4. A trait may maintain its own private state and API completely disjoint
     from the class that it is mixed into---a class has access only to
     public and protected members of a trait and vice versa. This further
     allows a class and trait to pass messages between one-another without
     having their communications exposed via a public API. A trait may even
     communicate with with other traits mixed into the same class (or its
     parents/children), given the proper overrides.

Traits provide a powerful system of code reuse that solves the multiple
inheritance problems of languages like C++, without introducing the burden
and code duplication concerns of Java's interfaces (note that GNU ease.js
does support interfaces, but not multiple inheritance). However, traits also
run the risk of encouraging overly rich APIs and complicated inheritance
trees that produce a maintenance nightmare: it is important to keep concerns
separated, creating classes (and traits) that do one thing and do it well.
Users should understand the implications of mixing in traits prior to the
class definition, and should understand how decorating an API using mixins
after a class definition tightly couples the trait with all objects derived
from the generated class (as opposed to the flexibility provided by the
composition-based decorator pattern). These issues will be detailed in the
manual once the trait implementation is complete.

The trait implementation is still under development; outstanding tasks are
detailed in `README.traits`. In the meantime, note that the implementation
*is* stable and can be used in the production environment. While
documentation is not yet available in the manual, comprehensive examples and
rationale may be found in the trait test cases.

Happy hacking!
2014-03-15 23:50:21 -04:00
Mike Gerwitz 00a4ff6786 README.traits containing remaining TODOs 2014-03-15 22:19:07 -04:00
Mike Gerwitz 0713a9f3d0 Deleted unnecessary trait abstract method in favor of auto-abstract flag
This method was added before this flag existed.
2014-03-15 21:16:27 -04:00
Mike Gerwitz cc43f4b339 Prohibiting trait getters/setters 2014-03-15 21:16:27 -04:00
Mike Gerwitz bfadd9fce9 Added missing trait docblocks 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 316a7dd703 Refactored Traits to use propParse hooks 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 c5b6562d34 Mention of "Traits as mixins" in README.md and manual
No documentation yet; this is planned for the 0.2.1 release to prevent
further delays of the first GNU release.
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