from:"Irakli Gozalishvili"

On Tuesday, 2012-04-03 at 01:49 , David Bruant wrote:
 Le 02/04/2012 17:59, Irakli Gozalishvili a écrit :  
  Hi David,  
   
  Your protected work reminds me a lot of what we did with `namespcase` 
  module in jetpack:  
  https://addons.mozilla.org/en-US/developers/docs/sdk/latest/packages/api-utils/namespace.html
  Which I also blogged about some time ago: 
  http://jeditoolkit.com/2012/03/15/namespaces.html#post
   
  
 As soon as I first wrote Protected(this), I thought of Jetpack namespaces 
 :-)
  
 I remember that one of your complaints about namespaces was that inheritance 
 was not supported. Do you think there is a workable middleground between 
 namespaces and what I've showed here that would have the benefits of 
 namespaces and inheritance?
  

Adding inheritance support turned out to be pretty easy and there is a patch in 
a review that would add support to it:
https://github.com/mozilla/addon-sdk/pull/375
  
   I have made obvious by juxtaposing both examples that JavaScript
   requires from the programmer to choose between encapsulation and
   inheritance. Indeed, as demonstarted above, encapsulation requires a
   shared scope.



   
   
  I totally agree that with this pain point, but hopefully private names will 
  help this. What drove me to reimplement something like Java's protected is 
  that I fear private names won't be enough.
  
 Basically, if an object o is an A and all As are Bs, if you only have private 
 names, then, o's methods inherited from B can access private names related to 
 B. o's methods inherited from A can access private names related to A.
 However, A methods can access private names related to B only if B shares 
 them (like the secret and age of my example). B can share them globally 
 (in the sense of to anyone, not necessarily as properties of the global 
 object), which effectively makes the private names no longer private, but 
 only unique, or A and B need to share a common scope which, in my opinion, 
 does not scale (it forces A and B to be in the same file which is not always 
 an option if you want to use code written in a library)
  
  
  Still I think that there are other expression problems with classes that 
  could be elegantly solved using clojure like protocols that I have posted 
  other day:  
   
  http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#post  
  https://mail.mozilla.org/pipermail/es-discuss/2012-March/021603.html
   
   
  
 I had completely missed that.
  
  Unfortunately I did not got much of a feedback ;) I'll need to watch the 
  video and read more, but that's an interesting idea.
  
 Note: That even though both Event and Installable protocols define functions 
 on and off. Also Object implements both still protocols, but there no 
 conflicts arise and functions defined by both protocols can be used without 
 any issues!
 = This part is rather intriguing. I'm afraid this may lead to confusion. 
 When I write .on, am I installing? adding a listener? Doing both?
They are different functions (not the methods). I was asked a similar it in the 
question and I replied there:
http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#comment-474857390
https://gist.github.com/2175647  
 Also, how are name conflits resolved? Regardless of the exact choice, it 
 seems to be implicit and thus certainly confusing. On that aspect, I would 
 tend to prefer traits or a traits-like solution.
There are no conflicts that's a whole point :)  
  
 David

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Protected Protocol

Ah looks like Kris already pointed that out  


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


On Tuesday, 2012-04-03 at 08:00 , Kris Kowal wrote:

 On Tue, Apr 3, 2012 at 1:49 AM, David Bruant bruan...@gmail.com 
 (mailto:bruan...@gmail.com) wrote:
  Le 02/04/2012 17:59, Irakli Gozalishvili a écrit :
  I remember that one of your complaints about namespaces was that inheritance
  was not supported. Do you think there is a workable middleground between
  namespaces and what I've showed here that would have the benefits of
  namespaces and inheritance?
   
  
  
 Yes, prototypical namespaces are a slight revision away, and I believe
 Irakli has already integrated that change in Jetpack.
  
 https://gist.github.com/2047799
  
 This gist illustrates parallel prototype chains between namespaces,
 and how a namespace can have a common ancestor prototype for each
 instance.
  
 Kris Kowal  

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: callable objects ?



On Tuesday, 2012-04-03 at 14:07 , David Bruant wrote:

 Le 03/04/2012 22:00, Irakli Gozalishvili a écrit :  
  Here is more or less what I have in mind: https://gist.github.com/2295048  
   
  // class
  var Point = {
(x, y) {
  this.getX = { () { return x; } }
  this.getY = { () { return x; } }
}
   
toString() {
  return '' + this.getX() + ',' + this.getY() + '';
}
  }
   
   
   
   
   
  
 Interesting new function syntax.
 The prototype and function body could even be declared together. What about 
 'length'?
  
  Also such callable objects provide shorter alternative to current function 
  syntax:  
  // shorter than function
   
  numbers.
filter({ (x) { return x % 2 } }).
// maybe single expression can be even shorter like arrow functions ?
map({ (x) x * x }).
forEach({ (x) { this.add(x) } }, that);
   
   
   
   
   
  
 +1
  
  Also this would allow interesting APIs similar to those found in clojure:  
   
  // maps / sets similar like in clojure ?
  var map = WeakMap(), key = {}, value = {};
   
  map.set(key, value);
  map(key) // = value
   
   
   
   
   
  
 So far so good.
  
  key(map) // = value This cannot work for backward-compat reasons. In 
  ES1-5, key = {} creates a regular (non-callable) object.
  


Well I did not suggested it should be backwards compatible, also nor classes 
nor shorter object syntax is backwards compatible.


  And maybe built-ins could have it for doing `[]` work:
   
   
  // Maybe even non-magical replacement for `[]`
   
  [ 'a', 'b', 'c' ](1) // = 'b'
   
   
   
   
   
  
 Again, this is a valid ES1-5 expression and throws an error. Arrays and 
 function have diverging opinions on the 'length' property.
  
 David

Also de-sugared version may be provided (and even prototyped today using 
__proto__):

var Point = Function.create(Object.prototype, function(x, y) {
this.getX = function() { return x };
this.getY = function() { return y };
}, {
toString: function() {
return '' + this.getX() + ',' + this.getY() + ''
  }
});
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: callable objects ?



On Tuesday, 2012-04-03 at 13:47 , Axel Rauschmayer wrote:

 I think you should make the distinction between [[Call]] and [[Construct]].  
  


You can do it via (this insntanceof ..) already and dispatch to call / 
construct if you want.  
  
 But both would be great to have for objects. It’s probably best to create 
 importable names.
  

Importable names won't allow shorter than function form though, so I think just 
() {} is better.  
  
  
 Then making the `new` operator available to object exemplars becomes indeed 
 simple. For example:
  
 // Root object exemplar
 import Construct from somewhere;
 let ObjectExemplar = {
 [Construct](...args) {
 let inst = Object.create(this);
 let result = inst.init(...args);
 return (result === undefined ? inst : result);
 }
 }
  
  
  
 On Apr 3, 2012, at 22:00 , Irakli Gozalishvili wrote:
  Hi,  
   
  Please excuse me if this will sound too crazy, but this idea have being 
  growing in my head for so long that I can't stop myself from proposing it 
  here. I have experimented many different ways of doing inheritance in JS:
   
  1. Starting with a simple sugar that reduces machinery involved, similar to 
  backbone.js
  https://github.com/Gozala/extendables
   
  2. Finishing with class free prototypal inheritance
  https://github.com/Gozala/selfish
   
  I have to say that experience with selfish turned out very interesting, it 
  made things so much simpler no special forms, no twisted relations between 
  constructors and objects, just a plain objects. Most of these things are 
  not obvious until you start using them, but the fact that exemplars 
  (classes) are no different from regular objects in the system makes things 
  much simpler.  
   
  That being said I have also came to realize that in most of the cases 
  functions as exemplars would be a better feet than objects. As a matter of 
  fact if objects could be made callable I think it could could have replaced 
  most of the things that classes are targeting in more elegant way.  
   
  Here is more or less what I have in mind: https://gist.github.com/2295048
   
  // class
  var Point = {
(x, y) {
  this.getX = { () { return x; } }
  this.getY = { () { return x; } }
}
   
toString() {
  return '' + this.getX() + ',' + this.getY() + '';
}
  }
   
  var a = new Point(0, 0)
  var b = new Point(1, 7)
   
  // Examples from class proposal
   
  // extend is like create with a diff that second arg is an object.
  var SkinnedMesh = Object.extend(THREE.Mesh, {
(geometry, materials) {
  // call the superclass constructor
  THREE.Mesh.call(this, geometry, materials);
   
  // initialize instance properties
  this.identityMatrix = new THREE.Matrix4();
  this.bones = [];
  this.boneMatrices = [];
   
  // ...
}
   
update (camera) {
  THREE.Mesh.update.call(this);
}
  });
   
  Also such callable objects provide shorter alternative to current function 
  syntax:
  // shorter than function
   
  numbers.
filter({ (x) { return x % 2 } }).
// maybe single expression can be even shorter like arrow functions ?
map({ (x) x * x }).
forEach({ (x) { this.add(x) } }, that);
   
   
  Also this would allow interesting APIs similar to those found in clojure:
   
  // maps / sets similar like in clojure ?
  var map = WeakMap(), key = {}, value = {};
   
  map.set(key, value);
  map(key) // = value
  key(map) // = value
   
   
  And maybe built-ins could have it for doing `[]` work:
   
   
  // Maybe even non-magical replacement for `[]`
   
  [ 'a', 'b', 'c' ](1) // = 'b'
  ({ a: 1, b: 2 })('a') // = 1
  ('b')({ a: 1, b: 2 }) // = 2
   
   
   
   
  Regards
  --
  Irakli Gozalishvili
  Web: http://www.jeditoolkit.com/
   
  ___
  es-discuss mailing list
  es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
  https://mail.mozilla.org/listinfo/es-discuss
  
 --  
 Dr. Axel Rauschmayer
 a...@rauschma.de (mailto:a...@rauschma.de)
  
 home: rauschma.de (http://rauschma.de)twitter: twitter.com/rauschma 
 (http://twitter.com/rauschma)
 blog: 2ality.com (http://2ality.com)
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: callable objects ?

Also I just realized that I have not mentioned it but I meant that new Point(0, 
0) would do following:

var point = Object.create(Point);
var value = Function.apply.call(point, arguments);
return typeof(value) === 'undefined' ? point : value;

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


On Tuesday, 2012-04-03 at 17:44 , Irakli Gozalishvili wrote:

  
  
 On Tuesday, 2012-04-03 at 13:47 , Axel Rauschmayer wrote:
  
  I think you should make the distinction between [[Call]] and [[Construct]]. 
   
   
   
  
  
 You can do it via (this insntanceof ..) already and dispatch to call / 
 construct if you want.  
   
  But both would be great to have for objects. It’s probably best to create 
  importable names.
   
  
 Importable names won't allow shorter than function form though, so I think 
 just () {} is better.  
   
  Then making the `new` operator available to object exemplars becomes indeed 
  simple. For example:
   
  // Root object exemplar
  import Construct from somewhere;
  let ObjectExemplar = {
  [Construct](...args) {
  let inst = Object.create(this);
  let result = inst.init(...args);
  return (result === undefined ? inst : result);
  }
  }
   
   
   
  On Apr 3, 2012, at 22:00 , Irakli Gozalishvili wrote:
   Hi,  

   Please excuse me if this will sound too crazy, but this idea have being 
   growing in my head for so long that I can't stop myself from proposing it 
   here. I have experimented many different ways of doing inheritance in JS:

   1. Starting with a simple sugar that reduces machinery involved, similar 
   to backbone.js
   https://github.com/Gozala/extendables

   2. Finishing with class free prototypal inheritance
   https://github.com/Gozala/selfish

   I have to say that experience with selfish turned out very interesting, 
   it made things so much simpler no special forms, no twisted relations 
   between constructors and objects, just a plain objects. Most of these 
   things are not obvious until you start using them, but the fact that 
   exemplars (classes) are no different from regular objects in the system 
   makes things much simpler.  

   That being said I have also came to realize that in most of the cases 
   functions as exemplars would be a better feet than objects. As a matter 
   of fact if objects could be made callable I think it could could have 
   replaced most of the things that classes are targeting in more elegant 
   way.  

   Here is more or less what I have in mind: https://gist.github.com/2295048

   // class
   var Point = {
 (x, y) {
   this.getX = { () { return x; } }
   this.getY = { () { return x; } }
 }

 toString() {
   return '' + this.getX() + ',' + this.getY() + '';
 }
   }

   var a = new Point(0, 0)
   var b = new Point(1, 7)

   // Examples from class proposal

   // extend is like create with a diff that second arg is an object.
   var SkinnedMesh = Object.extend(THREE.Mesh, {
 (geometry, materials) {
   // call the superclass constructor
   THREE.Mesh.call(this, geometry, materials);

   // initialize instance properties
   this.identityMatrix = new THREE.Matrix4();
   this.bones = [];
   this.boneMatrices = [];

   // ...
 }

 update (camera) {
   THREE.Mesh.update.call(this);
 }
   });

   Also such callable objects provide shorter alternative to current 
   function syntax:
   // shorter than function

   numbers.
 filter({ (x) { return x % 2 } }).
 // maybe single expression can be even shorter like arrow functions ?
 map({ (x) x * x }).
 forEach({ (x) { this.add(x) } }, that);


   Also this would allow interesting APIs similar to those found in clojure:

   // maps / sets similar like in clojure ?
   var map = WeakMap(), key = {}, value = {};

   map.set(key, value);
   map(key) // = value
   key(map) // = value


   And maybe built-ins could have it for doing `[]` work:


   // Maybe even non-magical replacement for `[]`

   [ 'a', 'b', 'c' ](1) // = 'b'
   ({ a: 1, b: 2 })('a') // = 1
   ('b')({ a: 1, b: 2 }) // = 2




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

   ___
   es-discuss mailing list
   es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
   https://mail.mozilla.org/listinfo/es-discuss
   
  --  
  Dr. Axel Rauschmayer
  a...@rauschma.de (mailto:a...@rauschma.de)
   
  home: rauschma.de (http://rauschma.de)twitter: twitter.com/rauschma 
  (http://twitter.com/rauschma)
  blog: 2ality.com (http://2ality.com)
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
  

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Should ... be suffix rather than prefix?

Second feels more intuitive to me


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


On Tuesday, 2012-04-03 at 13:16 , Mark S. Miller wrote:

 foo(a, b, ...rest)
 
 vs
 
 foo(a, b, rest...)
 
 Which is clearer?
 
 ES6 has currently agreed on the first. English and Scheme agree on the 
 second. 
 
 This question applies to both 
 http://wiki.ecmascript.org/doku.php?id=harmony:rest_parameters and 
 http://wiki.ecmascript.org/doku.php?id=harmony:spread. 
 
 -- 
 Cheers,
 --MarkM
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss
 
 


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Protected Protocol

2012-04-02 Thread Irakli Gozalishvili

Hi David, 

Your protected work reminds me a lot of what we did with `namespcase` module in 
jetpack:
https://addons.mozilla.org/en-US/developers/docs/sdk/latest/packages/api-utils/namespace.html
Which I also blogged about some time ago: 
http://jeditoolkit.com/2012/03/15/namespaces.html#post

In contrast to this work though namespaces are not class centric and you can 
use more than one namespace per object. We also use weak maps to implement 
that. 

 I have made obvious by juxtaposing both examples that JavaScript
 requires from the programmer to choose between encapsulation and
 inheritance. Indeed, as demonstarted above, encapsulation requires a
 shared scope.
 
 


I totally agree that with this pain point, but hopefully private names will 
help this. Still I think that there are other expression problems with classes 
that could be elegantly solved using clojure like protocols that I have posted 
other day:

http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#post
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021603.html

Unfortunately I did not got much of a feedback ;)
Cool to see others exploring this area!

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


On Sunday, 2012-04-01 at 15:28 , David Bruant wrote:

 Hi,
 
 A while ago, I posted a challenge on es-discuss [1]. It was a challenge
 related to code reuse, modularity and composition. There has been an
 interesting suggestion [2] [3] which left me a bit unsatisfied since
 relying on constructor arguments while it may not be always possible to
 do that.
 What I describe as the protected protocol is my response to my own
 challenge.
 Before explaining it, I'd like to take a step back and discuss about the
 object oriented properties of JavaScript.
 
 
 Two expected properties of object-oriented languages are encapsulation
 and inheritance.
 
 Encapsulation allows to define objects which can only be interacted with
 through a given an interface, thus hiding implementation details. In the
 long run, encapsulation makes the maintenance of components easier since
 the implementation of an object can be changed without affecting its
 clients.
 
 Encapsulation can be implemented in JavaScript. One usual way is to do
 as follow:
 
 function Storage(){
 var array = Array.prototype.slice.call(arguments, 0);
 
 return {
 add: function(e){
 array.push(e);
 },
 read: function(i){
 return array[+i];
 }
 };
 }
 
 Here, access to the array is restricted to the interface (add and
 read methods).
 
 
 Inheritance allows to better reuse code by specializing classes.
 This can be implemented as well, usually with this pattern:
 
 function Storage(){
 this.array = Array.prototype.slice.call(arguments, 0);
 }
 
 Storage.prototype = {
 add: function(e){
 this.array.push(e);
 },
 read: function(i){
 return this.array[+i];
 }
 };
 
 
 function StorageWithDeletion(){
 Storage.call(this); // equivalent to super;
 }
 
 StorageWithDeletion.prototype = Object.create(Storage.prototype);
 StorageWithDeletion.prototype.delete = function(i){
 delete this.array[+i];
 };
 
 
 To define a storageWithDeletion, there is no need to redefine the add
 and read method. To extend Storage, StorageWithDeletion here only needs
 access to the Storage function in the global scope (or Storage module
 when these will be deployed). This has the nice property that Storage
 and StorageWithDeletion can be defined in different files since they
 don't need to share a common function scope
 
 I have made obvious by juxtaposing both examples that JavaScript
 requires from the programmer to choose between encapsulation and
 inheritance. Indeed, as demonstarted above, encapsulation requires a
 shared scope.
 
 Solutions where Storage and StorageWithDeletion would be defined with a
 shared scope could be explored, but it would require to define both in
 the same file, which, I don't want to be a necessity.
 
 The trick of the protected protocol is that encapsulation does not
 really require a shared scope, it's just the most natural way to do it
 in JavaScript.
 
 When a method located in the prototype chain of an object is called, its
 'this' references the object from which the method has been called.
 Programmers have naturally stored the state of an object as own (public)
 properties of the object as it's the most natural way to bind
 information to an object.
 It doesn't have to be this way, though. WeakMaps offer an
 straightforward API to bind information to an object and it is not
 necessary to share this WeakMap with the rest of the world.
 
 
 The protected protocol and an example of how to use it can be found at
 [4] (which is a bit different than a version I tweeted earlier [5]).
 
 The most important part in my opinion is that the Person.js and
 ComputerSavvyPerson.js are defined in 2 different files. The only thing
 the latter needs is a reference to the constructor it inherits from
 (here, Person).
 
 Things that are expected to be secret can

recursive arrow functions

2012-04-01 Thread Irakli Gozalishvili

Today I have noticed one interesting remark from Douglas Crockford on arrow 
functions: you will need to use the old functions to write self-recursive 
functions - http://www.yuiblog.com/blog/2012/03/30/what-is-the-meaning-of-this

Is that really going to be the case ? I was so much looking forward to [proper 
tail calls](http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_calls) 
and making arrow functions incompatible would be really bad, specially since 
they seem to be more functiony than current functions. Why not allow naming 
arrow function or have some syntax for making recursive calls ?  


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

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: arrow function syntax simplified

2012-03-29 Thread Irakli Gozalishvili

Few questions on this new arrow functions:

let foo = x = x * x


1. What is foo.prototype ?  
2. What does new foo(y) does ?
3. Is there going to be equivalent of Function for arrow functions ?
4. Is Function.create(foo) going to work ?
5. Will foo.call, foo.apply pass in the `this` ?

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


On Thursday, 2012-03-29 at 07:15 , Brendan Eich wrote:

 This is all moot now -- see meeting notes and followups. Thin arrow is  
 not going to make it, we want one arrow. The |this| parameter for opting  
 into dynamic rather than default-lexical |this| also died. Method  
 definition shorthand covers the only strong use-case, as Kevin's  
 analysis shows.
  
 /be
  
 Herby Vojčík wrote:
  Brendan Eich wrote:
   Kevin Smith wrote:
 
I hate the CoffeeScript deviation, though. It's just confusing for
anyone who ever learned that fat-arrow binds |this| and thin-arrow
doesn't.
 
 
True. On the other hand, all arrows bind |this| is also quite simple
and easy to remember.
 


   Yes, and I kept the part of the proposal that allows |this| as a leading
   arrow formal parameter, including with parameter default value. This
   suggests a slight variation on the strawman, per your suggestion:

   x - { return this.x; } // lexical this for thin arrow
   x = this.x // as for fat arrow

   (this, x) - { return this.x; } // dynamic this, five letter syn-tax
   (this, x) = this.x // ditto for the expression-body form

   
   
  I like this very much. Clear, orthogonal, readable.
  It would be nice if this could get through.
   
   /be
   
  Herby
   
  P.S.: Dynamic this no-arg function could also use one-arg shorthand?
   
  this = this.x
  this - { return this.x; }
   
  
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss
  
  


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

module path resolution

2012-03-23 Thread Irakli Gozalishvili

I'v being trying to figure out how ES.next module path resolution would work. 
Unfortunately proposal is not very clear about it: 
http://wiki.ecmascript.org/doku.php?id=harmony:modules 

Here are some of the questions I have:

1. Will html [base element] have a same effect on modules as it has on script 
tags today ?
2. Are relative paths resolved to a requirer's url, owner html document's urlor 
baseURI ?

If my assumptions are correct this little example is correct:
https://github.com/Gozala/packageless/tree/master/examples/es.next/

[base element]:https://developer.mozilla.org/en/HTML/Element/base

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

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: module path resolution

2012-03-23 Thread Irakli Gozalishvili



On Friday, 2012-03-23 at 18:14 , David Herman wrote:

 On Mar 23, 2012, at 5:05 PM, Irakli Gozalishvili wrote:
 
  I'v being trying to figure out how ES.next module path resolution would 
  work. Unfortunately proposal is not very clear about it: 
  http://wiki.ecmascript.org/doku.php?id=harmony:modules
 
 There's more info about the resolution semantics on the loaders page:
 
 http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders
 
 Basically loaders make it possible for programmers to create custom 
 resolution policies.
 
 But your question is probably more about what the default policy of the 
 System loader will be on the web.
 
Yeap! 

 First of all, the System loader's baseURL (should it be baseURI? I never 
 understood the difference) would come from the document's URL. So relative 
 would definitely be relative the HTML file.
 
Yeah so by default `document.baseURI` is just a `document.documentURI` or 
simply URL to the html document. All the relative URLs on that document resolve 
to the `document.baseURI`. Also, there is an html `base` tag that allows one to 
set value of `document.baseURI` and there for change relative url resolution. 
More details can be found in HTML spec: 
http://www.w3.org/TR/html401/struct/links.html#h-12.4

 
  Here are some of the questions I have:
  
  1. Will html [base element] have a same effect on modules as it has on 
  script tags today ?
  2. Are relative paths resolved to a requirer's url, owner html document's 
  urlor baseURI ?
  
  If my assumptions are correct this little example is correct:
  https://github.com/Gozala/packageless/tree/master/examples/es.next/
  
  [base element]:https://developer.mozilla.org/en/HTML/Element/base
 
 These are really good points I hadn't thought about. Thanks for bringing it 
 up! I like the idea that
 
 ./foo.js
 
 forces the loading to be relative to the document, whereas
 
 bar/baz.js
 
 is interpreted as relative to the base path. I don't have strong feelings 
 myself about what the System loader's policy should be on the web, but I want 
 to make sure our infrastructure is flexible enough to support a) whatever 
 everyone decides is the best policy for the browser, and b) policies like the 
 Node.js / NPM policy. I will have to read up a little more on 
 document.baseURI and base and all that.

Let me elaborate a bit on what my intent is:

Usually any app / lib code is organized such that third party dependencies are 
located in an separate directory from an
actual program code. This helps to reduce noise for a human eye and also make 
it easier to work with version control systems, since third party code is 
commonly not tracked in the same repository. I think it's pretty important to 
have good support for this. One cleanest way IMO would be to have different 
resolution login for dependencies:

A. ./foo.js ../foo/bar.js
B. foo.js, foo/bar.js

I'd suggest to resolve A type paths relative to a requirer (ether require 
module url, or document url). And resolve B
type paths relative to a `document.baseURI`. That would allow users to organize 
codebase as described above and
show in the example repo:  
https://github.com/Gozala/packageless/tree/master/examples/es.next/

Also not that this is somewhat similar to nodejs behavior where `./foo, 
../foo/bar` form is used for resolving modules
relative to the requirer. While `foo, foo/bar` form is used for installed 
package dependencies. Unfortunately nodejs policies are bit more complicated 
than that since `foo` form there won't look in just one `baseURL` instead it 
does
recursive upward search in `node_modules` folders  which I don't think is 
compliant with web. That being said though I think it would map simple cases 
pretty well.

 
 Thanks for the information and ideas!
 
 Dave 
Regards 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

clojure like protocols

2012-03-22 Thread Irakli Gozalishvili

I have published a [blog post] about JS [protocol library] that implements 
clojure like polymorphism, which is interesting
as it solves typical [problems with classes]. From my experiment I got a 
feeling that it may be a much better feet for JS language than classes, so I 
thought it's worth sharing here.

[blog 
post]:http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#post 
[protocol library]:https://github.com/Gozala/protocol
[clojure protocols]:http://clojure.org/Protocols
[problems with classes]:https://vimeo.com/11236603

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

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: clojure like protocols

2012-03-22 Thread Irakli Gozalishvili




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


On Thursday, 2012-03-22 at 17:09 , Brandon Benvie wrote:

 Maye I'm crazy but this seems like IDL in a more JavaScript friendly form. 
 Not just WebIDL JavaScript semantics and types friendly, but targeted at 
 implementation using JavaScript which is less friendly and requires Proxy 
 wrappers for many/most things like dom.js does. Which is a good thing and I 
 like this.

Maybe I misunderstand your comment but this does not requires Proxy wrappers, 
in fact it uses just a simple monkey patching of prototypes using 
non-enumerable, unique names under the hood. With private names it can be 
improved even further. Or alternatively WeakMaps can be used to implement all 
of this. 
 
 
 On Thu, Mar 22, 2012 at 5:48 PM, Irakli Gozalishvili rfo...@gmail.com 
 (mailto:rfo...@gmail.com) wrote:
  I have published a [blog post] about JS [protocol library] that implements 
  clojure like polymorphism, which is interesting
  as it solves typical [problems with classes]. From my experiment I got a 
  feeling that it may be a much better feet for JS language than classes, so 
  I thought it's worth sharing here.
  
  [blog 
  post]:http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#post
   
  [protocol library]:https://github.com/Gozala/protocol
  [clojure protocols]:http://clojure.org/Protocols
  [problems with classes]:https://vimeo.com/11236603
  
  Regards
  --
  Irakli Gozalishvili
  Web: http://www.jeditoolkit.com/
  
  
  ___
  es-discuss mailing list
  es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
  https://mail.mozilla.org/listinfo/es-discuss
  
 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Alternative syntax for |

2011-11-21 Thread Irakli Gozalishvili

Recently Claus Reinke proposed some alternative that I think feels is so much 
more natural and simpler than | or beget: 

Instead of this:

foo | { bar: 'bar' } 

prototype can be a special property:

{ prototype: foo, bar: 'bar' }

simple and easy, of course it can have a different name from `prototype`. Also, 
this special `prototype` property can be non-configurable, non-writable and 
non-enumerable falling back to Object.prototype if not provided. Also 
Object.create(null, { foo: { value: 'foo' } }) will become as simple as { 
prototype: null, foo: 'foo' }.  
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Monday, 2011-11-21 at 10:10 , Allen Wirfs-Brock wrote:

 
 On Nov 19, 2011, at 11:38 AM, Dean Landolt wrote:
  
  
  On Sat, Nov 19, 2011 at 1:57 PM, Allen Wirfs-Brock al...@wirfs-brock.com 
  (mailto:al...@wirfs-brock.com) wrote:
   
   On Nov 15, 2011, at 10:27 PM, Russell Leggett wrote:
   
   
   
but given the overall disapproval of the exact syntax of the | 
operator, I think its at least a little more obvious what is going on.
   
   
   Sorry to be coming late to this thread.
   
   I think the above statement is a false characterization to use to start 
   this discussion.  There are some who disapprove of | or other similar 
   special character formulation of this operator. There are other who like 
   it a lot.  Certainly there isn't overall disapproval.  However, we 
   can't really even tell whether there is majority (of what population??) 
   approval or disapproval.  At best, all you can legitimately say is that 
   there is not universal approval of the | token.
  
  
  I was under the impression that TC39 generally operates by consensus. As 
  you note, there are some who disapprove -- if some is a non-inconsequential 
  number wouldn't this constitute overall disapproval?
 
 It's true that there isn't consensus within TC39 on the | syntax.  
 However, there also isn't consensus on any other specific token or keyword 
 either.  At the May TC39 meeting there was consensus on advancing to 
 proposal status  the semantic capabilities that were in the enhanced object 
 literal strawman.  At the same time it was noted that there wasn't agreement 
 on syntax. 
 
 Lack of consensus does not mean overall disapproval.  It means there isn't 
 overall approval.  Further consensus building is still required it might be 
 around the pending proposal or it might be around something else. 
 
 However, TC39 wan't even mentioned in the statement I took exception to.  It 
 seemed to make a broader subjective characterization.
  
  FWIW I'm indifferent to the syntax, but it reads just fine to me. Still, 
  I'm sure there's something better lurking. Especially if it's true that 
  since it's infix it could be nearly anything. IMHO begets is pretty 
  winful. 
 I find keywords such as begets a bit more jarring when used as 
 compositional primitives.  
 
 To me, beget reads fine in isolation such as
   let bob = tom beget {name:  'Robert');
 
 But when used in combination you get clashes of the underlying natural 
 language meaning of the keywords.  Compare
   let Point = class AbstractPoint begets {...
 to
   let Point = class AbstractPoint | {...
 
 The first form just doesn't read quite right to me.  For the second form, I 
 don't necessarily internally vocalize a natural language word for |.
 
 My personal preference is  for a special characters based operator based 
 token but it doesn't have to be |.  I've frequently suggested : as another 
 alternative.  I'm less happy with a keyword operator token but I don't reject 
 that alternative and beget may well be the best of those.
 
 However, we have to decide on something or we just won't have this 
 functionality at all.
 
 Consensus doesn't mean that everybody likes the solution.  It just means that 
 everybody is willing to accept it. What we really need to do is build such a 
 consensus around one of the alternatives.
 
 Allen
 
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss
 
 


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The class operator: a bridge between object and function exemplers

2011-11-15 Thread Irakli Gozalishvili



On Monday, 2011-11-14 at 16:50 , David Flanagan wrote:

 On 11/14/11 4:16 PM, Allen Wirfs-Brock wrote:
  On Nov 14, 2011, at 3:15 PM, David Flanagan wrote:
   I have a bad feeling about making 'new' work with both functions and 
   object exemplars. If we can have two different types of classes, we're 
   going to end up using typeof on our class objects to figure out what kind 
   of class they are. If I've got a value C from a library and I think it is 
   an object exemplar, but it is in fact a constructor function, then 'class 
   C' is going to return Function rather than C itself...
  
  Well, new'ing object exemplars has always been the central concept of our 
  discussions about them. Essentially it is the self style of object creation 
  and arguably the way the prototypal instantiation is supposed to work. It 
  seems to be what people who really like prototypal inheritance really want 
  to do.
  
 
 Apparently I wasn't paying attention to the early discussions about 
 object exemplars. I've heard the term used, but missed the point about 
 changing the behavior of new. It seems to me people who want to use 
 self-style object creation can use Object.create() and people who want 
 to use JavaScript-style object creation can use new like we've been 
 doing for 15 years. (Just today I wrote a blog post explaining why I'm 
 hoping for classes in ES.next, and included, as part of my argument, the 
 assertion that all the proposals on the table are just syntax sugar 
 without new language semantics. I was wrong about that, I guess!)
 
  The magic of what I'm proposing is that you will rarely have to worry 
  about whether a named object abstraction (call it Foo) you get from a 
  library is an object exemplar or a function/class exemplar. Without knowing 
  you can say:
  new Foo(args)
  
 
 Maybe I'm overreacting, and new semantics can make this all just work. 
 But it seems like a major, major change to the language.
 
  and it will work. Without knowing you can do either :
  let subfoo = Foo| {constructor() {}};
  or
  let subfoo = class Foo| {constructor() {}} //note this parses as: class 
  (Foo| {... })
  and things will work. You can even say:
  let subfoo = Foo| function() {}
  and the right thinks happen.
  
  To me, this seems like the essence of object-oreinted implementation 
  encapsulation. All a client of Foo needs to know is that Foo is an 
  exemplar and hence it can be instantiated (via new) or specialized 
  (via|). It is up to the implementor of Foo to decide how to best express 
  its implementation. They can even change their mind and clients shouldn't 
  care.
 Do JavaScript programmers want exemplars or do they want classes?
 

Some including me, want exemplars while others want classes. Good thing is that 
with this proposal both of us will get what we want :)
 
 
  Finally, if you really need to know whether an exemplar is an object 
  exemplar or a function exemplar then typeof Foo is Function seems like a 
  fine way to test it. (I'm really growing to like the is operator...)
  
   Object exemplars does not pave the cowpaths for classes: it creates a new 
   path and just smears out the concept of a class into something more 
   broad. I fear it will create confusion rather than  provide a terse and 
   declarative surface for those semantics so that programmer intent is 
   expressed instead of the underlying imperative machinery.
  I look at it from the perspective that we already have at least two 
  cowpaths that meander across each other in ways that make it hard to stay 
  on either one. I'm optimistic that we pave them in such a way that we are 
  really dealing so parallel lanes on the freeway (and this analogy just got 
  totally out of hand).
  
 
 If I may continue the out-of-hand metaphor, I worry that we'll end up 
 with a two lane freeway that is being repaved and has Warning: abrupt 
 edge! signs because one lane is bumpy and 2 inches lower than the other 
 lane.
 
 David
  Allen
 
 
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss
 
 


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The class operator: a bridge between object and function exemplers

2011-11-15 Thread Irakli Gozalishvili

Sorry I'm so excited about this that I just could not read it all before 
posting this, my apologies if it's already discussed: 



On Monday, 2011-11-14 at 17:04 , Allen Wirfs-Brock wrote:


   UnaryExpression :
   class UnaryExpression
   ...

The semantics are:
 1. if UnaryExpression is undefined or null, return the value of 
UnaryExpression.
 2. Let obj be ToObject(UnaryExpression)
3. Return the result of calling the [[Get]] internal method of obj with 
argument 'constructor'

   
   
   Interesting, so 'constructor' will inherit from Object.prototype if 
   missing from the exemplar. This means
   
   let Point = class {
x:0,
y,0
   
   };
   
   let p = new Point(1, 2);
   
   will result in p being constructed via the equivalent of new Number(1).
  
 
 sh*t! I though I'd had a solution for this, but maybe I don't...
 
 If you are really going to define either an object or class exemplar, you 
 really need to define a constructor.  The object exemplar case actually works 
 out ok in this case  because the inherited constructor is called as a 
 function, not as a constructor.   So for 
 
let Point = {
  x: 0,
  y: 0
};
  let p = new Point(1,2);
 
 Is pretty much equivalent to:
   let p = Point | {};
 
 which may not be exactly what the programmer expected  but it is a least in 
 the vicinity and yields an object with (inherited) x and y properties.

I think this concern could be easily fixed if `class prototype` was equivalent 
of `Class(prototype)` where implementation of Class is following (BTW I don't 
propose to use Class function just illustration of what class prototype could 
be) :

function Class(prototype) {
function constructor() {
Object.hasOwnProperty(prototype, 'constructor')
let instance = Object.create(prototype);
instance.constructor.apply(instance, arguments);
return instance;
}
constructor.prototype = prototype;
return constructor;
}

As additional benefit this solves issue of shared / frozen constructor 
properties of the prototype.

P.S.: I just yesterday I started experimenting with `Class` function in 
combination with selfish. ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The class operator: a bridge between object and function exemplers

2011-11-15 Thread Irakli Gozalishvili



On Tuesday, 2011-11-15 at 10:58 , David Flanagan wrote:

 On 11/14/11 5:17 PM, Allen Wirfs-Brock wrote:
  On Nov 14, 2011, at 4:50 PM, David Flanagan wrote:
  
   On 11/14/11 4:16 PM, Allen Wirfs-Brock wrote:
On Nov 14, 2011, at 3:15 PM, David Flanagan wrote:
 I have a bad feeling about making 'new' work with both functions and 
 object exemplars. If we can have two different types of classes, 
 we're going to end up using typeof on our class objects to figure out 
 what kind of class they are. If I've got a value C from a library and 
 I think it is an object exemplar, but it is in fact a constructor 
 function, then 'class C' is going to return Function rather than C 
 itself...

Well, new'ing object exemplars has always been the central concept of 
our discussions about them. Essentially it is the self style of object 
creation and arguably the way the prototypal instantiation is supposed 
to work. It seems to be what people who really like prototypal 
inheritance really want to do.

   
   Apparently I wasn't paying attention to the early discussions about 
   object exemplars. I've heard the term used, but missed the point about 
   changing the behavior of new. It seems to me people who want to use 
   self-style object creation can use Object.create() and people who want to 
   use JavaScript-style object creation can use new like we've been doing 
   for 15 years. (Just today I wrote a blog post explaining why I'm hoping 
   for classes in ES.next, and included, as part of my argument, the 
   assertion that all the proposals on the table are just syntax sugar 
   without new language semantics. I was wrong about that, I guess!)
   
  
  Object create doesn't do the job because it doesn't provide for calling an 
  initialize methods (turns out to be a very important part of the 
  self-style).
  
 
 Its not like there's a large community of self programmers out there who 
 are migrating to JavaScript... It seems to me that if you like the 
 object exemplar style, then you don't want to be using the new operator 
 and constructor functions (or things that appear to be constructors 
 because they're used with new). Instead you want to define factory 
 functions that use Object.create():
 

But making it possible to reuse libraries that are written either object or 
class exemplar supporters is a huge win to me!
 
 
 function Range(from, to) {
 return Object.create(Range.methods, {
 from: { value: from, enumerable: true },
 to: { value: from, enumerable: true}
 });
 }
 Range.methods = {
 includes: function(x) {
 return this.from = x  x = this.to;
 }
 };
 Range(1,3).includes(2); // = true
 
   Do JavaScript programmers want exemplars or do they want classes?
  They seem to be split. Some vocally ask for better support for prototypal 
  inheritance other vocally ask for classes.
  
 
 Irakli has self-identified in this thread as wanting object exemplars 
 but he has also defined a simple and useful Class() function for working 
 with them. I suspect that part of the appeal of object exemplars is 
 that it is easier to write support functions like Class() for working 
 with them. That is: we can make the proponents of object exemplars 
 happy with good library support. But for classes, we need language 
 support...
 
  I think what everybody is asking for is a better way to created named 
  object abstractions. The term exemplar is just one that I introduced into 
  the discussion to make it easier to talk about the different kinds of 
  entities you might apply such names to. In some language you name a class 
  declaration, in others you name a prototypal instance, in JS you have 
  historically named a function. Exemplar was intended to be a generic for 
  such named object abstractions. An object exemplar is a self style 
  prototype, a class exemplar is the sort of thing you find in languages llke 
  Java. A function exemplar is a JS constructor,
 Are there existing languages that support more than one kind of exemplar 
 at the language level? It seems to me that JS is stuck with function 
 exemplars, and we should work to make those better, not add complexity 
 to the language by adding support for another style of exemplar.
 
 David
 
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss
 
 


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minimalist (why) classes ?

2011-11-14 Thread Irakli Gozalishvili

On Monday, 2011-11-14 at 10:42 , Rick Waldron wrote:
 
 The tests I wrote for Selfish illustrate that it also has this behaviour, but 
 is more deceiving because you think you're getting new instances. 
Hey Rick, I'd be interested to see those tests since it's not supposed to 
mutate any arguments passed to it, and if that's a case it's a bug and I'd like 
to fix it. Thanks!  
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minimalist (why) classes ?

2011-11-13 Thread Irakli Gozalishvili

I think this discussion drifted into slightly diff direction.  
What I intended to say was that today all major frameworks use same patter to 
do subclassing. They all implement different APIs to do the following:

function subclass() {
   // init ….
}
subclass.prototype = Object.create(superclass)
Object.defineProperty(subclass.prototype, 'constructor', { value: subclass })
subclass.prototype.method = function() {  
   //...
}

Object.extend used in my gist is BTW same as backbone's .extend and is just a 
shortcut of the code above:

var subclass = superclass.extend({
   initialize: function() {
  // init ...
   },
   method: function() {
  // ….
   }
})

What I'm asking for is a standard function, no matter weather it's 
`Object.extend` or something else that makes it simple to do subclassing. Also 
lisper in me thinks that `Object.extend` method is better than dedicated class 
syntax cause it keeps language concise. In addition I think that if 
`Object.extend` will turn out to be broken it will be easier (not to say easy) 
to fix (`Object.extend = … `) then fixing `class Foo extends Bar`.
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Sunday, 2011-11-13 at 13:21 , Brendan Eich wrote:

 On Nov 13, 2011, at 11:28 AM, John J Barton wrote:
  
  On Sun, Nov 13, 2011 at 9:34 AM, Brendan Eich bren...@mozilla.com 
  (mailto:bren...@mozilla.com) wrote:
   On Nov 13, 2011, at 9:30 AM, Brendan Eich wrote:

The hard cases include:
 
1. Closures.
2. Proxies.
3. Private names.
4. Internal hidden state.
5. Side-table entries mapped to the object's identity.
 


   In the case of objects implemented by C++ or whatever the host 
   implementation language might be, the internal or side-table state may 
   not even be representable in JS, even in strings (do not want raw 
   pointers, or machine addresses however obfuscated, to leak to an 
   attacker).
   
  I think we are on the wrong path here. I guess we followed: a standard
  extend() needs a copy-ish operation; a copyish operation is like
  cloning; cloning is hard; OMG.
   
  
  
 That's not what happened. Some people are happy with shallow copy of 
 properties available to ES5 reflection, or even a for-in loop. Others (Rick?) 
 want deep, at least as an option. Deep could skip any private/internal/etc. 
 properties, for sure. But deep tends to get into trouble because if you don't 
 stay shallow, you run immediately into item 1: Closures. How would those be 
 deeply copied, including their lexical environments?
  
  
  But let's back up. We are looking for one or a few operations such that:
  var a = op(b,c,d,...);
  creates a useful result when we use |a| and we are using existing JS
  libraries for guidance. By definition there are no show stoppers here.
   
  
  
 I agree, other than inability to agree on what to standardize.
  
  
  We are creating new objects from existing objects using operations
  available to JS devs, but in standard and recommended way. The only
  two things can stop us from being successful: irreconcilable
  differences and inertia.
   
  
  
 Ok, but this is all meta-pep-talk. What should the reconcilable standard be?
  
 /be
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss
  
  


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minimalist (why) classes ?

2011-11-13 Thread Irakli Gozalishvili



On Friday, 2011-11-11 at 18:38 , Brendan Eich wrote:

 Having written all this, I will repeat that I like your selfish work and the 
 exemplar idea
Thanks, that's really encouraging! 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: WeakMaps question ?

I really need to know why WeakMaps don't accept primitives as keys, can anyone 
please reply ? 

Thanks!
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Thursday, 2011-11-10 at 10:31 , Irakli Gozalishvili wrote:

 Hi, 
 
 I was wondering what is a reason for disallowing non-object values as keys in 
 WeakMaps ?
 
 Also, I think I have a pretty good use case for primitive keys:
 
 Worker process sends messages to the (main) UI process, to initiate UI 
 notification. If user clicks that notification main process will worker know 
 that given notification was clicked:
 
 (function(exports) {
 
 let id = 0
 let listeners = WeakMap()
 
 exports.notify = function notify({ onClick, message }) {
   if (onClick) listeners.set(++id, onClick)
   self.postMessage({ id: id, message: message })
 }
 
 self.onmessage = function({ id }) {
   let listener = listeners.get(id)
   if (listener) listener()
 }
 
 })(this)
 
 Is my use case invalid ? At the moment I use custom map implementation with a 
 limited size, once map hits the limit oldest entries will be removed. 
 
 Regards
 --
 Irakli Gozalishvili
 Web: http://www.jeditoolkit.com/
 Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)
 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Minimalist (why) classes ?

Hi, 

I have posted this to the long thread of Minimalist Classes, but since I have 
not got any response, I assume it got lost into a long discussion. So I thought 
I'll give it another try on fresh thread.

I do really liked direction that Jeremy tried to push classes to, but still I 
don't understand why do we need to introduce new syntax to the language. From 
what I can tell, lack of classes or special syntax for creating ones, is not a 
problem. Problem is amount of ceremony one needs to perform inherit or subclass 
if you like.

Also, I think we don't need new `class` expression to solve actual problems we 
have, simple function will do the job perfectly here, also it will add zero 
learning curve! I forked Jeremy's proposal and modified it to ilustrate how 
existing subclassing problems can be solved without introducing new constructs 
to the language or adding more verbosity. Please also note that there is 
nothing new here, lot's of frameworks do this already (hide prototype 
machinery), but each does it with it's own flavored API which is IMO another 
problem that standardization should solve. The classes problem is very similar 
to `Function.prototype.bind` that ES5 solved greatly, why not do the same for 
classes ? 

https://gist.github.com/1355701

In addition I tried to address few other concerns I had with a proposal:

-  `constructor` property as initializer is poor choice raising many questions 
(what will be prototype of constructor property if it's used in more then one 
class, if it's frozen etc).
- Some people in the community would love to have frozen classes others value 
flexibility, simple functions make it easy to build first out of second without 
becoming a second class citizen.


Please note, that I intentionally omitted `super` as it's separate problem that 
is / must be discussed in the separate thread / proposal.
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)



Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: WeakMaps question ?

I think what I need is a map with primitive keys and non-null object values, 
entries of which can be removed  GC-ied if values are no longer referenced. If 
I understand Map / Set / WeakMap proposals non of them can be used to solve 
this issue or do I miss something ? 

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Friday, 2011-11-11 at 15:39 , Oliver Hunt wrote:

 A weak map can only remove an entry if both the key and value have died, in 
 many ES implementations a number of the primitives are not gc allocated and 
 so can never die, or are cached globally so have lifetime unrelated to any 
 given program.
 
 The net effect of allowing such primitive values to be used as keys would be 
 to make the map strong and the associated values would not be able to be 
 collected.
 
 --Oliver
 
 On Nov 11, 2011, at 3:28 PM, Irakli Gozalishvili wrote:
  I really need to know why WeakMaps don't accept primitives as keys, can 
  anyone please reply ? 
  
  Thanks!
  --
  Irakli Gozalishvili
  Web: http://www.jeditoolkit.com/
  Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)
  
  
  On Thursday, 2011-11-10 at 10:31 , Irakli Gozalishvili wrote:
  
   Hi, 
   
   I was wondering what is a reason for disallowing non-object values as 
   keys in WeakMaps ?
   
   Also, I think I have a pretty good use case for primitive keys:
   
   Worker process sends messages to the (main) UI process, to initiate UI 
   notification. If user clicks that notification main process will worker 
   know that given notification was clicked:
   
   (function(exports) {
   
   let id = 0
   let listeners = WeakMap()
   
   exports.notify = function notify({ onClick, message }) {
 if (onClick) listeners.set(++id, onClick)
 self.postMessage({ id: id, message: message })
   }
   
   self.onmessage = function({ id }) {
 let listener = listeners.get(id)
 if (listener) listener()
   }
   
   })(this)
   
   Is my use case invalid ? At the moment I use custom map implementation 
   with a limited size, once map hits the limit oldest entries will be 
   removed. 
   
   Regards
   --
   Irakli Gozalishvili
   Web: http://www.jeditoolkit.com/
   Address: 29 Rue Saint-Georges, 75009 Paris, France 
   (http://goo.gl/maps/3CHu)
   
  
  ___
  es-discuss mailing list
  es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
  https://mail.mozilla.org/listinfo/es-discuss
 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minimalist (why) classes ?

Thats exact port of proposal that Jeremy wrote here:
https://gist.github.com/1329619 

I could write add examples from the classes proposal if that wolud help:
http://wiki.ecmascript.org/doku.php?id=harmony:classes

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Friday, 2011-11-11 at 16:05 , John J Barton wrote:

 On Fri, Nov 11, 2011 at 3:47 PM, Irakli Gozalishvili rfo...@gmail.com 
 (mailto:rfo...@gmail.com) wrote:
  Hi,
  I have posted this to the long thread of Minimalist Classes, but since I
  have not got any response, I assume it got lost into a long discussion. So I
  thought I'll give it another try on fresh thread.
  I do really liked direction that Jeremy tried to push classes to, but still
  I don't understand why do we need to introduce new syntax to the language.
  From what I can tell, lack of classes or special syntax for creating ones,
  is not a problem. Problem is amount of ceremony one needs to perform inherit
  or subclass if you like.
  Also, I think we don't need new `class` expression to solve actual problems
  we have, simple function will do the job perfectly here, also it will add
  zero learning curve! I forked Jeremy's proposal and modified it to ilustrate
  how existing subclassing problems can be solved without introducing new
  constructs to the language or adding more verbosity. Please also note that
  there is nothing new here, lot's of frameworks do this already (hide
  prototype machinery), but each does it with it's own flavored API which is
  IMO another problem that standardization should solve. The classes problem
  is very similar to `Function.prototype.bind` that ES5 solved greatly, why
  not do the same for classes ?
  https://gist.github.com/1355701
  
 
 
 Just FYI,
 
 I found the listing confusing, since the examples seem unrelated to
 each other and there is no reference to the corresponding 'class'
 proposal.
 
 jjb 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minimalist (why) classes ?

What I'm suggesting is to sugar current patterns, without adding new syntax 
similar to how Funciton.prototype.bind was added. And maybe in next iteration 
add special syntax if it still we be wanted. It's just so much easier to fix 
`Object.extend` if it will end up to be a wrong fit than change a special class 
syntax.

BTW I have updated examples to illustrate exactly what is problematic requires 
sugar https://gist.github.com/1355701

Class syntax is wanted to avoid some method calling boilerplate that's more 
verbose, 

In my examples it actually takes same amount of chars:

class Foo extends Bar {}

VS

var Bar = Foo.extend({})

arguably easier to get wrong, and harder to analyze and optimize. That's it. 

Arguably indeed, IMO increasing surface of language makes surface of things 
that can be made wrong bigger, increasing probability of making things wrong. 


Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Friday, 2011-11-11 at 16:31 , Brendan Eich wrote:

 On Nov 11, 2011, at 4:09 PM, Irakli Gozalishvili wrote:
 
  Thats exact port of proposal that Jeremy wrote here:
  https://gist.github.com/1329619 
  
  I could write add examples from the classes proposal if that wolud help:
  http://wiki.ecmascript.org/doku.php?id=harmony:classes
  
 
 
 Maybe, but I think that you'd be beating a dead horse.
 
 Class syntax is wanted to avoid some method calling boilerplate that's more 
 verbose, arguably easier to get wrong, and harder to analyze and optimize. 
 That's it.
 
 Hence, classes as sugar. If you find existing JS sweet enough, you won't 
 want classes.
 
 /be
 
  Regards
  --
  Irakli Gozalishvili
  Web: http://www.jeditoolkit.com/
  Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)
  
  
  On Friday, 2011-11-11 at 16:05 , John J Barton wrote:
  
   On Fri, Nov 11, 2011 at 3:47 PM, Irakli Gozalishvili rfo...@gmail.com 
   (mailto:rfo...@gmail.com) wrote:
Hi,
I have posted this to the long thread of Minimalist Classes, but 
since I
have not got any response, I assume it got lost into a long discussion. 
So I
thought I'll give it another try on fresh thread.
I do really liked direction that Jeremy tried to push classes to, but 
still
I don't understand why do we need to introduce new syntax to the 
language.
From what I can tell, lack of classes or special syntax for creating 
ones,
is not a problem. Problem is amount of ceremony one needs to perform 
inherit
or subclass if you like.
Also, I think we don't need new `class` expression to solve actual 
problems
we have, simple function will do the job perfectly here, also it will 
add
zero learning curve! I forked Jeremy's proposal and modified it to 
ilustrate
how existing subclassing problems can be solved without introducing new
constructs to the language or adding more verbosity. Please also note 
that
there is nothing new here, lot's of frameworks do this already (hide
prototype machinery), but each does it with it's own flavored API which 
is
IMO another problem that standardization should solve. The classes 
problem
is very similar to `Function.prototype.bind` that ES5 solved greatly, 
why
not do the same for classes ?
https://gist.github.com/1355701

   
   
   Just FYI,
   
   I found the listing confusing, since the examples seem unrelated to
   each other and there is no reference to the corresponding 'class'
   proposal.
   
   jjb 
  
  ___
  es-discuss mailing list
  es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
  https://mail.mozilla.org/listinfo/es-discuss
 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minimalist Classes

2011-11-10 Thread Irakli Gozalishvili

Hi,  

Sorry have not had a chance to reply on this thread earlier. I do really like 
the direction that Jeremy pushes to, but still I don't understand why do we 
need to introduce new syntax to the language. I think `class` expression is 
completely unnecessary, why not a function ? I forked Jeremy's proposal and 
modified it so that it preserves it's simplicity without introducing any new 
syntax to the language:

https://gist.github.com/1355701

In addition I changed few things that was raising additional questions:

-  `constructor` property as initializer (what if constructor is shared, frozen 
etc).

I also intentionally omitted `super` as it's separate topic.  
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Thursday, 2011-11-03 at 11:33 , Brendan Eich wrote:

 On Nov 3, 2011, at 6:53 AM, Matthew Tretter wrote:
  
  Sorry, I'll try to be more clear.
   
  What's super-intuitive isn't *that* you use the form class name expr, 
  it's how you interact with that form once you know what it does. The reason 
  is self-evident—people know how to work with object literals and functions.
  
 Then we are not talking about the same thing.
  
 Class syntax of the form class C {...} where the {...} is an extension of 
 ES3-5 ObjectLiteral syntax is fine, we're aligned on that (for the moment).
  
 The particular form from Jeremy's gist:
  
 // Note that the right-hand side of a class definition is just an expression,
 // an object literal is not required. You can be fully dynamic when creating a
 // class:
  
 class Student objectContainingStudentProperties
 line 59 on at https://gist.github.com/1329619
  
 is what is at issue.
  
  
  This is not true of the Leather form which, like I said, would probably 
  inspire a lot of run(a){…} attempts at function definitions in non-class 
  contexts.
  
 Different topic yet again, but ok: method definition syntax was already 
 proposed a while ago by Allen, and promoted to Harmony for ES.next. It may 
 cause some Dart-like 'function'-lacking misplaced method definition attempts, 
 indeed. We should see how big a problem this is in practice. I doubt it'll be 
 more than a speed-bump for some, but if it is, we can adapt.
  
  
  Not that that alone is enough to disqualify it, but it's something that 
  should be taken into consideration.
  
 Agreed.
  
  
  Off the top of my head, one use-case would be Python-like method decorators:
   
  class Runner {
  run: require_auth(function(a) {
  })
  }
   
  Another would be the dynamic definition of methods:
   
  class Runner {
  run: (function() {
  return someFeatureIsSupported ? feature : polyfill;
  })()
  }
   
  
  
 These are still legal, with class body built on extended object literals. Why 
 did you think these would be verboten?
  
 It's one thing to say these should work. It's another to insist that the 
 long-hand should be the only way.
  
 /be
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss
  
  


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Enums?

2011-10-25 Thread Irakli Gozalishvili



On Monday, 2011-10-03 at 19:17 , David Herman wrote:

 A couple reactions:
 
 - strings are already interned in current engines for symbol-like 
 performance; there's no need to introduce symbols into the language
 


Assuming that's about Ruby like 
[symbols](http://www.ruby-doc.org/core-1.9.2/Symbol.html) or Clojure like 
[keywords](http://clojure.org/data_structures#toc8). While they are not much 
different from strings I really miss them in JS. Also I think clojure uses them 
in a very interesting way:


(use 'clojure.contrib.shell-out :as shell :reload) 

or even more intensive 

(ns com.my-company.clojure.examples.my-utils (:import java.util.Date) (:use 
[clojure.contrib.def :only (defvar-)]) (:require [clojure.contrib.shell-out :as 
shell]))

Problem with strings is that it's not always obvious weather it's intended 
argument to the function or a flag.  
 
 - private names are overkill for most uses of enums; just use string literals
 
 - in SpiderMonkey I think you get better performance if your switch cases use 
 known constants; for example:
 
  const RED = red, GREEN = green, BLUE = blue;
  ...
  switch (color) {
  case RED: ...
  case GREEN: ...
  case BLUE: ...
  }
 
 - with modules, you would be able to define these consts and share them 
 modularly (currently in SpiderMonkey the only way to share these definitions 
 across modules as consts is either to make them global or to share an 
 eval-able string that each module can locally eval as a const declaration -- 
 blech)
 
 Dave
 
 On Sep 30, 2011, at 7:13 PM, Axel Rauschmayer wrote:
 
  One language feature from JavaScript that I miss are enums. Would it make 
  sense to have something similar for ECMAScript, e.g. via 
  Lisp-style/Smalltalk-style symbols plus type inference? If yes, has this 
  been discussed already? I feel strange when I simulate symbols with strings.
  
  -- 
  Dr. Axel Rauschmayer
  
  a...@rauschma.de (mailto:a...@rauschma.de)
  twitter.com/rauschma (http://twitter.com/rauschma)
  
  home: rauschma.de (http://rauschma.de)
  blog: 2ality.com (http://2ality.com)
  
  
  
  ___
  es-discuss mailing list
  es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
  https://mail.mozilla.org/listinfo/es-discuss
 
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: new Object

2011-10-17 Thread Irakli Gozalishvili

I think we should just forget about new keyword, prototype property all 
togather and move towards something more simple: 

var proto = {
  method: function() { },
  new: function() {
var self = Object.create(this);
this.initialize.apply(self, arguments);
return self;
  },
  initialize: function(someValue) {
this.things = someValue
  }
}

var o = proto.new(someValue);

Of course with a help of library that would not require as much boilerplate: 
https://github.com/Gozala/selfish  


Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Tuesday, 2011-10-11 at 20:53 , Jake Verbaten wrote:

 is there any kind of proposal for syntax that is like :
 
 var proto = {
   method: function() { },
   constructor: function(someValue) {
 this.things = someValue
   }
 };
 
 var o = new proto(someValue);
  Object.getPrototype(o) === proto; // true
 
 basically defining how `new` operates on an object (that is to represent the 
 prototype). It is basically equivelant to
 
 var Constructor = function () { ... }
 constructor.prototype = {
   method: ...
   constructor: Constructor
 }
 
 var o = new Constructor(someValue);
 
 To me personally the whole duplication the Constructor on 
 Constructor.prototype.constructor and having .prototype on a function is less 
 elegant.
 
 Initial concerns with such syntax :
 
  - new { ... }(parameters) may be difficult to parse
  - new protoObj.call(...) is not going to work (protoObj does not have 
 Function.prototype in it's prototype chain), should it work?
  - new protoObj(); should probably throw an error if protoObj.constructor is 
 not defined.
  - should we invoke a constructor property of a protoObj that is not it's own 
 property
  - the new operator is confusing enough as it is
 
 Advantages:
 
  - this syntax would map more closely with the proposed declarative class 
 syntax. So class could just be a sugar for generating objects you can invoke 
 with new.
  - For any well formed existing code (where .prototype.constructor is set) 
 new existingObject() should generate a new object with existingobject as it's 
 prototype and having called the nearest constructor property
  - constructor property is optional so new someObject is just sugar for 
 Object.create(someObject)
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: new Object

2011-10-17 Thread Irakli Gozalishvili




Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Monday, 2011-10-17 at 11:16 , Jake Verbaten wrote:

 I do the same with
 Object.prototype.new = function () { 
   var o = Object.create(this);
   o.constructor  o.constructor.apply(o, arguments);
   return o;
  } 
 However rather then calling proto.new(); I would like var o = new proto(); 
 
 


May I ask why (less syntax in language is better no) ?
 
 and o instanceof proto to work
 
 


You have proto.isPrototypeOf(o) instead.
  
 
  On Oct 17, 2011 9:17 AM, Irakli Gozalishvili rfo...@gmail.com 
  (mailto:rfo...@gmail.com) wrote:
  
  I think we should just forget about new keyword, prototype property all 
  togather and move towards something more simple: 
   var proto = {   method: function() { },
new: function() {
  var self = Object.create(this);
  this.initialize.apply(self, arguments);
  return self;
},
initialize: function(someValue) {
  this.things = someValue
}
  }
  
  var o = proto.new(someValue);
  
  Of course with a help of library that would not require as much 
  boilerplate: https://github.com/Gozala/selfish  
  
  
  Regards
  --
  Irakli Gozalishvili
  Web: http://www.jeditoolkit.com/
  Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)
  
  On Tuesday, 2011-10-11 at 20:53 , Jake Verbaten wrote:
 is there any kind of proposal for syntax that is like :   var proto 
 = {method: function(...
   ___
   es-discuss mailing list
   es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
   https://mail.mozilla.org/listinfo/es-discuss
  

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

doc for functions, classes, objects etc.

2011-09-02 Thread Irakli Gozalishvili

I also prototyped this idea mainly for node. Also, I figured out a hack with
a label, that make it work for spidermonkey.


Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France http://goo.gl/maps/3CHu

On Thursday, 2011-09-01 at 20:28 , Dmitry A. Soshnikov wrote:

On 31.08.2011 18:38, Allen Wirfs-Brock wrote:

On Aug 31, 2011, at 1:57 AM, Dmitry A. Soshnikov wrote:

On 30.08.2011 20:39, Allen Wirfs-Brock wrote:

On Aug 30, 2011, at 12:39 AM, Dmitry A. Soshnikov wrote:

OK, let's up the topic. Seems there are no technical issues in the proposed
thing -- we can simply either accept it or not. The question is whether it's
needed and sound proposal and the feature to have in ECMAScript.

There certainly are technical issues.

To start, by making this part of the core language you would be defining a
feature that can be used by any application code. For example, a program
might choose to encode essential runtime metadata as its documentation.
Because of that possibility, the [[Documentation]] information must always
be available at runtime. Minimizers or obfuscators could not remote
documentation comments because of the possibility of breaking such programs.

Sure, though I don't think that application level code have to be dependent
in logic on documentation string. The doc-string is just the _addition for
debug_. No more, no less. It's when you use a new lib (my example with
Redis's `get` method which should accept callback), you just get this help
directly from here without going to some websites (which can even be down
for this time) and solve the problems much faster. And for minified scripts,
I think the option Remove doc-comments is the case.

When designing language features, a designer always has some specific use
cases in mind. But that doesn't restrict users of the language from
discovering other use cases. Once a feature is incorporated into a language,
implementation have to support all possible use cases, not just the original
intended use case. That's why it is important for language designer to think
broadly about all conceivable uses and feature interaction when extending a
language. Sure, no application is required to have logic dependencies upon
the content of a documentation string but once they exist any application
could have such dependencies. As a language designers you have to think
about the implications of such usages. It isn't good enough to just say that
wasn't the intended use of the feature.

Yes, of course it's true, we have to consider the most hardcore
use-cases of our programs. Well, then I have to think on it, but the
first thing which comes in mind -- already mentioned Remove
doc-comments option for minifiers, i.e. a user himself is responsible
for this action. Moreover, minification is again mostly for
browser-scripting, where this help(...) functionality isn't so required
as it is for the server programming in the console.

And for the later case I wrote a simple version of such a pre-processor:
https://gist.github.com/1186853

Simple example:

/**
* sum
* @param {Number} x
* @param {Number} y
* The function of summation.
*/
function sum(x, y) {
return x + y;
}

/**
* multSum
* @param {Number} x
* @param {Number} y
* @param {String} value
* The function of calculation.
*/
function calculate(x, y, value) {
// comment
print(value + :  + sum(x, y));
}

// -- Test documentation --

// Result:

// Help on sum function:
//
// /**
// * sum
// * @param {Number} x
// * @param {Number} y
// * The function of summation.
// */
help(sum);

// Help on calculate function:
//
// /**
// * multSum
// * @param {Number} x
// * @param {Number} y
// * @param {String} value
// * The function of calculation.
// */
help(calculate);

// -- Test guards --

sum(1, 2); // 3, OK

calculate(1, 2, value); // value: 3

sum(1, 2); // TypeError: y must be a number

calculate(1, 2, 4); // TypeError: value must be a string

Dmitry.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss



-- 
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France http://goo.gl/maps/3CHu
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: doc for functions, classes, objects etc.

2011-09-02 Thread Irakli Gozalishvili



On Saturday, 2011-09-03 at 24:55 , Oliver Hunt wrote:

 
 On Sep 2, 2011, at 3:41 PM, Brendan Eich wrote:
  On Sep 2, 2011, at 3:29 PM, Irakli Gozalishvili wrote:
   On Friday, 2011-09-02 at 22:28 , Brendan Eich wrote:
Can you show your label hack for SpiderMonkey to es-discuss?

   
   Ahh sorry I did not realized I forgot to post link:
   
   https://github.com/Gozala/doc 
  Cool! Permit me to cite some of your README content to help promote to 
  those who did not click ;-) -- here it is:
  
  var doc = require('doc').doc doc(doc) // Prints following output: /* 
  function doc(source) { ... } 
  --- Prints documentanion of the 
  given function */ // You can also document your own functions: function 
  compose() { doc: Returns the composition of a list of functions, where 
  each function | consumes the return value of the function that follows. 
  In math | terms, composing the functions `f()`, `g()`, and `h()` 
  produces | `f(g(h()))`. | Usage: | var greet = function(name) { 
  return 'hi: ' + name } | var exclaim = function(statement) { return 
  statement + '!' } | var welcome = compose(exclaim, greet) | 
  welcome('moe') | // 'hi: moe!' 
 
 Function.toString isn't standardised, and I recall that in the past SM did 
 elide dead code, multiple engines reformat code, so in general this doesnt 
 seem reliable at a library level. 

Yeap toString is not reliable, but hey it works just fine on most engines I 
know ;) Also SM strips out dec code that's why I use label hack so that it 
keeps it :) 

 It also doesn't work for builtin functions, and I feel we'd want a solution 
 that allows documentation for builtin functions as well.
 
 
 


In fact `doc` function will work with built-ins just fine, even though output 
is not that useful:

 doc(Array.prototype.slice)

 function slice($1, $2) { ... }


 
 From the pov of runtime identification, we'd be in the odd position of having 
 to try and identify valid code as being documentation.
 
 This shouldn't be taken as support for this idea (documentation as part of 
 the language) as I feel that this is the type of feature i'd associate with 
 the development environment rather than part of the language.
 
 --Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Subject: Re: Harmony - proxies | asynchronous

2011-09-02 Thread Irakli Gozalishvili

In case someone is interested I've experimented with proxy sugared promises (it 
was long time ago some few things might require updates):

https://github.com/Gozala/meta-promise 


Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Monday, 2011-09-05 at 23:37 , Dmitry Soshnikov wrote:

 On 03.09.2011 1:26, John J Barton wrote:
  I'm pretty puzzled by this discussion and I'm guessing other folks 
  might be puzzled as well. Since I understood node fibers as thread 
  for Node, the discussion I read is:
  
   /be: You can have threads!
   Mikeal: We don't want threads!
  
  If I'm on the right track, then I should understand how this relates 
  to proxies. But I don't. Any hints?
 Don't be worry :) the topic is a little bit changed. Initially it was 
 asked how to provide asynchronous property readings (proxy's `get` trap, 
 or a simple accessor's get which call some deferred action) in the 
 syncronious view. And consuming generators (being a technique of 
 implementation of cooperative processes) allow to do this, since can 
 suspend a process and resume it from the next line, i.e. representing 
 asynchronous in syncronious view.
 
 But, that's said, even more elegant of such a technique would be either 
 syntactic transformation at compilation level, or creation of implicit 
 task-wrapper with a sugar for `yield` in this case. Regarding not using 
 `yield` for improving asynchronous programming -- I also didn't 
 understand the reasons. Because currently programming in Erlang (which 
 have the same green thread which are managed by an _implicit_ 
 scheduler) I can say that Node.js's spagetty-code with nested callbacks 
 just, sorry, sucks in comparison with Erlang's which is also 
 asynchronous, but allows to write it all in the synchronous manner. 
 Though, the topic is not about Erlang...
 
 Dmitry.
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: prototype focus

I absolutely agree with Alex and have few other points:

1. Does this code looks familiar ?

 function Foo(options) {  }
 Foo.prototype.do_foo_job = function() { ... }
 
 function Bar(options) {
 if (!(this instanceof Bar))
  return this new Bar(options);
 Foo.apply(this, arguments);
 }
 Bar.prototype.do_bar_job = function() {
  
 }
 

With focus on prototype this is so much simpler: 


var Foo = Object.extend({
 initialize: function(options) { ... },
do_foo_job: function() { ... }
})


On Friday, 2011-07-01 at 11:10 , Axel Rauschmayer wrote:

  I don't think
  JavaScript has ever been far from its prototype roots especially if
  the programmer shifts to thinking about a prototype object instead of
  thinking about a functions prototype property.
 
 That is basically the point that the proposal tries to make. Have you taken a 
 look at the library code? It is very short and not a radical overhaul.
 http://dl.2ality.com/dl/2011/06/Proto.js
 
 Note how below, there is always an extra prototype in there with 
 constructor functions.
 
 Super-calls (there will be syntactic sugar for this):
 - Constructor functions: Superclass.prototype.foo.call(this)
 - PAC: Superclass.foo.call(this)
 
 Subclassing:
 - Constructor functions: Subclass.prototype = 
 Object.create(Superclass.prototype)
 - PAC: let Subclass = Object.create(Superclass)
 
 Instanceof (internally):
 - Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
 - PAC: o instanceof C === C.isPrototypeOf(o)
 
 
   Problems that both prototypes-as-classes (PAC) and class literals (CL) are
   trying to solve are:
   - Subclassing is hard and not directly supported by the language: 
   connecting
   prototypes, chaining constructors, super-references.
  
  Object.getPrototypeOf(this).foo.call(this) is pretty long.
 
 See above.
 
  It seems to me that perhaps the PaC drifted too far or perhaps started
  too far from what JavaScript has already. If the idea is to shift the
  focus more towards prototypes, then starting from something like what
  I've written and adding super syntax would be more consistent with
  what JavaScript already has.
 
 
 “too far from what JavaScript has already” is very vague. How so? With class 
 literals, your code will look like PAC, anyway. Have you taken a look at 
 Sect. 3? Do you agree that the mentioned conceptual simplifications hold?
 http://www.2ality.com/2011/06/prototypes-as-classes.html#3
 
 I find Brendan’s anti-PAC argument much more convincing: that all people 
 might find it more natural to think in terms of constructors than in terms of 
 prototypes. If that is the case then PAC would be a bad idea. The other 
 convincing anti-PAC argument is that it is a bad idea to have two class 
 mechanisms.
 
 -- 
 Dr. Axel Rauschmayer
 
 a...@rauschma.de (mailto:a...@rauschma.de)
 twitter.com/rauschma (http://twitter.com/rauschma)
 
 home: rauschma.de (http://rauschma.de)
 blog: 2ality.com (http://2ality.com)
 
 
 
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: prototype focus

Sorry I did not intended to send email yet:

So here is my points:

1. Does this looks familiar (version with syntax highlighting 
https://gist.github.com/1058534) 

function Foo(options) {  }
Foo.prototype.do_foo_job = function() { ... }

function Bar(options) {
if (!(this instanceof Bar))
return this new Bar(options);
Foo.apply(this, arguments);
}
Bar.prototype = Object.create(Foo.prototype);
Bar.prototype.do_bar_job = function() {  };

With focus on prototypes it's as simple as this:
var Foo = Object.extend({
initialize: function(options) { ... },
do_foo_job: function() { ... }
})

var Bar = Foo.extend({
do_bar_job: function() { ... }
})

Why should not be I able to reuse initialization function, or why do I have to 
create constructor function for all classes / subclasses ?

2. With a constructor focused classes you end up maintaing two sets of 
properties: 1. prototype properties and 2. (java static like) constructor 
properties, which adds complexity requires dedicated syntax in declarative 
classes syntax.

3. It could be my personal, internal conflict, but I seriously can't see any 
reason for `constructor` to be a special among all other methods, by having 
privilege to hold a reference to a prototype object (I don't even mention that 
this reference is circular by default). Overall `prototype` property feels like 
hack to emulate Java like classes.

4. With focus on prototypes there is potential to further reduce language 
syntax (hopefully new, instanceof will die off) instead of cluttering even 
further. 

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Friday, 2011-07-01 at 15:19 , Irakli Gozalishvili wrote:

 I absolutely agree with Alex and have few other points:
 
 1. Does this code looks familiar ?
 
  function Foo(options) {  }
  Foo.prototype.do_foo_job = function() { ... }
  
  function Bar(options) {
  if (!(this instanceof Bar))
   return this new Bar(options);
  Foo.apply(this, arguments);
  }
  Bar.prototype.do_bar_job = function() {
   
  }
  
 
 With focus on prototype this is so much simpler: 
 
 
 var Foo = Object.extend({
  initialize: function(options) { ... },
 do_foo_job: function() { ... }
 })
 
 
 On Friday, 2011-07-01 at 11:10 , Axel Rauschmayer wrote:
 
   I don't think
   JavaScript has ever been far from its prototype roots especially if
   the programmer shifts to thinking about a prototype object instead of
   thinking about a functions prototype property.
  
  That is basically the point that the proposal tries to make. Have you taken 
  a look at the library code? It is very short and not a radical overhaul.
  http://dl.2ality.com/dl/2011/06/Proto.js
  
  Note how below, there is always an extra prototype in there with 
  constructor functions.
  
  Super-calls (there will be syntactic sugar for this):
  - Constructor functions: Superclass.prototype.foo.call(this)
  - PAC: Superclass.foo.call(this)
  
  Subclassing:
  - Constructor functions: Subclass.prototype = 
  Object.create(Superclass.prototype)
  - PAC: let Subclass = Object.create(Superclass)
  
  Instanceof (internally):
  - Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
  - PAC: o instanceof C === C.isPrototypeOf(o)
  
  
Problems that both prototypes-as-classes (PAC) and class literals (CL) 
are
trying to solve are:
- Subclassing is hard and not directly supported by the language: 
connecting
prototypes, chaining constructors, super-references.
   
   Object.getPrototypeOf(this).foo.call(this) is pretty long.
  
  See above.
  
   It seems to me that perhaps the PaC drifted too far or perhaps started
   too far from what JavaScript has already. If the idea is to shift the
   focus more towards prototypes, then starting from something like what
   I've written and adding super syntax would be more consistent with
   what JavaScript already has.
  
  
  “too far from what JavaScript has already” is very vague. How so? With 
  class literals, your code will look like PAC, anyway. Have you taken a look 
  at Sect. 3? Do you agree that the mentioned conceptual simplifications hold?
  http://www.2ality.com/2011/06/prototypes-as-classes.html#3
  
  I find Brendan’s anti-PAC argument much more convincing: that all people 
  might find it more natural to think in terms of constructors than in terms 
  of prototypes. If that is the case then PAC would be a bad idea. The other 
  convincing anti-PAC argument is that it is a bad idea to have two class 
  mechanisms.
  
  -- 
  Dr. Axel Rauschmayer
  
  a...@rauschma.de (mailto:a...@rauschma.de)
  twitter.com/rauschma (http://twitter.com/rauschma)
  
  home: rauschma.de (http://rauschma.de)
  blog: 2ality.com (http://2ality.com)
  
  
  
  ___
  es-discuss mailing list
  es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
  https://mail.mozilla.org/listinfo/es

Re: prototype focus



On Friday, 2011-07-01 at 16:38 , Mark S. Miller wrote:

 On Fri, Jul 1, 2011 at 7:18 AM, Sean Eagan seaneag...@gmail.com 
 (mailto:seaneag...@gmail.com) wrote:
  On Fri, Jul 1, 2011 at 8:45 AM, Irakli Gozalishvili rfo...@gmail.com 
  (mailto:rfo...@gmail.com) wrote:
  
   why do I have to create constructor function for all classes / subclasses 
   ?
 
 This magic trades confusion for convenience. In any earlier version of the 
 proposal, I actually had a traditional default constructor, the equivalent of 
 
  constructor() { super(); }
 
 but others argued against it. Sorry don't remember who. There were plenty of 
 off list discussions to gather consensus. On this one, I didn't feel strongly 
 either way, but I eventually agreed with the objectors. When in doubt, throw 
 it out -- even more important in language design than in writing. 
 
  
  This could be handled by class literals by allowing for default
   constructors. If one doesn't provide a constructor, the following one
   could be provided:
  
   constructor(... args) {
  super(... args);
   }
 
 This one I object to because those used to other languages that provide such 
 default constructors will only call the super constructor with no arguments. 
 Though now that you mention it, I can see why JSers without exposure to other 
 languages may naturally expect your's. 
 
 With two expectations for the semantics of something that does not appear in 
 the code, and without a static or dynamic rejection to prevent progress of 
 the code written to the wrong assumption, I now finally feel strongly about 
 this. The critics were right -- we should not provide any default 
 constructor. Thanks for pointing out the problem case. 
 
 
 
 


Do you think prototype focused version:

Prototype.new(foo);

also suggest wrong assumptions ? If not (which I think is the case) is another 
+ in favor of prototype focus. 

 -- 
  Cheers,
  --MarkM

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: prototype focus



On Friday, 2011-07-01 at 19:31 , Brendan Eich wrote:

 On Jul 1, 2011, at 6:19 AM, Irakli Gozalishvili wrote:
 
  With focus on prototype this is so much simpler: 
  
  
  var Foo = Object.extend({
   initialize: function(options) { ... },
  do_foo_job: function() { ... }
  })
  
  
  
  
  
  
 
 
 With | and 'super' in functions, I think you are set. It's hard to add more. 
 The main debate is about whether this is enough, or do classes as sugar 
 provide enough added value?
 
 (But you didn't show Bar as well as Foo.)
 

Sorry I don't understand what did I failed to show in Bar ?

My intent was to show that classes don't necessary need to have own 
constructors / initialization methods as they can be
simply inherited via prototype chain. Or did you meant something else ? 

 /be
 
 
  
  
  On Friday, 2011-07-01 at 11:10 , Axel Rauschmayer wrote:
  
I don't think
JavaScript has ever been far from its prototype roots especially if
the programmer shifts to thinking about a prototype object instead of
thinking about a functions prototype property.
   
   That is basically the point that the proposal tries to make. Have you 
   taken a look at the library code? It is very short and not a radical 
   overhaul.
   http://dl.2ality.com/dl/2011/06/Proto.js
   
   Note how below, there is always an extra prototype in there with 
   constructor functions.
   
   Super-calls (there will be syntactic sugar for this):
   - Constructor functions: Superclass.prototype.foo.call(this)
   - PAC: Superclass.foo.call(this)
   
   Subclassing:
   - Constructor functions: Subclass.prototype = 
   Object.create(Superclass.prototype)
   - PAC: let Subclass = Object.create(Superclass)
   
   Instanceof (internally):
   - Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
   - PAC: o instanceof C === C.isPrototypeOf(o)
   
   
 Problems that both prototypes-as-classes (PAC) and class literals 
 (CL) are
 trying to solve are:
 - Subclassing is hard and not directly supported by the language: 
 connecting
 prototypes, chaining constructors, super-references.

Object.getPrototypeOf(this).foo.call(this) is pretty long.
   
   See above.
   
It seems to me that perhaps the PaC drifted too far or perhaps started
too far from what JavaScript has already. If the idea is to shift the
focus more towards prototypes, then starting from something like what
I've written and adding super syntax would be more consistent with
what JavaScript already has.
   
   
   “too far from what JavaScript has already” is very vague. How so? With 
   class literals, your code will look like PAC, anyway. Have you taken a 
   look at Sect. 3? Do you agree that the mentioned conceptual 
   simplifications hold?
   http://www.2ality.com/2011/06/prototypes-as-classes.html#3
   
   I find Brendan’s anti-PAC argument much more convincing: that all people 
   might find it more natural to think in terms of constructors than in 
   terms of prototypes. If that is the case then PAC would be a bad idea. 
   The other convincing anti-PAC argument is that it is a bad idea to have 
   two class mechanisms.
   
   -- 
   Dr. Axel Rauschmayer
   
   a...@rauschma.de (mailto:a...@rauschma.de)
   twitter.com/rauschma (http://twitter.com/rauschma)
   
   home: rauschma.de (http://rauschma.de/)
   blog: 2ality.com (http://2ality.com/)
   
   
   
   ___
   es-discuss mailing list
   es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
   https://mail.mozilla.org/listinfo/es-discuss
  
  ___
  es-discuss mailing list
  es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
  https://mail.mozilla.org/listinfo/es-discuss
 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

2011-06-29 Thread Irakli Gozalishvili

There have been multiple thread on this and I did not know were to comment, so 
I'll add few comments here.

I think that whole constructors as classes business in JS is confusing for 
everyone coming to JS, and they only understand it after understanding 
confusing constructor- prototype relationship.

It is true that people find 

var point = new Point(x, y)
point instanceof Point

intuitive but that's because it looks like Java. Also they are quite puzzled to 
find out that in some cases:

var point = Point(x, y)

works the same.

On the other hand people may find Point.new(x, y) as intuitive, as they will 
think of ruby instead of java. Also, I do not think there is a point to use 
`constructor` with all it's confusing prototype relationships for 
initialization in prototypes as classes, just use initialize method to do 
that. 

Is it really too late to undo `constructor` as classes ? There are other 
proposals like rest and spread with a hope that `arguments` will die off some 
day. Why this would be different ?

Finally I believe that killing constructors will make js straight forward to 
understand and lighter in syntax.

And not everyone tries to emulate classical inheritance today:
http://javascript.crockford.com/prototypal.html


Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Thursday, 2011-06-30 at 24:24 , Axel Rauschmayer wrote:

  Last concrete disagreement we had was over new C() vs. C() in the current 
  language being notably different from new C() vs. C.constructor() in the 
  alternate-reality language with prototypes as classes.
 
 
 As in “don’t mix too well”. I agree with that. That will be a challenge for 
 class literals. But the abstraction argument might apply to both cases: If 
 people see a class C, they just want to instantiate it via new C(x,y). As 
 long as instanceof works accordingly afterwards, I’m not sure much has 
 changed *superficially*.
 
 -- 
 Dr. Axel Rauschmayer
 
 a...@rauschma.de (mailto:a...@rauschma.de)
 twitter.com/rauschma (http://twitter.com/rauschma)
 
 home: rauschma.de (http://rauschma.de)
 blog: 2ality.com (http://2ality.com)
 
 
 
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Understanding Irakli’s code (new protocol)

2011-06-24 Thread Irakli Gozalishvili




On Friday, 2011-06-24 at 21:13 , Axel Rauschmayer wrote:

 I’m trying to understand all the implications of Irakli’s code.
 
 https://gist.github.com/d33befccbe1e0ed492d5
 
  Object.prototype.new = function new() {
  return new this.constructor();
  };
  Object.prototype.extend = function extend(properties) {
  var constructor = new Function(), descriptor = {};
  properties = properties || {};
  Object.getOwnPropertyNames(properties).forEach(function(name) {
  descriptor[name] = Object.getOwnPropertyDescriptor(properties, name);
  });
  descriptor.constructor = { value: constructor };
  return Object.freeze(constructor.prototype = Object.create(this, 
 descriptor));
  };
 
  Object.new = function new() {
  return Object.prototype.new();
  };
  Object.extend = function extend(properties) {
  return Object.prototype.extend(properties);
  };
 
 Questions:
 
 1. Do new and extend really work properly on any built-in other than 
 Object?
  - E.g., I would expect String.extend() to lead to the invocation of 
 Object.prototype.extend() which assumes this to be a prototype, but it is a 
 constructor.
  - This could be fixed by checking whether this is a function and then 
 acting accordingly. Or by setting up a constructor/class method extend for 
 each built-in.
I have not tried or thought much about other build-ins as showing idea was a 
main point. Yeah I was thinking that similar methods could be created per 
build-ins if necessary.


 2. I don’t like that new() methods have to keep the result of super.new() and 
 return it. I would prefer something like the code below, which enables a 
 constructor behavior like in Allen’s example.
 
I personally think that whole prototype, constructor and new keyword 
relationships add a lot of complexity to a language, and since this was fitting 
discussion nicely I though I'd share idea how this can be evolved to something 
more straight forward, that fits language much more IMO. I like new as a method 
because code is becomes simple and obvious. 

 3. Are my changes really an improvement or do they impede proper interaction 
 with built-ins, somehow?
 
 = Library code =
 
 // Optional, possibly faster: split the method below into 
 Object.prototype.new and Function.prototype.new (the latter overriding the 
 former)
 Object.prototype.new = function new() {
  if (this instanceof Function) {
  return new this();
  } else {
  return new this.constructor();
  }
 }; 
 // Performance is less of an issue for this method
 Object.prototype.extend = function extend(properties) {
  var superProto;
  if (this instanceof Function) {
  superProto = this.prototype;
  } else {
  superProto = this;
  }
  var descriptor = {};
  properties = properties || {};
  Object.getOwnPropertyNames(properties).forEach(function(name) {
  descriptor[name] = Object.getOwnPropertyDescriptor(properties, name);
  });
  var thisProto = Object.create(superProto, descriptor);
  if (thisProto.constructor) {
  thisProto.constructor.prototype = thisProto;
  }
  thisProto.__super__ = superProto;
  return thisProto;
 };
 
 // Optional: split the method below into Object.prototype.hasInstance and 
 Function.prototype.hasInstance
 Object.prototype.hasInstance = function extend(instance) {
  if (this instanceof Function) {
  return instance instanceof this;
  } else {
  return this.isPrototypeOf(instance);
  }
 };

In my library I just use Foo.isPrototypeOf(bar);
https://github.com/Gozala/selfish

 
 / Not necessary, any more (Object instanceof Object)
 Object.new = function new() {
  return Object.prototype.new();
 };
 Object.extend = function extend(properties) {
  return Object.prototype.extend(properties);
 };
 /
 
 = Using the library =
 
 const SkinnedMesh = THREE.Mesh.extend({
  constructor: function SkinnedMesh(geometry, materials) {
  SkinnedMesh.__super__.constructor.apply(this, arguments);
  // initialize instance properties
  this.identityMatrix = THREE.Matrix4.new();
  this.bones = [];
  this.boneMatrices = [];
  },
  update: function(camera) {
  ...
  // call base version of same method
  SkinnedMesh.__super__.update.call(this);
  }
 });
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is class syntax really necessary ?

2011-06-13 Thread Irakli Gozalishvili

Ok I wrote up another gist

https://gist.github.com/7e649e8c33d412e90178

that no longer refers to any non-existing functions like `Function.create` and 
addresses `super` sugar issue using `base` function (In a similar way as in 
Dmitry's link).

Also, implementation uses deprecated `caller`, non-standard `__proto__` , 
pseudo internal properties [[target]]', '[[name]]', '[[this]]' and function 
wrappers, but I hope / assume native implementation will be able to achieve 
same results without any of those.

One disadvantage in comparison to `super` is that you can no longer call 
overlaid X methods from Y method, from my experience thats pretty rare case and 
can easily be workarounded. Alternatively base can have be improved using 
proxies to support base[X](a, b) case as well.

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Monday, 2011-06-13 at 24:49 , Brendan Eich wrote:

 On Jun 12, 2011, at 3:38 PM, Irakli Gozalishvili wrote:
 
  On Monday, June 13, 2011, Brendan Eich bren...@mozilla.com 
  (mailto:bren...@mozilla.com) wrote:
   On Jun 12, 2011, at 3:18 PM, Irakli Gozalishvili wrote:On Monday, 
   2011-06-13 at 24:03 , Brendan Eich wrote:
   
On Jun 12, 2011, at 2:52 PM, Irakli Gozalishvili wrote:
Here is gist I wrote 
   before:https://gist.github.com/986487#file_implementation.js
   What Function.create are you using there?
   Is there a missing return statement in function extend?
   Yeap, sorry! It's there now.
   Ok. But what is that Function.create your gist relies on?
  
  
  It was proposed before I believe, it's like Object.create
  
  
  Function.create = function (proto, func) {
   var f = function() {
   return func.apply(this, arguments);
   }
   f.__proto__ = proto
   return f
  }
 
 No, that was too proxy-like. See
 
 http://wiki.ecmascript.org/doku.php?id=strawman:name_property_of_functions
 
 Starting at The major objection to losing 
 
 
   Another idea I had was that super can be similar to private. Here is some 
   example:
   Please note that the private(this)/private(other) syntax is intentional 
   straw, to be burned up and replaced with something better.
   I think you're trying to self-host too much. People can write classes the 
   hard way, with super too. They need sugar, not salt or pepper ;-).
   /be
  
  I just don't know how wild I can go with idea :) Isn't it better to
  leave off super for the moment and tackle that separately ?
 
 Not obviously. super outside of classes does not necessarily pay for itself 
 (I did not remember it going to Harmony at the last meeting). And super 
 inside of class should pay off as the classes proposal hopes -- 'super' in 
 that context has no open issues.
 
 /be
 /be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is class syntax really necessary ?

Hi,

Is there anything else (other than starting this thread) I can do to make 
committee consider `Function.prototype.extend` as an alternative to a proposed 
class sugar ? 

Thanks
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)


On Tuesday, 2011-05-24 at 24:48 , Brendan Eich wrote:

 On May 23, 2011, at 11:25 AM, Bob Nystrom wrote:
 
  One thing I'd like the proposal to support, which it doesn't currently, is 
  initializers on instance property declarations. Then you could do: 
  
   class C { 
public _list = [];
   
   
   }
   
   
   
  
  
  With that, you'll correctly get a new _list on each instance of C when it's 
  created. 
 But (we've argued, I forget where so repeating it here), this looks like [] 
 is evaluated once when the class declaration is evaluated. That is not what 
 you intend.
 
 Then at some point (in the last thread on this) I remembered parameter 
 default values, but they cover only missing parameters to the constructor. 
 This _list member could be private. But it has to be initialized in a body 
 that executes once per instantiation, which is not the class body -- it's the 
 constructor body.
 
 /be
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is class syntax really necessary ?


On Sunday, 2011-06-12 at 23:18 , Brendan Eich wrote:

 On Jun 12, 2011, at 2:22 AM, Irakli Gozalishvili wrote:
 
  Hi,
  
  Is there anything else (other than starting this thread) I can do to make 
  committee consider `Function.prototype.extend` as an alternative to a 
  proposed class sugar ? 
 
 Could you show Function.prototype.extend again, 

Here is gist I wrote before:
https://gist.github.com/986487#file_implementation.js

 and say how it solves the super-construct and super-method-call problems?
 

I don't have any (in js implementable solution) for those problems, also I 
think sugar for `super` can be a separate thing. Gist contains example with 
super that behave exactly the same as in harmony proposal for classes. 

 
 /be
 
  
  Thanks
  --
  Irakli Gozalishvili
  Web: http://www.jeditoolkit.com/
  Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)
  
  
  On Tuesday, 2011-05-24 at 24:48 , Brendan Eich wrote:
  
   On May 23, 2011, at 11:25 AM, Bob Nystrom wrote:
   
One thing I'd like the proposal to support, which it doesn't currently, 
is initializers on instance property declarations. Then you could do: 

 class C { 
  public _list = [];
 
 
 }
 
 
 


With that, you'll correctly get a new _list on each instance of C when 
it's created. 
   But (we've argued, I forget where so repeating it here), this looks like 
   [] is evaluated once when the class declaration is evaluated. That is not 
   what you intend.
   
   Then at some point (in the last thread on this) I remembered parameter 
   default values, but they cover only missing parameters to the 
   constructor. This _list member could be private. But it has to be 
   initialized in a body that executes once per instantiation, which is not 
   the class body -- it's the constructor body.
   
   /be
   ___
   es-discuss mailing list
   es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
   https://mail.mozilla.org/listinfo/es-discuss
  
  ___
  es-discuss mailing list
  es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
  https://mail.mozilla.org/listinfo/es-discuss
 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is class syntax really necessary ?



On Monday, 2011-06-13 at 24:03 , Brendan Eich wrote:

 On Jun 12, 2011, at 2:52 PM, Irakli Gozalishvili wrote:
  
  Here is gist I wrote before:
  
  https://gist.github.com/986487#file_implementation.js
  
  
 
 
 What Function.create are you using there?
 
 Is there a missing return statement in function extend?
 
 

Yeap, sorry! It's there now.

   and say how it solves the super-construct and super-method-call problems?
   
   
   
  
  
  I don't have any (in js implementable solution) for those problems, also I 
  think sugar for `super` can be a separate thing. Gist contains example with 
  super that behave exactly the same as in harmony proposal for classes. 
 
 super.update();
 // Desugars to:
 // Object.getPrototypeOf(Object.getPrototypeOf(this)).update.call(this);
 
 
 That comment is wrong, or worse: it implies the wrong spec. This function 
 code does not want to depend on |this|, which could be rebound. You want to 
 depend on the [[Prototype]] of the enclosing object, or if contained in class 
 C syntax at the right level (not nested in arbitrary function expressions or 
 inner function definitions), C.prototype.[[Prototype]].
 
 Allen worked through this idea already:
 
 http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super
 


Could be, I have not spend time thinking on super as I considered as separate 
issue. I'll take a look at Allen's work thanks for the link.


Another idea I had was that super can be similar to private. Here is some 
example:

function super(self) {
var proto = Object.getPrototypeOf(Object.getProtypeOf(self));
Proxy.create({
...
get: function (receiver, name) {
// Shorter to constructor would be nice: super(this).new(options)
if (name === 'new') name = 'constructor'
// make sure to apply for getter / setters / and methods only.
// super(this).method(a, b)
return proto[name].bind(self);
}
...
}, proto);
}


super(this).new(options);
super(this).constructor(a, b);
super(this).method(a, b);

Obviously I don't suggest to use proxy, I just used to illustrate idea.

Also please not that constructor will be enough as users will be able to 
implement getter `new` returning `this.constructor` on a base class for shorter 
syntax.

 /be
 
 
   /be
   

Thanks
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France 
(http://goo.gl/maps/3CHu)


On Tuesday, 2011-05-24 at 24:48 , Brendan Eich wrote:

 On May 23, 2011, at 11:25 AM, Bob Nystrom wrote:
 
  One thing I'd like the proposal to support, which it doesn't 
  currently, is initializers on instance property declarations. Then 
  you could do: 
  
   class C { 
public _list = [];
   
   
   }
   
   
   
  
  
  With that, you'll correctly get a new _list on each instance of C 
  when it's created. 
 But (we've argued, I forget where so repeating it here), this looks 
 like [] is evaluated once when the class declaration is evaluated. 
 That is not what you intend.
 
 Then at some point (in the last thread on this) I remembered 
 parameter default values, but they cover only missing parameters to 
 the constructor. This _list member could be private. But it has to be 
 initialized in a body that executes once per instantiation, which is 
 not the class body -- it's the constructor body.
 
 /be
 ___
 es-discuss mailing list
 es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org (mailto:es-discuss@mozilla.org)
https://mail.mozilla.org/listinfo/es-discuss
   
  
 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is class syntax really necessary ?

On Monday, June 13, 2011, Brendan Eich bren...@mozilla.com wrote:
 On Jun 12, 2011, at 3:18 PM, Irakli Gozalishvili wrote:On Monday, 2011-06-13 
 at 24:03 , Brendan Eich wrote:

 On Jun 12, 2011, at 2:52 PM, Irakli Gozalishvili wrote:
 Here is gist I wrote 
 before:https://gist.github.com/986487#file_implementation.js
 What Function.create are you using there?
 Is there a missing return statement in function extend?
 Yeap, sorry! It's there now.
 Ok. But what is that Function.create your gist relies on?



It was proposed before I believe, it's like Object.create


Function.create = function (proto, func) {
var f = function() {
 return func.apply(this, arguments);
 }
 f.__proto__ = proto
 return f
}


 Another idea I had was that super can be similar to private. Here is some 
 example:
 Please note that the private(this)/private(other) syntax is intentional 
 straw, to be burned up and replaced with something better.
 I think you're trying to self-host too much. People can write classes the 
 hard way, with super too. They need sugar, not salt or pepper ;-).
 /be


I just don't know how wild I can go with idea :) Isn't it better to
leave off super for the moment and tackle that separately ?

-- 
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France http://goo.gl/maps/3CHu
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Is class syntax really necessary ?

Hi,

I think there lot's of proposals for ES.next that require syntax extensions, 
which is probably worth if new functionality added or shortens most commonly 
used constructs like functions (were no other option is available). In case of 
this proposal: 
http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues
 even though
I like it I'm not sure adding new syntax is worth it.

I'm not suggesting that sugar for class composition is not necessary, example 
from three.js used by proposal highlights necessity pretty very well, I'm just 
thinking of doing that without introducing new syntax, here is one option: 
https://gist.github.com/986487

This way syntax noise may be reduced in addition this can be shimmed into 
current JS by implementing `Function.prototype.extend`.

Also every single frameworks today does something similar in one form or 
another, IMO all is necessary is to have a standard that will let bikeshedding 
go away. I think there is also a good precedent of this with 
`Function.prototype.bind`.

Here are some related links:

http://documentcloud.github.com/backbone/
http://base2.googlecode.com/svn/version/1.0.2/doc/base2.html#/doc/!base2.Base
http://prototypejs.org/learn/class-inheritance
http://startdojo.com/2011/03/02/dojo-classes-inherited-and-constructors/
http://mootools.net/docs/core/Class/Class
http://ejohn.org/blog/simple-javascript-inheritance/


Kind regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is class syntax really necessary ?

On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov wrote:
On 23.05.2011 14:17, Irakli Gozalishvili wrote:
Hi,

I think there lot's of proposals for ES.next that require syntax
extensions, which is probably worth if new functionality added or shortens
most commonly used constructs like functions (were no other option is
available). In case of this proposal:
http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues
even though
I like it I'm not sure adding new syntax is worth it.

May I ask a counter question -- why do you think it's not good to add
syntactic sugar for classes? It's a kind of a strange thing. People sometimes
talk about unnecessarily of a sugar. But why I'm asking? Is it bad to use a
sugar? Or do you _really_ worry about an _implementation_ that e.g. a
language will be too heavy? After all, it's not even the issue of users,
it's the issue of implementers.

Dimitry thanks that's very good question.

1. More syntax means larger language surface, which adds complexity more things
to remember / learn. More things to consider in ES.next.next
2. I OOP in JS is already confusing for people coming from other languages,
this proposal will make it even more confusing.

That is, since it's just a sugar, the users _still_ are free to use
_desugared_ constructions (i.e. constructor + prototype + manual linkage of
parent prototype in case of inheritance). If they want to. If they instead want
to write with the sugar -- why we should worry about that adding of new syntax
is worth (taking into account that `class`, `extends`, etc. keywords are
already reserved since ES3 era).

So from what I can tell, right after the sugar for classes is standardized,
everyone will just start to use it and forget about desugared constructions.
And nobody even will think and bother about whether it's worth or not.

I don't doubt that, but adoption will take longer.
A good point of standardizing this wrapper (which is just a sugar) is that
all ad-hoc class-wrappers of libraries will be just eliminated and there will
be common classes sugar from the box. Since JS already supports classical
inheritance (though, without sugar), I don't how it's bad not to standardize
the sugar for it. It will be convenient who need to program a class-based
system. At the same time, if someone will still need a chaotic code reuse,
i.e. a prototype-based inheritance (reuse a code from that object from which
I want) -- they still be able to use things as `Object.create` (or |
operator, etc.)

From my perspective main problem today is verbosity, which can be fixed
without introducing new syntax. Also while I named some disadvantages, I can't
really see any advantages of dedicated syntax, there for I think it's better
to avoid adding more syntax changes.
I'm not suggesting that sugar for class composition is not necessary,
example from three.js used by proposal highlights necessity pretty very
well, I'm just thinking of doing that without introducing new syntax, here
is one option: https://gist.github.com/986487

This way syntax noise may be reduced in addition this can be shimmed into
current JS by implementing `Function.prototype.extend`.

Yeah, OTOH, it can be so too. Though, the _familiar_ sugar will be bring the
ability to involve programmers quicker.

Also every single frameworks today does something similar in one form or
another, IMO all is necessary is to have a standard that will let
bikeshedding go away.
Right.

Dmitry.

I think there is also a good precedent of this with
`Function.prototype.bind`.

Here are some related links:

http://documentcloud.github.com/backbone/
http://base2.googlecode.com/svn/version/1.0.2/doc/base2.html#/doc/!base2.Base
http://prototypejs.org/learn/class-inheritance
http://startdojo.com/2011/03/02/dojo-classes-inherited-and-constructors/
http://mootools.net/docs/core/Class/Class
http://ejohn.org/blog/simple-javascript-inheritance/

Kind regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France

___ es-discuss mailing list
es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is class syntax really necessary ?

On Monday, 2011-05-23 at 17:31 , Brendan Eich wrote:
On May 23, 2011, at 6:11 AM, Irakli Gozalishvili wrote:
On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov wrote:
On 23.05.2011 14:17, Irakli Gozalishvili wrote:
Hi,

I think there lot's of proposals for ES.next that require syntax
extensions, which is probably worth if new functionality added or
shortens most commonly used constructs like functions (were no other
option is available). In case of this proposal:
http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues
even though
I like it I'm not sure adding new syntax is worth it.

May I ask a counter question -- why do you think it's not good to add
syntactic sugar for classes? It's a kind of a strange thing. People
sometimes talk about unnecessarily of a sugar. But why I'm asking? Is it
bad to use a sugar? Or do you _really_ worry about an _implementation_
that e.g. a language will be too heavy? After all, it's not even the
issue of users, it's the issue of implementers.

Dimitry thanks that's very good question.

1. More syntax means larger language surface, which adds complexity more
things to remember / learn. More things to consider in ES.next.next

It's true, although not everyone learns it all up front. Especially where new
syntax is not yet supported in all browsers, and the student is not using a
compiler to translate new to old version.

I think the sharper version of your (1) is: class syntax is too much syntax
to solve the problems people have with prototypal inheritance: subclassed
prototype/constructor set-up and super calls.

I agree with that. Allen had been proposing super support that was separate.
You proposed Function.prototype.extend. Perhaps there's enough there to
relieve us of the large, tradition-haunted ediface of classes.

2. I OOP in JS is already confusing for people coming from other languages,
this proposal will make it even more confusing.

This is not as on target, in my opinion, because even if overwrought, classes
are trying to solve some confusion or accident hazards in JS today to-do with
prototypal inheritance. Namely,

(A) the boilerplate needed to set up a sub-prototype object with correct
constructor property, and

(B) the pain of doing correct super calls by hand.

Can we agree that these are problems to be solved, if not by classes then by
other APIs or special forms?
I do completely agree with that!

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is class syntax really necessary ?


On Monday, 2011-05-23 at 18:14 , Isaac Schlueter wrote: 
 On Mon, May 23, 2011 at 08:51, Brendan Eich bren...@mozilla.com wrote:
  Class syntax is like a lint brush for such features. If we add it, it will 
  accrete more semantics (with unambiguous syntax, I hope) over time. This is 
  just inevitable, in my view. It makes me want to resist classes and look at 
  smaller and more direct fixes for the two known prototypal hazards.
 
 Yes, please!
 
 I assume two known hazards is referring to your previous email:
 subclassed prototype/constructor set-up and super calls.
 
 I've been using this pattern in my OOP javascript programs lately:
 https://github.com/isaacs/inherits/blob/master/inherits.js
 
 It works really well, behaves as expected (easy for the author to say,
 ha, but it doesn't violate instanceof, doesn't call ctors more than
 once, doesn't clobber already-added prototype properties, etc.) And
 it's about 10 lines, easy to read and grok.
 
I personally prefer backbone style as IMO it has advantage of keeping complete 
setup in one declaration statement.

 What would make it even nicer, however, with minimal added syntax:
 
 1. Call super(a, b, c) instead of Child.super.call(this, a, b, c)
 2. Maybe Parent.extend(Child) or Child.inherit(Parent) instead of
 inherits(Child, Parent)
 3. Right now, calling parent versions of overridden methods is a
 painful: this.constructor.super.prototype.someMethod.call(this).
 It'd be nice to use something like super.someMethod().
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss
 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is class syntax really necessary ?