Inheritance

[Irakli Gozalishvili]

Hi Folks,

We have being doing some work to make it easier to inherit (subclass) core components provided by an SDK like: Panel, Tab, Window… We have considered few alternative APIs, but before making a final decision  I would like to also hear input from our

community. Here are three APIs we do consider:

https://gist.github.com/2321738 

Please vote by listing them in order of your preference!

Also, be aware that this will be backwards compatible change so everything will work as it is today. It's just if you want to create SuperPanel out of SDK Panel you will have a way to do that.

Thanks!
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

[Shane Caraveo]

The order you have it in is the order I like.

I prefer the syntax from #1, it feels highly readable. couldn't extend
be protected?

#2 is ok, I could certainly live with it.

Shane

On 12-04-09 5:45 PM, Irakli Gozalishvili wrote:
> Hi Folks,
>
> We have being doing some work to make it easier to inherit (subclass)

> core components provided by an SDK like: Panel, Tab, Window� We have

> considered few alternative APIs, but before making a final decision I
> would like to also hear input from our
> community. Here are three APIs we do consider:
>
> https://gist.github.com/2321738
>
> Please vote by listing them in order of your preference!
>
> Also, be aware that this will be backwards compatible change so
> everything will work as it is today. It's just if you want to create
> SuperPanel out of SDK Panel you will have a way to do that.
>
> Thanks!
> --
> Irakli Gozalishvili
> Web: http://www.jeditoolkit.com/
>

> --
> You received this message because you are subscribed to the Google
> Groups "mozilla-labs-jetpack" group.
> To post to this group, send email to mozilla-la...@googlegroups.com.
> To unsubscribe from this group, send email to
> mozilla-labs-jet...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

[Alexandre Poirot]

#2 and #3 have the benefit to be more explicit. You know immediatly that Type/extend-mix come from api-utils/something.
Whereas #1 can end up being less explicit, when someone do:
  Panel.extend({ ... }); or exports.Panel = Symbiont.extend({ ... });
You will have to know somehow that Panel inherits (most likely indirectly) from Base and can be extended in that way.

I dislike usage of mix() in #1 and #3. It is error prone and less redeable than #2 and current version of base (different than #1).
It adds parentheses over very long objects definition, and you would really like to avoid such ones!

In #2, I don't see the value of having `prototype` AND `implements`, can't we just have one such attribute that can accept object or array ?

Otherwise, I was wondering if something changed in Base. In the current version, we have to do: Color.new(...), whereas you do just : Color(...). Is that an expected improvement ?

I'd go as first choice, either with a version of `extend` that would avoid usage of `mix`, or a `Type` version with a unique `prototype`/`implements` attribute. A second choice would be `Base` without `mix`.
But like Shane, I think I would be able to live with any of these options. As in deep of my heart, I'd just prefer using plain Prototype :)

[Irakli Gozalishvili]

On Wednesday, 2012-04-11 at 10:04 , Alexandre Poirot wrote:

#2 and #3 have the benefit to be more explicit. You know immediatly that Type/extend-mix come from api-utils/something.
Whereas #1 can end up being less explicit, when someone do:
  Panel.extend({ ... }); or exports.Panel = Symbiont.extend({ ... });
You will have to know somehow that Panel inherits (most likely indirectly) from Base and can be extended in that way.

I totally agree with this (that's why it's #3 on my list :), but on the other hand it can be useful (we used that in XPCOM module). 

I dislike usage of mix() in #1 and #3. It is error prone and less redeable than #2 and current version of base (different than #1).
It adds parentheses over very long objects definition, and you would really like to avoid such ones!

In #2, I don't see the value of having `prototype` AND `implements`, can't we just have one such attribute that can accept object or array ?

They denominate different things similar to how mix and extend behave. extend creates decedent of first argument with own properties of second argument. Mix creates an object with properties of all it's arguments. Same goes for prototype and implements, prototype property expresses what would be the ancestor of the result, while implements contains sets of properties to be copied upon result. I think that

Type({

prototype: [ Foo, Bar, Baz ]

   ...

})

  

would be extremely confusing suggesting that type may have multiple prototypes.

Otherwise, I was wondering if something changed in Base. In the current version, we have to do: Color.new(...), whereas you do just : Color(...). Is that an expected improvement ?

 

Yes that's expected. While current objects make few things simpler (like calling ancestor's methods) they make it harder for our users to sub-type constructs we expose:

Class(Panel.prototype.extend(…))

Since we can't change high level APIs from Color() to Color.new I think we should stick to same style in high / low level APIs and more importantly make sub-typeing as nice for our users.

I'd go as first choice, either with a version of `extend` that would avoid usage of `mix`, or a `Type` version with a unique `prototype`/`implements` attribute. A second choice would be `Base` without `mix`.
But like Shane, I think I would be able to live with any of these options. As in deep of my heart, I'd just prefer using plain Prototype :)

Another advantage of #2 vs #1 is that it no longer requires to have both `Base` and `extend` around to do subtypes.  

On Tuesday, April 10, 2012 2:45:20 AM UTC+2, gozala wrote:

Hi Folks,

We have being doing some work to make it easier to inherit (subclass) core components provided by an SDK like: Panel, Tab, Window… We have considered few alternative APIs, but before making a final decision  I would like to also hear input from our

community. Here are three APIs we do consider:

https://gist.github.com/2321738 

Please vote by listing them in order of your preference!

Also, be aware that this will be backwards compatible change so everything will work as it is today. It's just if you want to create SuperPanel out of SDK Panel you will have a way to do that.

Thanks!
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

--
You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.

To view this discussion on the web visit https://groups.google.com/d/msg/mozilla-labs-jetpack/-/MzVYzZtjlYMJ.

[Alexandre poirot]

These API are powerfull. You can do both inheritance and mixins (or whatever name is the more relevant). But it complexify as we pile up things on top of each others.

I'd really like to see others feedback on such important choice. As it is going to affect all our codebase.

2012/4/12 Irakli Gozalishvili <rfo...@gmail.com>

[David Rajchenbach-Teller]

       Hi,

 I would like to understand something about Jetpack: who are the intended end-users? Whenever I heard presentations, I understood that jetpack targeted primarily web developers. If this is correct, you want to keep the programming style close to web-side JavaScript. In particular, I believe that this means not reinventing inheritance.

Just my two cents,
 David

[David Mason]

Hi David,

This is a great point you bring up. However, we have made a shift in
focus this year. If you read the beginning of the roadmap document:
https://wiki.mozilla.org/Jetpack/Roadmap - I tried to lay out some of
the reasons for this shift (though I should also add a section about
jetpack being the best option for extensibility of Firefox on new
platforms).

We are still trying to make sure that the SDK is easier to use than the
traditional XUL tools, but we also want to accommodate this shift in
focus - so not everything will fall into the simplicity that is web
development. Nonetheless, we do need voices, like yours, to help us
gauge this shift and whether we are going too far in complexity - so
thanks!

Dave Mason

> --
> You received this message because you are subscribed to the Google
> Groups "mozilla-labs-jetpack" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/mozilla-labs-jetpack/-/vQ0mplVeeVsJ.

[Wes Kocher]

On an unrelated note, I think we'll hit the project's limit on Daves
sooner than expected. :)
From: David Mason
Sent: 4/12/2012 1:27 PM
To: mozilla-la...@googlegroups.com
Cc: David Rajchenbach-Teller
Subject: Re: [jetpack] Re: Inheritance

[Ben Bucksch]

I use:

function Base() {}
Base.prototype = {
baseFunction : function() {
}
}

function Subclass() {}
Subclass.prototype = {
subclassFunction : function() {
}
}
extend(Subclass, Base);

with:

/**
* Create a subtype
*/
function extend(child, supertype)
{
child.prototype.__proto__ = supertype.prototype;
}

/**
* Copy properties of |source| into |target|
*/
function mixInto(source, target)
{
for (var property in source)
{
if (typeof(target[property]) == "undefined" &&
// avoid execution of getters/setters
!source.__lookupGetter__(property) &&
!source.__lookupSetter__(property))
{
target[property] = source[property];
}
}
}

[Ben Bucksch]

On 10.04.2012 02:45, Irakli Gozalishvili wrote:
> Please vote by listing them in order of your preference!

When selecting from the given choices:
1. base.extend
3. extend-and-mix (close up)
I really dislike 2. declarative, because I have to set .prototype
explicitly (and it's not declarative, FWIW)

> Also, be aware that this will be backwards compatible change so
> everything will work as it is today. It's just if you want to create
> SuperPanel out of SDK Panel you will have a way to do that.

Good. It's important for me that I don't have to reformat my code in
order to use it in Jetpack. If I had to use this type system for my own
code, I would have to reformat a lot.

Ben

[Erik Vold]

fwiw I don't think we should be communicating that we are changing focus, the focus on web/new developers shouldn't be reduced, but the strategy for attracting them should change.  I think focusing on converting traditional addon devs (aka deep integrators) is the right first step for a new strategy though.

E

[David Mason]

I'm not sure we are actively communicating it, other than answering
questions that arise about what we are trying to accomplish. And
certainly we want to keep any and all plans available for public
consumption... that's just what we do ;)

But I do agree with you that converting trad devs is one of the right
first steps. At the same time we also must keep some of our current
development focus on supporting mobile firefox which, in turn, helps us
keep an eye on the future. That future is likely to be one where we are
supporting multiple platforms where XUL is not present - thus, being
able to support traditional devs becomes even more important.

Having said all that, I do feel its important for us to always keep the
"web development" model in mind - where we can. The SDK should be easy
to use, be a similar experience to developing for the web, and have a
small "code footprint" so that its easy for people to contribute.

Dave

On Fri 13 Apr 2012 11:17:56 AM EDT, Erik Vold wrote:
> fwiw I don't think we should be communicating that we are changing
> focus, the focus on web/new developers shouldn't be reduced, but the
> strategy for attracting them should change. I think focusing on
> converting traditional addon devs (aka deep integrators) is the right
> first step for a new strategy though.
>
> E
>
> On Thu, Apr 12, 2012 at 11:27, David Mason <d...@mozilla.com
> <mailto:d...@mozilla.com>> wrote:
>
> Hi David,
>
> This is a great point you bring up. However, we have made a shift
> in focus this year. If you read the beginning of the roadmap

> document: https://wiki.mozilla.org/__Jetpack/Roadmap

> <https://wiki.mozilla.org/Jetpack/Roadmap> - I tried to lay out
> some of the reasons for this shift (though I should also add a
> section about jetpack being the best option for extensibility of
> Firefox on new platforms).
>
> We are still trying to make sure that the SDK is easier to use
> than the traditional XUL tools, but we also want to accommodate
> this shift in focus - so not everything will fall into the
> simplicity that is web development. Nonetheless, we do need
> voices, like yours, to help us gauge this shift and whether we are
> going too far in complexity - so thanks!
>

> --
> You received this message because you are subscribed to the Google
> Groups "mozilla-labs-jetpack" group.

[Erik Vold]

You guys do seem to be heading in the right direction which makes me glad.

Attracting the web devs is the real reason why the addon sdk exists afaict though, so we need to do more than keep that model in mind I think.  Traditional addon devs don't really need the sdk, although it will make their lives easier.  The sdk needs them far more than they need the sdk imho.

E

mozilla-labs-jetpack@googlegroups.com.

To unsubscribe from this group, send email to

mozilla-labs-jetpack+unsub...@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

--
You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.

To post to this group, send email to mozilla-labs-jetpack@googlegroups.com.
To unsubscribe from this group, send email to mozilla-labs-jetpack+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

--
Erik Vergobbi Vold

Email: erik...@gmail.com
Website: http://erikvold.com/

[Paul Morris]

David Rajchenbach-Teller wrote:
> I understood that jetpack targeted primarily web developers. If this
> is correct, you want to keep the programming style close to web-side
> JavaScript. In particular, I believe that this means not reinventing
> inheritance.

+1 from this web developer dabbling in FF add-ons.

But I am probably not the ("deep integrator") target audience for this
functionality. That said and FWIW, I like the sound of "plain & simple"
(#3) over "Backbone like" or "Moo Tools like," but I will gladly defer
to those who know how to evaluate these things!

Cheers,
-Paul

[Irakli Gozalishvili]

I'll try to give little bit more background to answer some of the concerns raised here:

First of all we plan to use one inheritance pattern all over the code base to make it easier to read it and more importantly maintain it. We also want to make it possible for our users to subclass / subtype / derive from exemplars provided by an SDK, which is currently not possible.

I'd be more than happy to use a web standard, but unfortunately there is no such standard, JS is very flexible language and each

JS library / framework has it's own opinionated API for doing inheritance and that is different from project to project. That being said I have carefully chosen APIs that are used by popular web frameworks today and are compliant with our objective of providing necessary security characteristics to the provided exemplars.

 

JS API for doing inheritance involves to much machinery with `.prototype`, that is both verbose and error prone, that is also why all JS libraries / frameworks have an API to do that. Also, in our case it's not only about setting up a prototype chain but also making it temper proof that involves even more machinery and workarounds for some cross compartment platform bugs. 

1. Exemplar constructs provided by SDK will have frozen prototype chain, that will let us keep a promise described in the documentation. Third party code should not be able to change that. This will become even more important once we start landing parts of SDK into Firefox.

2. This means that changing prototype chain at runtime by overriding properties of prototype or even worth `__proto__` is no go! This is not aligned with security goals and non standard (__proto__) will go away eventually.

Main target audience for this API is people hacking on SDK itself. As user you can either follow our API style or do whatever you want to at the end of the day you will get a function with proper `prototype` set up. You can either do all the machinery yourself and give up on security or do more machinery or even use any library to do inheritance. Which BTW is not possible today. Only limitation would be that you won't be able to change anything in exemplars and their prototype chains provided by an SDK (This is intentional to meet our security goals).

Now let me explain each API proposal individually:

# 1

This is similar to most popular JS MVC library today http://backbonejs.org/

It may be good enough, but still little bit risky as third you might deal with `Foo` exemplar that has different `.extend` method

that does completely different thing from what we promise. In addition we need `mix` function to address cases where non-liniar composition is required (backbone does not provides anything for that).

# 2

Very much similar to yet another popular JS framework MooTools `Class`. Unlike #1 function `Type` (or whatever name will end up to be) is provided by SDK and result calling it would be always predictable. In addition it's pretty declarative it's just an object and `prototype` and `implements` properties has no special meaning, it's just `Type` will interpret them to do one particular thing. This is powerful as we may have other function like `XPCOM` that would take same declaration ind interpret those fields differently. 

# 3

Is pretty much low level functions that we'll have either way to implement either #1 or #2, but maybe it's enough. One unfortunate things with #3 is that in order to do inheritance you will have to import both Base, extend.

Regards

--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

--

You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.

To post to this group, send email to mozilla-la...@googlegroups.com.

To unsubscribe from this group, send email to mozilla-labs-jet...@googlegroups.com.

[Irakli Gozalishvili]

On Friday, 2012-04-13 at 07:25 , Ben Bucksch wrote:

On 10.04.2012 02:45, Irakli Gozalishvili wrote:

Please vote by listing them in order of your preference!

When selecting from the given choices:

1. base.extend

3. extend-and-mix (close up)

I really dislike 2. declarative, because I have to set .prototype

explicitly (and it's not declarative, FWIW)

No it's just a optional property in the hash you pass that `Type` interprets specially, other functions may give another meaning. 

 

Also, be aware that this will be backwards compatible change so

everything will work as it is today. It's just if you want to create

SuperPanel out of SDK Panel you will have a way to do that.

Good. It's important for me that I don't have to reformat my code in

order to use it in Jetpack. If I had to use this type system for my own

code, I would have to reformat a lot.

No in fact Panel and such will be just constructor functions with proper `prototype` setup (unlike now).

 

Ben

[Irakli Gozalishvili]

On Friday, 2012-04-13 at 07:16 , Ben Bucksch wrote:

I use:

function Base() {}

Base.prototype = {

baseFunction : function() {

}

}

function Subclass() {}

Subclass.prototype = {

subclassFunction : function() {

}

}

extend(Subclass, Base);

with:

/**

* Create a subtype

*/

function extend(child, supertype)

{

child.prototype.__proto__ = supertype.prototype;

}

__proto__ is no go for us, already explained why.

/**

* Copy properties of |source| into |target|

*/

function mixInto(source, target)

{

for (var property in source)

{

if (typeof(target[property]) == "undefined" &&

// avoid execution of getters/setters

!source.__lookupGetter__(property) &&

!source.__lookupSetter__(property))

{

target[property] = source[property];

}

}

}

[Irakli Gozalishvili]

       Hi,

 I would like to understand something about Jetpack: who are the intended end-users? Whenever I heard presentations, I understood that jetpack targeted primarily web developers. If this is correct, you want to keep the programming style close to web-side JavaScript.

I wish there was a standard style  :(

 

In particular, I believe that this means not reinventing inheritance.

Just my two cents,
 David

--

You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.

To view this discussion on the web visit https://groups.google.com/d/msg/mozilla-labs-jetpack/-/vQ0mplVeeVsJ.

[Daniel]

MooTools Prime will introduce an updated inheritance pattern that will work well with the class abstraction that is likely to make it into the language, might be worth a look: https://github.com/mootools/prime

[Daniel]

Here's an inheritance example from the Prime repo: https://github.com/mootools/prime/blob/master/test/prime/index.js

[Julien Wajsberg]

I find that the way to call super methods is too verbose.
Dojo contribute a method 'inherited' that permit to call the super method.

see the doc and examples there :
http://livedocs.dojotoolkit.org/dojo/declare#inherited

also, Dojo automatically calls the super constructor. I'm not sure I
like this though.

Maybe it's not worth the added complexity of course, but when I had to
use Dojo, I found it was quite handy.

--
Julien

On 15 April 2012 06:18, Daniel <dani...@gmail.com> wrote:
> Here's an inheritance example from the Prime repo: https://github.com/mootools/prime/blob/master/test/prime/index.js
>

> --
> You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/mozilla-labs-jetpack/-/E52iQpa0PMIJ.

[Irakli Gozalishvili]

On Saturday, 2012-04-14 at 21:18 , Daniel wrote:

Here's an inheritance example from the Prime repo: https://github.com/mootools/prime/blob/master/test/prime/index.js

Thanks Daniel for pointing that out. Also by looking at examples it does not seems to be very different from current Class

http://mootools.net/docs/core/Class/Class just a property names.

 

--

You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.

To view this discussion on the web visit https://groups.google.com/d/msg/mozilla-labs-jetpack/-/E52iQpa0PMIJ.

[Irakli Gozalishvili]

Regards

--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

On Sunday, 2012-04-15 at 02:02 , Julien Wajsberg wrote:

I find that the way to call super methods is too verbose.

Dojo contribute a method 'inherited' that permit to call the super method.

see the doc and examples there :

http://livedocs.dojotoolkit.org/dojo/declare#inherited

I do believe they use `arguments.caller` to achieve that which is not permuted in "strict mode" as it could cause capabilities leak. Which is no go for us. That being said I have some ideas how we can simplify super calls, but that's will be a future improvement.

[Paul Morris]

Thanks for the additional background, Irakli.  I understand it better now, but it's still beyond my expertise to offer a worthwhile opinion on which I think is better.  I'm sure that the team will make a good call.

-Paul

[David Rajchenbach-Teller]

On Saturday, April 14, 2012 9:37:21 PM UTC+2, gozala wrote:

I'd be more than happy to use a web standard, but unfortunately there is no such standard, JS is very flexible language and each

JS library / framework has it's own opinionated API for doing inheritance and that is different from project to project.

I tend to think that this is a good reason to not force web developers into one class-style inheritance mechanism and keep the prototype-based inheritance. On the other hand:

Main target audience for this API is people hacking on SDK itself.

...means that you can indeed choose the paradigm you find most suited.

I do have a concern, though, that is not limited to the question of inheritance. While I follow the development of Jetpack only incidentally, what little recent code I have seen (typically, promise-related stuff) gives me the impression that there is a strong temptation to produce code that would fit nicely in the Haskell Platform or in OCaml Batteries Included. While I personally love FP, I fear that this would be counter-productive in the context, insofar as this could restrict the contributor base to people who can think in higher-order and functors.

Do you have any feedback on that style?
 

(This is intentional to meet our security goals).

That sounds interesting. Is there any document with the security goals and methods?

Thanks for the detailed reply.

Cheers,
 David

[Irakli Gozalishvili]

On Monday, 2012-04-23 at 02:23 , David Rajchenbach-Teller wrote:

On Saturday, April 14, 2012 9:37:21 PM UTC+2, gozala wrote:

I'd be more than happy to use a web standard, but unfortunately there is no such standard, JS is very flexible language and each

JS library / framework has it's own opinionated API for doing inheritance and that is different from project to project.

I tend to think that this is a good reason to not force web developers into one class-style inheritance mechanism and keep the prototype-based inheritance. On the other hand:

Main target audience for this API is people hacking on SDK itself.

...means that you can indeed choose the paradigm you find most suited.

Yes it's all about making people hacking on SDK more productive by reducing error prone boilerplate out of the way.

 

I do have a concern, though, that is not limited to the question of inheritance. While I follow the development of Jetpack only incidentally, what little recent code I have seen (typically, promise-related stuff) gives me the impression that there is a strong temptation to produce code that would fit nicely in the Haskell Platform or in OCaml Batteries Included. While I personally love FP, I fear that this would be counter-productive in the context, insofar as this could restrict the contributor base to people who can think in higher-order and functors.

Do you have any feedback on that style?

I don't share this concerns, functional jazz becomes inrceasingly popular this days. Take a look at http://underscorejs.org/ it's

one of the most popular JS libraries and it's all about functional. As of promises even jQuery has moved to them, and new technologies like Windows 8 start with promise based APIs to handle asynchronisity. JS also may eventually get native

http://wiki.ecmascript.org/doku.php?id=strawman:concurrency as well. After all, programing is about learning and if devs will have to learn thing or two to contribute to the core that's for the good!

 

 

(This is intentional to meet our security goals).

That sounds interesting. Is there any document with the security goals and methods?

Unfortunately not but, since you're bribing this up I'll try to find some time to write one. 

Thanks for the detailed reply.

Cheers,
 David

--

You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.

To view this discussion on the web visit https://groups.google.com/d/msg/mozilla-labs-jetpack/-/mk1qa3hasKEJ.

[Irakli Gozalishvili]

I forgot to update this thread, but it's better late than never right :) So api for doing inheritance has landed to SDK some time ago. You can take a look at docs and code if interested:

https://github.com/mozilla/addon-sdk/blob/master/packages/api-utils/docs/heritage.md

https://github.com/mozilla/addon-sdk/blob/master/packages/api-utils/lib/heritage.js

https://github.com/mozilla/addon-sdk/blob/master/packages/api-utils/tests/test-heritage.js

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/