Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Nov 16, 2014
  1. update travis urls authored
  2. update name in license authored
Commits on Aug 15, 2014
  1. Merge pull request #30 from yckart/patch-1

    Fixed shapes.js => Rectangle arguments
  2. @yckart

    Fixed shapes.js => rectage

    yckart authored
    Changed properties from `width` / `height` to `w` / `h`
Commits on Jun 30, 2014
  1. use node 0.10 and 0.11 in ci authored
  2. rm the broken prepublish script, omg authored
  3. v5.1.1 authored
Commits on Jun 25, 2014
  1. add a changelog entry for 5.1.0 authored
Commits on Mar 9, 2014
  1. v5.1.0

Commits on Oct 31, 2013
  1. Merge pull request #25 from laughinghan/doc.Bare-comment

    Revise comments for Bare and setting its prototype
  2. @laughinghan
  3. @laughinghan

    Revise comments for Bare and setting its prototype

    laughinghan authored
    Still not perfect but an improvement in some ways
Commits on Oct 29, 2013
  1. Revert "inline the hasOwnProperty check"

    This reverts commit c52a23a.
Commits on Oct 28, 2013
  1. be more defensive when setting .init to the superclass

    This only sets it when it doesn't exist anywhere on the prototype chain,
    rather than when it's set to a falsy value.
  2. inline the hasOwnProperty check

  3. Simplify check if inheriting from a non-Pjs class

    If proto.init is truthy but not a function, like 1 or something, you'll
    get a
        TypeError: Object 1 has no method 'apply'
    which I feel like is excellent behavior.
    If we're inheriting from a Pjs class but `proto.init` is overridden to a
    falsy value, we'll think we're inheriting from a non-Pjs class and set
    `proto.init` to the superclass constructor, which isn't the most
    defensive, fail-early thing to do, but is also what happened prior to
    this commit.
    Really, to be defensive in our non-pjs check, we should check
    `('init' in proto)`, so if `proto.init` is overridden to anything
    but a function it'll TypeError like above.
  4. Don't fail silently if .init isn't a function #cuttingFeatures

    Because of the check for inheriting a non-pjs class, the only way for
    that to happen is if you monkey-patch .init to something that isn't a
    function, in which case you'll get a
        TypeError: Object ${thing you monkey-patched .init to} has no method 'apply'
    which I feel like is excellent behavior.
    <0.4kb now!
  5. Merge pull request #21 from laughinghan/refactor.cosmetic

    Simplify and reduce minified size without reducing functionality
  6. Merge pull request #24 from laughinghan/master

    Cosmetic fixes: delete outdated comment, fix typo
  7. @laughinghan
  8. @laughinghan
  9. @laughinghan

    Inline `isObject` #cosmetic

    laughinghan authored
    Recommend --word-diff (default regex, not '\w+|.'), and GIT_PAGER= so
    that the line in the README won't word-wrap, e.g.:
    $ GIT_PAGER= git show --word-diff
  10. @laughinghan

    Remove unnecessary variable and else-if #cosmetic

    laughinghan authored
    Recommend --word-diff-regex='\w+|.' to view diff.
    I first noticed that we were doing isObject() twice if an object is
    passed as `def` in the first place, and in simplifying that I realized
    we didn't even need `extensions` in the first place.
    `for (var ext in def)` didn't make much sense so I changed the name of
    the iteration variable too.
  11. v5.0.0

Commits on Oct 27, 2013
  1. @laughinghan

    Fix idiomatic subclasses of Pjs classes #backcompatBreaking

    laughinghan authored
    Prior to this commit an idiomatic subclass of a Pjs class would fail
    to inherit the constructor, for example:
    function Subclass(info, moreInfo) {
      // ...
      var arg1 = slightlyChange(info), arg2 = drasticallyChange(moreInfo);
      // ..., arg1, arg2);
    would silently create and discard a new instance of `Superclass` and
    not mutate as `this` as intended.
    Of course, if you're writing your idiomatic subclass of a Pjs class
    by hand, you can just do `this.init(arg1, arg2)` and you're golden.
    However, in [CoffeeScript][1] and even [ECMAScript 6 (Harmony)][2],
    `super(arg1, arg2)` compiles to `, arg1, arg2)`,
    and if you don't define a `constructor`, there's an implicit
    `Superclass.apply(this, arguments)`, which it's pretty lame to
    The fix is a one-liner:
         function C() {
    -      var self = new Bare;
    +      var self = this instanceof C ? this : new Bare;
           if (isFunction(self.init)) self.init.apply(self, arguments);
           return self;
    The only back-compat break is jayferd#9: `this.constructor(arg1, arg2)`
    will also mutate `this`, being fundamentally equivalent to
    `, arg1, arg2)`. But it occured to me that this isn't a
    problem for idiomatic classes because to instantiate them you do
    `new this.constructor(arg1, arg2)`, which we can make work for Pjs
    classes too, and just say that in that ambiguous case you use `new` to
    "force" instantiation. Note that for varargs you just do
    `this.constructor.apply(null, argsList)` as ever. (Btw we totally forgot
    to suggest `` in jayferd#9.)
    I really think that given the tradeoff of being a well-behaved class
    system vs the edge case of a factory method, especially considering how
    easy it is to just use `new`, we should favor being well-behaved.
  2. @laughinghan
Something went wrong with that request. Please try again.