class prototype object vs class instance properties

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

class prototype object vs class instance properties

Garrett Smith
What is the difference between a class's prototype object and it's
instance properties?

class A {
  var x : uint = 10; // instance property.
  prototype var x : uint = 20; // another instance property in the
prototype chain.
}

class B extends A { }

My understanding is that the result would be:

new B().x; // result is 20.

What would be the benefit of a class having a prototype over 9instance
properties/methods?
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: class prototype object vs class instance properties

liorean
On 17/08/07, Garrett Smith <[hidden email]> wrote:
> What is the difference between a class's prototype object and it's
> instance properties?

Prototype properties are fallbacks if the property does not exist on
the instance.

> class A {
>   var x : uint = 10; // instance property.
>   prototype var x : uint = 20; // another instance property in the
> prototype chain.
> }
>
> class B extends A { }
>
> My understanding is that the result would be:
>
> new B().x; // result is 20.
>
> What would be the benefit of a class having a prototype over 9instance
> properties/methods?

Prototype properties can be shadowed by instance properties without
being changed, prototype properties are fallbacks if the instance
property does not exist, and prototype properties are not part of the
actual instance, so can be used as memory footprint reduction if one
has lots of instances that don't need separate values for that
instance property.
--
David "liorean" Andersson
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: class prototype object vs class instance properties

Garrett Smith
In reply to this post by Garrett Smith

liorean wrote:
>> What would be the benefit of a class having a prototype over 9instance
>> properties/methods?
>
> Prototype properties can be shadowed by instance properties without
> being changed, prototype properties are fallbacks if the instance
> property does not exist, and prototype properties are not part of the
> actual instance, so can be used as memory footprint reduction if one
> has lots of instances that don't need separate values for that
> instance property.
> --

That's pretty much how es3 works, then.

Instance methods in the prototype, unique properties will be defined on the instance.



Reply | Threaded
Open this post in threaded view
|

Re: class prototype object vs class instance properties

Brendan Eich-2
On Aug 18, 2007, at 10:13 AM, Garrett wrote:

> liorean wrote:
>>> What would be the benefit of a class having a prototype over  
>>> 9instance
>>> properties/methods?
>>
>> Prototype properties can be shadowed by instance properties without
>> being changed, prototype properties are fallbacks if the instance
>> property does not exist, and prototype properties are not part of the
>> actual instance, so can be used as memory footprint reduction if one
>> has lots of instances that don't need separate values for that
>> instance property.
>> --
>
> That's pretty much how es3 works, then.

In fact the reference implementation at http://ecmascript.org/ uses  
ES4 class definitions to create the built-in classes from ES1-3  
(Object, Date, etc.). A few fine points:

In |dynamic class Object {...}|, the |dynamic| keyword is required if  
you want the class's instances, not just its prototype, to allow ad-
hoc properties to be set on them. So indeed, |Object| is a dynamic  
class in the reference implementation.

In |class C { var x; }; c = new C; c.x = 42| and |dynamic class D  
{ prototype var x; }; d = new D; d.x = 42| both c and d wind up with  
an x property having value 42. But c.x is a "fixture" -- it can't be  
deleted, and if it has a type annotation, that type constraint can't  
be altered. Whereas d.x is just an ad-hoc property on a dynamic  
class's instance, which happens to shadow prototype var x, but has no  
type relation to that prototype property.

A function definition inside a class C's body |class C { function m
():void {...} ...}| creates a method fixture named m, which has a  
function structural type |function (this:C):void| and which can't be  
deleted or overwritten.

So classes, fields (var in class), and methods (function in class)  
respectively provide objects with private members where the instances  
cannot be extended, properties that can't be deleted or have their  
type annotations violated, and receiver-based method dispatch (again  
with existence and type guarantees). These can be emulated in ES3 in  
several ways, at some cost in clarity and runtime efficiency.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: class prototype object vs class instance properties

Garrett Smith
On 8/18/07, Brendan Eich <[hidden email]> wrote:

> On Aug 18, 2007, at 10:13 AM, Garrett wrote:
>
> > liorean wrote:
> >>> What would be the benefit of a class having a prototype over
> >>> 9instance
> >>> properties/methods?
> >>
> >> Prototype properties can be shadowed by instance properties without
> >> being changed, prototype properties are fallbacks if the instance
> >> property does not exist, and prototype properties are not part of the
> >> actual instance, so can be used as memory footprint reduction if one
> >> has lots of instances that don't need separate values for that
> >> instance property.
> >> --
> >
> > That's pretty much how es3 works, then.
>
> In fact the reference implementation at http://ecmascript.org/ uses
> ES4 class definitions to create the built-in classes from ES1-3
> (Object, Date, etc.). A few fine points:
>
> In |dynamic class Object {...}|, the |dynamic| keyword is required if
> you want the class's instances, not just its prototype, to allow ad-
> hoc properties to be set on them. So indeed, |Object| is a dynamic
> class in the reference implementation.
>
I understand that.

> In |class C { var x; }; c = new C; c.x = 42| and |dynamic class D
> { prototype var x; }; d = new D; d.x = 42| both c and d wind up with
> an x property having value 42. But c.x is a "fixture" -- it can't be
> deleted, and if it has a type annotation, that type constraint can't
> be altered. Whereas d.x is just an ad-hoc property on a dynamic
> class's instance, which happens to shadow prototype var x, but has no
> type relation to that prototype property.
>
> A function definition inside a class C's body |class C { function m
> ():void {...} ...}| creates a method fixture named m, which has a
> function structural type |function (this:C):void| and which can't be
> deleted or overwritten.
>
> So classes, fields (var in class), and methods (function in class)
> respectively provide objects with private members where the instances
> cannot be extended, properties that can't be deleted or have their
> type annotations violated, and receiver-based method dispatch (again
> with existence and type guarantees). These can be emulated in ES3 in
> several ways, at some cost in clarity and runtime efficiency.
>
I understand that.

But these methods are also bound, right?

In current coding conventions, many programmers (including myself)
like to have the constructor's prototype assigment in one place with
an object literal.


function A {
// instance props.
this.init();
}
A.prototype = {
  Events : {
// Enum would be nice.
    "open" : "open"
  }

  ,init : function init() {
  }
};

This "objec tliteral"styleis not congruent to the prototype being a
special instance (as in ES3 and 4 built-ins, with Date.prototype
having value NaN, et c) . The above code style is clear and easy to
read. You have the constructor, then the prototype.

It would be nice to have a prototype block, like:

class A {

  init  : void =  function init()
  prototype {

  }

  function A () {

  }


}

I am not sure if the with(prototype) { ... } would be suitable for
that approach. I think with statements should not be encouraged.

I'm also confused on the syntax for function return type.

ES4:
>> class P { f:Void=  function  f()  {print('fff');}}
[function Function]
>> new P().f()
[stack] []
**ERROR** EvalError: uncaught exception: ReferenceError: unresolved
object reference {multiname: [ns public '']::f } (near
builtins/Error.es:83.47-83.47)


> /be
>


--
http://dhtmlkitchen.com/
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: class prototype object vs class instance properties

Brendan Eich-2
On Aug 18, 2007, at 1:51 PM, Garrett Smith wrote:

> But these methods are also bound, right?

Yes, good point -- I left out that further detail. |this| always  
refers in a method to the instance from which the method was called  
or extracted.

> In current coding conventions, many programmers (including myself)
> like to have the constructor's prototype assigment in one place with
> an object literal.

Yeah, I like and use that convention too.

> This "object literal"styleis not congruent to the prototype being a
> special instance (as in ES3 and 4 built-ins, with Date.prototype
> having value NaN, et c) . The above code style is clear and easy to
> read. You have the constructor, then the prototype.
>
> It would be nice to have a prototype block, like:
>
> class A {
>
>   init  : void =  function init()
>   prototype {
>
>   }

This is something proposed ages ago by Waldemar Horwat (then at  
Netscape) for ES4 -- any time you have

   prototype function m1(...) {...}
   prototype function m2(...) {...}
   prototype function m3(...) {...}

in some ES4 drafts waldemar wrote, you could instead say

   prototype {
     function m1(...) {...}
     function m2(...) {...}
     function m3(...) {...}
   }

Waldemar's proposal allowed this for any kind of "attribute"  
qualifying a definition, including a namespace IIRC.

I'll bring this up at the next meeting, since you are quite right  
that the current builtins in the reference implementation are chatty.

> I am not sure if the with(prototype) { ... } would be suitable for
> that approach. I think with statements should not be encouraged.

Right, |with| is not suitable here -- it won't change the scope in  
which functions and vars are bound in a class any more than it would  
elsewhere (as it does not in ES1-3). Also, it is being deprecated  
(there's a reformed with that can be used if you're retrofitting, or  
if you like with and want to use it without scope ambiguity).

> I'm also confused on the syntax for function return type.
>
> ES4:
>>> class P { f:Void=  function  f()  {print('fff');}}
> [function Function]
>>> new P().f()
> [stack] []
> **ERROR** EvalError: uncaught exception: ReferenceError: unresolved
> object reference {multiname: [ns public '']::f } (near
> builtins/Error.es:83.47-83.47)

You didn't define a method f in class P. Look:

 >> class P { f:Void=  function  f()  {print('fff');}}
[function Function]
 >> Void
[function Function]
 >> Void()
fff

the f: is a section label, like private: or public:. The Void name is  
unbound and on the left-hand side of assignment (=) in class P's  
initialization code, so that's an assignment expression-statement  
executed once when the class is processed. Per the usual rules, the  
assignment binds a global property named 'Void'.

I don't know where you saw an example that looked anything like that.  
In the mail I wrote, to which you are replying here, I showed a void  
method:

class C { function m():void {...} ...}

The return type annotation, which is optional, goes after the  
function formal parameter list, and starts with : as for all type  
annotations. The use of |void| here shows a special case: 'void' is  
not a type name, it means instead that the function cannot contain  
'return expr;' statements, only 'return;' statements and falling-off-
the-end-without-return. There is no 'Void' type in ES4. The type of  
the undefined value is a type named undefined (available only in type  
expression contexts), same as for null/null.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: class prototype object vs class instance properties

Jeff Dyer
> > This "object literal"styleis not congruent to the prototype being a
> > special instance (as in ES3 and 4 built-ins, with Date.prototype
> > having value NaN, et c) . The above code style is clear and easy to
> > read. You have the constructor, then the prototype.
> >
> > It would be nice to have a prototype block, like:
> >
> > class A {
> >
> >   init  : void =  function init()
> >   prototype {
> >
> >   }
>
> This is something proposed ages ago by Waldemar Horwat (then at
> Netscape) for ES4 -- any time you have
>
>    prototype function m1(...) {...}
>    prototype function m2(...) {...}
>    prototype function m3(...) {...}
>
> in some ES4 drafts waldemar wrote, you could instead say
>
>    prototype {
>      function m1(...) {...}
>      function m2(...) {...}
>      function m3(...) {...}
>    }
>
> Waldemar's proposal allowed this for any kind of "attribute"
> qualifying a definition, including a namespace IIRC.
>

That's right.

> I'll bring this up at the next meeting, since you are quite right
> that the current builtins in the reference implementation are chatty.
>

ActionScript will have something like this soon in its program
configuration feature. It is described here:

http://wiki.ecmascript.org/doku.php?id=proposals:program_configuration

The meaning is slightly different, but maybe not incompatible. In the
above proposal, a configuration expression turns on or off a block of
code, including any embedded definitions. If non-configuration
attributes where used on a block they could be applied to relevant
definitions. Perhaps it should be an error to put definitions in a block
whose attributes don't apply.

Jd
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Program configuration [Was: class prototype object vs class instance properties]

P T Withington
On 2007-08-20, at 13:21 EDT, Jeff Dyer wrote:

> ActionScript will have something like this soon in its program
> configuration feature. It is described here:
>
> http://wiki.ecmascript.org/doku.php?id=proposals:program_configuration

Interesting that you rejected the use of Javascript control flow for  
configuration.  That is what we use in LZX.  Effectively we just  
require that if statements involving configuration variables be  
optimized at compile time.  (We don't currently permit expressions on  
configuration variables and we don't have a language for defining  
configuration variables.)  The benefit we saw is that the programmer  
does not need to learn anything new to understand configuration.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Program configuration [Was: class prototype object vs class instance properties]

Jeff Dyer
We considered using ordinary control flow constructs for program
configuration but in the end decided to use a purely attribute based
mechanism for that purpose. Given that we were using configuration
attributes on definitions and members of object and array literals,
extending their use to blocks seemed consistent and natural. Also, we
thought giving a compile time meaning to if-else might make programs
harder to read. But if you do like Java and limit the feature to
compiling out statements, then using if-else syntax might be just fine.

Jd

> -----Original Message-----
> From: P T Withington [mailto:[hidden email]]
> Sent: Monday, August 20, 2007 11:17 AM
> To: Jeff Dyer
> Cc: Brendan Eich; Garrett Smith; [hidden email]
> Subject: Program configuration [Was: class prototype object vs class
> instance properties]
>
> On 2007-08-20, at 13:21 EDT, Jeff Dyer wrote:
>
> > ActionScript will have something like this soon in its program
> > configuration feature. It is described here:
> >
> >
http://wiki.ecmascript.org/doku.php?id=proposals:program_configuration
>
> Interesting that you rejected the use of Javascript control flow for
> configuration.  That is what we use in LZX.  Effectively we just
> require that if statements involving configuration variables be
> optimized at compile time.  (We don't currently permit expressions on
> configuration variables and we don't have a language for defining
> configuration variables.)  The benefit we saw is that the programmer
> does not need to learn anything new to understand configuration.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss