AOP Compatibility

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

AOP Compatibility

Kris Zyp-4
It seems that one of more significant remaining compatibility issues with
ES3 is the inability to set AOP advice on all methods. Many frameworks rely
on the ability to replace functions in order to add advice/listen to
methods. For example, this is how dojo.connect works, although this is
certainly not the only function that uses this technique. This might not
fail compatibility tests in the sense that pure ES3 code (no classes) will
still operate properly in an ES4 environment. However, when ES4 classes are
mixed with existing ES3 framework code, and when instances of classes are
passed to AOP functions like dojo.connect, the AOP function will fail to be
able to replace the function to add advice.
Is there any way this compatibility can be mitigated? I am assuming there is
no conceivable way to actually replace methods ad-hoc with arbitrary
functions and retain sane typing and class expectations. However, would a
more controlled AOP API be a reasonable approach to adding AOP advice to
methods? At least, frameworks could be altered to handle the difference
between ES4 class and dynamic Object, and use the AOP API when appropriate,
and therefore general AOP providing functions could be altered to work in
both ES3 and ES4 environments. I don't know if there another way to mitigate
this incompatibility...
Thanks,
Kris

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

Re: AOP Compatibility

Brendan Eich-2
On Feb 20, 2008, at 10:17 AM, Kris Zyp wrote:

> Is there any way this compatibility can be mitigated? I am assuming  
> there is
> no conceivable way to actually replace methods ad-hoc with arbitrary
> functions and retain sane typing and class expectations.

I'm not sure why you assume this. Latest RI downloaded from http://
ecmascript.org/ :

$ ./es4
ECMAScript Edition 4 RI v0.0M2 (Fri Feb 15 13:37:13 2008)
 >> save_getTime = Date.prototype.getTime
[function Function]
 >> Date.prototype.getTime = function advice() { intrinsic::print
("before getTime"); let t = save_getTime(); intrinsic::print("after  
getTime"); return t; }
[function Function]
 >> d = new Date
Wed, 20 Feb 2008 22:15:18 GMT+0000
 >> d.getTime()
before getTime
after getTime
1203545718235
 >> save_Date_parse = Date.parse
[function Function]
 >> Date.parse = function more_advice() { intrinsic::print("yay!");  
return save_Date_parse.apply(this, arguments); }
[function Function]
 >> Date.parse(Date())
yay!
1203545824000

The builtins are backward-compatible as to class object and prototype  
mutation, including AOP hacks. The only proposed change for ES4,  
dependent on opt-in versioning, is making the constructor (now type)  
bindings immutable. Replacing Date in the global object is much less  
commonly done (but not unknown: Joel Spolsky's fogbugz does this, we  
learned via a crucial experiment in Firefox 3 beta 2).

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

Re: AOP Compatibility

P T Withington
On 2008-02-20, at 17:20 EST, Brendan Eich wrote:

> On Feb 20, 2008, at 10:17 AM, Kris Zyp wrote:
>
>> Is there any way this compatibility can be mitigated? I am assuming
>> there is
>> no conceivable way to actually replace methods ad-hoc with arbitrary
>> functions and retain sane typing and class expectations.
>
> I'm not sure why you assume this. Latest RI downloaded from http://
> ecmascript.org/ :

I thought the question was about annotating class fixtures?

But your reply made me think:  So, built-ins cannot be classes,  
because they require backward compatibility?  Or maybe I missed that  
there are sealed/class versions of built-ins (in some other  
namespace?) with just a thin veneer of prototype around them for back  
compatibility?

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

Re: AOP Compatibility

Brendan Eich-2
On Feb 20, 2008, at 3:35 PM, P T Withington wrote:

> On 2008-02-20, at 17:20 EST, Brendan Eich wrote:
>
>> On Feb 20, 2008, at 10:17 AM, Kris Zyp wrote:
>>
>>> Is there any way this compatibility can be mitigated? I am assuming
>>> there is
>>> no conceivable way to actually replace methods ad-hoc with arbitrary
>>> functions and retain sane typing and class expectations.
>>
>> I'm not sure why you assume this. Latest RI downloaded from http://
>> ecmascript.org/ :
>
> I thought the question was about annotating class fixtures?

How could it be, since those do not exist in ES1-3?

Fixtures are in the intrinsic namespace, so yes, 'use namespace  
intrinsic' will break AOP. The two do not mix, they're fundamentally  
opposed to each other.

> But your reply made me think:  So, built-ins cannot be classes,
> because they require backward compatibility?  Or maybe I missed that
> there are sealed/class versions of built-ins (in some other
> namespace?) with just a thin veneer of prototype around them for back
> compatibility?

You can read the code ;-). Built-in constructors such as Date are  
dynamic classes. Here's part of builtins/Date.es:

package
{
     import ECMAScript4_Internal.*;
     import JSON.*;

     use default namespace public;
     use namespace helper;
     use namespace informative;
     use namespace intrinsic;
     use namespace __ES4__;
     use strict;

     const NOARG = {};

     dynamic class Date
     {

         static const length = 7;

         /* E262-3 15.9.2: The Date Constructor Called as a Function */
         meta static function invoke(...args)   // args are ignored.
             (new Date()).public::toString();

         /* E262-3 15.9.3: The Date Constructor. */
         function Date(year=NOARG, month=NOARG, date=NOARG,  
hours=NOARG, minutes=NOARG, seconds=NOARG
, ms=NOARG) {
             informative::setupNanoAge();

             switch (NOARG) {
etc.

Yes, typeof Date == "function" for backward compatibility. typeof is  
broken and we can't fix it, but the |is| operator and the meta  
objects proposal provides better alternative tools.

/be

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

Re: AOP Compatibility

Kris Zyp-4
In reply to this post by P T Withington
> I thought the question was about annotating class fixtures?
Yes, that was my intent, sorry I wasn't clearer. I knew that built-ins were
designed to be backwards compatible. I don't have the RI in front of me at
the moment, but I assume you can't do replace a method on a user class with
another ad-hoc function.
Kris

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

Re: AOP Compatibility

Brendan Eich-2
On Feb 20, 2008, at 3:42 PM, Kris Zyp wrote:

>> I thought the question was about annotating class fixtures?
> Yes, that was my intent, sorry I wasn't clearer.

No problem, sorry for assuming you meant ES3-compatible code.

> I knew that built-ins were
> designed to be backwards compatible. I don't have the RI in front  
> of me at
> the moment, but I assume you can't do replace a method on a user  
> class with
> another ad-hoc function.

Absolutely not with fixtures, but you can put the prototype qualifier  
in front of function definitions in classes to create prototype  
methods just like the ones in ES3's builtins, and you can make your  
class dynamic (although IIRC, all class objects where static  
properties live are mutable; class *instances* are fixed unless the  
class is dynamic -- Graydon or Jeff should correct me if I'm wrong).  
If you want to allow AOP, which is pretty much an integrity  
violation, you have to lower your shields.

Formalizing AOP further, somehow supporting it without losing the  
integrity guarantees needed for early binding and strict mode, is out  
of scope for ES4. But you can do a lot with ES4's function types. If  
the guarantee is not about function object identity (e.g. for  
analysis of effects, or for inlining), rather only about function  
type, it's fine to use a non-fixture that has a type annotation. |
prototype function AOPmeHarder(this:Widget, a:int, b:string):boolean|  
can be overwritten by advice, but the advice can't subvert type  
judgments.

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

Re: AOP Compatibility

Kris Zyp-4
> Absolutely not with fixtures, but you can put the prototype qualifier  in
> front of function definitions in classes to create prototype  methods just
> like the ones in ES3's builtins, and you can make your  class dynamic
> (although IIRC, all class objects where static  properties live are
> mutable; class *instances* are fixed unless the  class is dynamic --  
> Graydon or Jeff should correct me if I'm wrong).

Of course a library function (like dojo.connect) that is called to advise a
method on an object doesn't have control of how the object was created. If
it is an instance of user class (and not dynamic), this function will this
fail. This functionality is pretty core and heavily used by Dojo and I
believe is used by other libraries as well. Of course existing code will
continue to work, but it will be disappointing to find this function fail
for new objects created with ES4 functionality. I don't know an easier
solution, other than real AOP support.
Kris

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

Re: AOP Compatibility

Brendan Eich-2
On Feb 20, 2008, at 4:21 PM, Kris Zyp wrote:

> Of course a library function (like dojo.connect) that is called to  
> advise a
> method on an object doesn't have control of how the object was  
> created. If
> it is an instance of user class (and not dynamic), this function  
> will this
> fail. This functionality is pretty core and heavily used by Dojo and I
> believe is used by other libraries as well. Of course existing code  
> will
> continue to work, but it will be disappointing to find this  
> function fail
> for new objects created with ES4 functionality. I don't know an easier
> solution, other than real AOP support.

I think you're assuming a problem of the "Doctor, it hurts when I do  
this" variety. Non-dynamic classes are not for everything. Where you  
need them as integrity devices, you do not want Dojo's AOP, no way no  
how. Most objects will continue to be plain old Object instances. But  
note that even in today's world, DOM types are nominal -- there are  
non-dynamic classes under the hood. Not all DOM or similar browser  
embedding objects can be mutated freely. Dojo survives these hazards,  
as far as I know.

/be

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

Re: AOP Compatibility

Neil Mix
Another thought: does ES4 provide enough introspection capability to  
write proxy objects that wrap an immutable class instance?  It seems  
as though it should be possible to create a single class (with *  
getter/setter functions) that can wrap any object, emulate its  
interface and provide AOP advice capabilities.  If this is indeed  
possible, would that prove useful for the situations Kris is  
concerned about?

On Feb 20, 2008, at 7:32 PM, Brendan Eich wrote:

> On Feb 20, 2008, at 4:21 PM, Kris Zyp wrote:
>> Of course a library function (like dojo.connect) that is called to
>> advise a
>> method on an object doesn't have control of how the object was
>> created. If
>> it is an instance of user class (and not dynamic), this function
>> will this
>> fail. This functionality is pretty core and heavily used by Dojo  
>> and I
>> believe is used by other libraries as well. Of course existing code
>> will
>> continue to work, but it will be disappointing to find this
>> function fail
>> for new objects created with ES4 functionality. I don't know an  
>> easier
>> solution, other than real AOP support.
>
> I think you're assuming a problem of the "Doctor, it hurts when I do
> this" variety. Non-dynamic classes are not for everything. Where you
> need them as integrity devices, you do not want Dojo's AOP, no way no
> how. Most objects will continue to be plain old Object instances. But
> note that even in today's world, DOM types are nominal -- there are
> non-dynamic classes under the hood. Not all DOM or similar browser
> embedding objects can be mutated freely. Dojo survives these hazards,
> as far as I know.
>
> /be
>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss

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

Re: AOP Compatibility

Garrett Smith
On Thu, Feb 21, 2008 at 7:47 AM, Neil Mix <[hidden email]> wrote:
> Another thought: does ES4 provide enough introspection capability to
>  write proxy objects that wrap an immutable class instance?  It seems
>  as though it should be possible to create a single class (with *
>  getter/setter functions) that can wrap any object, emulate its
>  interface and provide AOP advice capabilities.  If this is indeed
>  possible, would that prove useful for the situations Kris is
>  concerned about?

This thread is useless without code.

>
>
>
>  On Feb 20, 2008, at 7:32 PM, Brendan Eich wrote:
>
>  > On Feb 20, 2008, at 4:21 PM, Kris Zyp wrote:
>  >> Of course a library function (like dojo.connect) that is called to
>  >> advise a
>  >> method on an object doesn't have control of how the object was
>  >> created. If
>  >> it is an instance of user class (and not dynamic), this function
>  >> will this
>  >> fail. This functionality is pretty core and heavily used by Dojo
>  >> and I
>  >> believe is used by other libraries as well. Of course existing code
>  >> will
>  >> continue to work, but it will be disappointing to find this
>  >> function fail
>  >> for new objects created with ES4 functionality. I don't know an
>  >> easier
>  >> solution, other than real AOP support.
>  >
>  > I think you're assuming a problem of the "Doctor, it hurts when I do
>  > this" variety. Non-dynamic classes are not for everything. Where you
>  > need them as integrity devices, you do not want Dojo's AOP, no way no
>  > how. Most objects will continue to be plain old Object instances. But
>  > note that even in today's world, DOM types are nominal -- there are
>  > non-dynamic classes under the hood. Not all DOM or similar browser
>  > embedding objects can be mutated freely. Dojo survives these hazards,
>  > as far as I know.
>  >
>  > /be
>  >
>  > _______________________________________________
>  > Es4-discuss mailing list
>  > [hidden email]
>  > https://mail.mozilla.org/listinfo/es4-discuss
>
>  _______________________________________________
>  Es4-discuss mailing list
>  [hidden email]
>  https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: AOP Compatibility

Kris Zyp-4
In reply to this post by Neil Mix
> Another thought: does ES4 provide enough introspection capability to
> write proxy objects that wrap an immutable class instance?  It seems  as
> though it should be possible to create a single class (with *
> getter/setter functions) that can wrap any object, emulate its  interface
> and provide AOP advice capabilities.  If this is indeed  possible, would
> that prove useful for the situations Kris is  concerned about?

That is good question. It wouldn't truly solve the problem. When you call
dojo.connect to request that your method add advice/a listener, the caller
doesn't expect that it is going to be told that it should no longer use the
original class instance, but rather a proxy. But this could still mitigate
the problem. At least users could proxy class instances such that they are
advisable in the same way their ol' dynamic ES3 objects were.
I don't know if their is sufficient introspection capability though, I would
love to know if that is possible.
Thanks,
Kris

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

Re: AOP Compatibility

Brendan Eich-2
In reply to this post by Neil Mix
On Feb 21, 2008, at 7:47 AM, Neil Mix wrote:

> Another thought: does ES4 provide enough introspection capability to
> write proxy objects that wrap an immutable class instance?  It seems
> as though it should be possible to create a single class (with *
> getter/setter functions) that can wrap any object, emulate its
> interface and provide AOP advice capabilities.  If this is indeed
> possible, would that prove useful for the situations Kris is
> concerned about?

Sure, at the price of loss of identity. That may break AOP use-cases.

/be

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

Class method addition and replacement (was Re: AOP Compatibility)

Kris Zyp-4
In reply to this post by Brendan Eich-2
>> the moment, but I assume you can't do replace a method on a user  class
>> with
>> another ad-hoc function.
>
> Absolutely not with fixtures,

I was thinking about this, is there any reason why you can't replace a
class's method with another method or install a method on an instance object
that overrides the class's method, assuming that the method signature
remains the same, the body has correct typing use of |this|, and the class
is non-final? This seems to have the same integrity as method overriding in
subclasses. Being able to do this (and possibly dynamically adding methods
to classes) would bring the level of dynamicism that Mark had suggested with
his ES4 sugar proposal (being able to create classes on the fly), but
without destroying the fundamental ES4 typing/fixture system. This could be
used to solve AOP as well, and bring a distinctly higher level of dynamicism
which could be leveraged to progressively build, serialize (with proper
introspection), and deserialize classes.

Essentially, are there mutations to classes and object instances that do not
effect integrity and do not violate explicit contracts against mutation
(final annotation=no method mutations) that we could allow?

Thanks,
Kris

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

Re: Class method addition and replacement (was Re: AOP Compatibility)

Peter Hall-4
Replacing a method effectively changes the type, even if the signature
is the same. If some code creates an instance of a class using "new"
it should be able to rely on it being that type, and make assumptions
about how that object will behave. (This is not a matter of breaking
polymorphism because the same code created the instance such that
there is no possibility of a sub-type instance being present).
Allowing methods to be replaced means that other parts of a program
could alter the behaviour of an object in a way that could contradict
those assumptions.

Additionally, allowing methods to be replaced could reduce the
effectiveness of early binding optimisations. (Jeff Dyer can correct
me if I'm inaccurate here..) In AS3, class methods are referenced via
the class's traits table. They may be accessed by name, but calls are
bound to addresses where possible, at compile time via the traits.
Allowing methods to be overridden would mean a choice of copying the
traits for each instance, which would increase memory usage
dramatically; or else checking for overrides at runtime for every
method call, which would hurt performance.


Peter


On Thu, Apr 3, 2008 at 4:23 PM, Kris Zyp <[hidden email]> wrote:

> >> the moment, but I assume you can't do replace a method on a user  class
>  >> with
>  >> another ad-hoc function.
>  >
>  > Absolutely not with fixtures,
>
>  I was thinking about this, is there any reason why you can't replace a
>  class's method with another method or install a method on an instance object
>  that overrides the class's method, assuming that the method signature
>  remains the same, the body has correct typing use of |this|, and the class
>  is non-final? This seems to have the same integrity as method overriding in
>  subclasses. Being able to do this (and possibly dynamically adding methods
>  to classes) would bring the level of dynamicism that Mark had suggested with
>  his ES4 sugar proposal (being able to create classes on the fly), but
>  without destroying the fundamental ES4 typing/fixture system. This could be
>  used to solve AOP as well, and bring a distinctly higher level of dynamicism
>  which could be leveraged to progressively build, serialize (with proper
>  introspection), and deserialize classes.
>
>  Essentially, are there mutations to classes and object instances that do not
>  effect integrity and do not violate explicit contracts against mutation
>  (final annotation=no method mutations) that we could allow?
>
>  Thanks,
>  Kris
>
>  _______________________________________________
>  Es4-discuss mailing list
>  [hidden email]
>  https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Class method addition and replacement (was Re: AOP Compatibility)

Lars Hansen-3
Just to echo Peter here, changing a method violates integrity in
the worst way.  If I say "new Cls" I *know* that the object I get
is of type Cls, and if I know the implementation of that class I
know what a call to a method of the type will do.  There is no
way subclassing can get in the way of that knowledge, but allowing
methods to be arbitrarily assigned to (even with constraints on
type compatibility) completely destroys that invariant.  But that
invariant is one of the main benefits of having classes in the
first place.

(There are efficiency concerns too, but I think the violation of
integrity is the important part.)

--lars

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Peter Hall
> Sent: 3. april 2008 09:58
> To: Kris Zyp
> Cc: es4-discuss Discuss
> Subject: Re: Class method addition and replacement (was Re:
> AOP Compatibility)
>
> Replacing a method effectively changes the type, even if the
> signature is the same. If some code creates an instance of a
> class using "new"
> it should be able to rely on it being that type, and make
> assumptions about how that object will behave. (This is not a
> matter of breaking polymorphism because the same code created
> the instance such that there is no possibility of a sub-type
> instance being present).
> Allowing methods to be replaced means that other parts of a
> program could alter the behaviour of an object in a way that
> could contradict those assumptions.
>
> Additionally, allowing methods to be replaced could reduce
> the effectiveness of early binding optimisations. (Jeff Dyer
> can correct me if I'm inaccurate here..) In AS3, class
> methods are referenced via the class's traits table. They may
> be accessed by name, but calls are bound to addresses where
> possible, at compile time via the traits.
> Allowing methods to be overridden would mean a choice of
> copying the traits for each instance, which would increase
> memory usage dramatically; or else checking for overrides at
> runtime for every method call, which would hurt performance.
>
>
> Peter
>
>
> On Thu, Apr 3, 2008 at 4:23 PM, Kris Zyp <[hidden email]> wrote:
> > >> the moment, but I assume you can't do replace a method
> on a user  
> > >> class
> >  >> with
> >  >> another ad-hoc function.
> >  >
> >  > Absolutely not with fixtures,
> >
> >  I was thinking about this, is there any reason why you
> can't replace
> > a  class's method with another method or install a method on an
> > instance object  that overrides the class's method,
> assuming that the
> > method signature  remains the same, the body has correct
> typing use of
> > |this|, and the class  is non-final? This seems to have the same
> > integrity as method overriding in  subclasses. Being able
> to do this
> > (and possibly dynamically adding methods  to classes) would
> bring the
> > level of dynamicism that Mark had suggested with  his ES4 sugar
> > proposal (being able to create classes on the fly), but  without
> > destroying the fundamental ES4 typing/fixture system. This
> could be  
> > used to solve AOP as well, and bring a distinctly higher level of
> > dynamicism  which could be leveraged to progressively
> build, serialize (with proper  introspection), and
> deserialize classes.
> >
> >  Essentially, are there mutations to classes and object
> instances that
> > do not  effect integrity and do not violate explicit
> contracts against
> > mutation  (final annotation=no method mutations) that we
> could allow?
> >
> >  Thanks,
> >  Kris
> >
> >  _______________________________________________
> >  Es4-discuss mailing list
> >  [hidden email]
> >  https://mail.mozilla.org/listinfo/es4-discuss
> >
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Class method addition and replacement (was Re: AOP Compatibility)

Brendan Eich-2
In reply to this post by Kris Zyp-4
On Apr 3, 2008, at 8:23 AM, Kris Zyp wrote:

>>> the moment, but I assume you can't do replace a method on a user  
>>> class
>>> with
>>> another ad-hoc function.
>>
>> Absolutely not with fixtures,
>
> I was thinking about this, is there any reason why you can't replace a
> class's method with another method or install a method on an  
> instance object
> that overrides the class's method, assuming that the method signature
> remains the same, the body has correct typing use of |this|, and  
> the class
> is non-final? This seems to have the same integrity as method  
> overriding in
> subclasses. Being able to do this (and possibly dynamically adding  
> methods
> to classes) would bring the level of dynamicism that Mark had  
> suggested with
> his ES4 sugar proposal (being able to create classes on the fly)

Mark's sketch did not allow method replacement, however.

AOP is not the root password to mutation barriers added to enforce  
integrity properties. It is not even formally sound, last I looked.  
And its main use-case is logging or other such post-hoc, cross-
cutting instrumentation. If the universe of objects already contains  
some (like certain built-in objects including DOM nodes in most  
browsers) whose methods cannot be replaced, which must therefore be  
wrapped for AOP-style hacking, then why wouldn't we want classes to  
behave as proposed in ES4?

Wrappers will be required; they already are for security in browsers  
I've studied (or they are coming soon, at any rate). Any code not  
insisting on a nominal type relation, i.e., using * (implicitly as in  
untyped code today, or explicitly), or a like test, or a structural  
subtype test, could let wrappers through. Just as DOM wrappers can  
satisfy hand-coded "shape tests" in today's untyped libraries that  
use AOP.

/be

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

Re: Class method addition and replacement (was Re: AOP Compatibility)

Kris Zyp-4
In reply to this post by Lars Hansen-3
> Just to echo Peter here, changing a method violates integrity in
> the worst way.  If I say "new Cls" I *know* that the object I get
> is of type Cls, and if I know the implementation of that class I
> know what a call to a method of the type will do.  There is no
> way subclassing can get in the way of that knowledge, but allowing
> methods to be arbitrarily assigned to (even with constraints on
> type compatibility) completely destroys that invariant.  But that
> invariant is one of the main benefits of having classes in the
> first place.

But if I want the class to behave exactly the same as when I created, why
would I change the method? Isn't changing a method an explicit indication
that a developer doesn't want the class to be invariant?
I believe this is more a philosophical/preferential question. Do you value
class integrity/immutably more or dynamicism/mutably? Obviously my
preference is towards the latter camp, but perhaps I am in the minority, and
the concerns over efficiency are certainly important as well.
Thanks,
Kris


>
> (There are efficiency concerns too, but I think the violation of
> integrity is the important part.)
>
> --lars
>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Peter Hall
>> Sent: 3. april 2008 09:58
>> To: Kris Zyp
>> Cc: es4-discuss Discuss
>> Subject: Re: Class method addition and replacement (was Re:
>> AOP Compatibility)
>>
>> Replacing a method effectively changes the type, even if the
>> signature is the same. If some code creates an instance of a
>> class using "new"
>> it should be able to rely on it being that type, and make
>> assumptions about how that object will behave. (This is not a
>> matter of breaking polymorphism because the same code created
>> the instance such that there is no possibility of a sub-type
>> instance being present).
>> Allowing methods to be replaced means that other parts of a
>> program could alter the behaviour of an object in a way that
>> could contradict those assumptions.
>>
>> Additionally, allowing methods to be replaced could reduce
>> the effectiveness of early binding optimisations. (Jeff Dyer
>> can correct me if I'm inaccurate here..) In AS3, class
>> methods are referenced via the class's traits table. They may
>> be accessed by name, but calls are bound to addresses where
>> possible, at compile time via the traits.
>> Allowing methods to be overridden would mean a choice of
>> copying the traits for each instance, which would increase
>> memory usage dramatically; or else checking for overrides at
>> runtime for every method call, which would hurt performance.
>>
>>
>> Peter
>>
>>
>> On Thu, Apr 3, 2008 at 4:23 PM, Kris Zyp <[hidden email]> wrote:
>> > >> the moment, but I assume you can't do replace a method
>> on a user
>> > >> class
>> >  >> with
>> >  >> another ad-hoc function.
>> >  >
>> >  > Absolutely not with fixtures,
>> >
>> >  I was thinking about this, is there any reason why you
>> can't replace
>> > a  class's method with another method or install a method on an
>> > instance object  that overrides the class's method,
>> assuming that the
>> > method signature  remains the same, the body has correct
>> typing use of
>> > |this|, and the class  is non-final? This seems to have the same
>> > integrity as method overriding in  subclasses. Being able
>> to do this
>> > (and possibly dynamically adding methods  to classes) would
>> bring the
>> > level of dynamicism that Mark had suggested with  his ES4 sugar
>> > proposal (being able to create classes on the fly), but  without
>> > destroying the fundamental ES4 typing/fixture system. This
>> could be
>> > used to solve AOP as well, and bring a distinctly higher level of
>> > dynamicism  which could be leveraged to progressively
>> build, serialize (with proper  introspection), and
>> deserialize classes.
>> >
>> >  Essentially, are there mutations to classes and object
>> instances that
>> > do not  effect integrity and do not violate explicit
>> contracts against
>> > mutation  (final annotation=no method mutations) that we
>> could allow?
>> >
>> >  Thanks,
>> >  Kris
>> >
>> >  _______________________________________________
>> >  Es4-discuss mailing list
>> >  [hidden email]
>> >  https://mail.mozilla.org/listinfo/es4-discuss
>> >
>> _______________________________________________
>> Es4-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es4-discuss
>>
>
>
>

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

Re: Class method addition and replacement (was Re: AOP Compatibility)

Peter Hall-4
If you want mutability, you can define methods as vars in the first place.

class Foo {

  // can be modified on a per-instance basis
  public var f : function (a:T):S = function (a:T):S {
      return null;
  }

}


but that is an explicit intent to permit that behaviour by the class author.

Peter



On Fri, Apr 4, 2008 at 1:02 AM, Kris Zyp <[hidden email]> wrote:

>
> > Just to echo Peter here, changing a method violates integrity in
> > the worst way.  If I say "new Cls" I *know* that the object I get
> > is of type Cls, and if I know the implementation of that class I
> > know what a call to a method of the type will do.  There is no
> > way subclassing can get in the way of that knowledge, but allowing
> > methods to be arbitrarily assigned to (even with constraints on
> > type compatibility) completely destroys that invariant.  But that
> > invariant is one of the main benefits of having classes in the
> > first place.
> >
>
>  But if I want the class to behave exactly the same as when I created, why
> would I change the method? Isn't changing a method an explicit indication
> that a developer doesn't want the class to be invariant?
>  I believe this is more a philosophical/preferential question. Do you value
> class integrity/immutably more or dynamicism/mutably? Obviously my
> preference is towards the latter camp, but perhaps I am in the minority, and
> the concerns over efficiency are certainly important as well.
>  Thanks,
>  Kris
>
>
>
>
>
> >
> > (There are efficiency concerns too, but I think the violation of
> > integrity is the important part.)
> >
> > --lars
> >
> >
> > > -----Original Message-----
> > > From: [hidden email]
> > > [mailto:[hidden email]] On Behalf Of Peter Hall
> > > Sent: 3. april 2008 09:58
> > > To: Kris Zyp
> > > Cc: es4-discuss Discuss
> > > Subject: Re: Class method addition and replacement (was Re:
> > > AOP Compatibility)
> > >
> > > Replacing a method effectively changes the type, even if the
> > > signature is the same. If some code creates an instance of a
> > > class using "new"
> > > it should be able to rely on it being that type, and make
> > > assumptions about how that object will behave. (This is not a
> > > matter of breaking polymorphism because the same code created
> > > the instance such that there is no possibility of a sub-type
> > > instance being present).
> > > Allowing methods to be replaced means that other parts of a
> > > program could alter the behaviour of an object in a way that
> > > could contradict those assumptions.
> > >
> > > Additionally, allowing methods to be replaced could reduce
> > > the effectiveness of early binding optimisations. (Jeff Dyer
> > > can correct me if I'm inaccurate here..) In AS3, class
> > > methods are referenced via the class's traits table. They may
> > > be accessed by name, but calls are bound to addresses where
> > > possible, at compile time via the traits.
> > > Allowing methods to be overridden would mean a choice of
> > > copying the traits for each instance, which would increase
> > > memory usage dramatically; or else checking for overrides at
> > > runtime for every method call, which would hurt performance.
> > >
> > >
> > > Peter
> > >
> > >
> > > On Thu, Apr 3, 2008 at 4:23 PM, Kris Zyp <[hidden email]> wrote:
> > > > >> the moment, but I assume you can't do replace a method
> > > on a user
> > > > >> class
> > > >  >> with
> > > >  >> another ad-hoc function.
> > > >  >
> > > >  > Absolutely not with fixtures,
> > > >
> > > >  I was thinking about this, is there any reason why you
> > > can't replace
> > > > a  class's method with another method or install a method on an
> > > > instance object  that overrides the class's method,
> > > assuming that the
> > > > method signature  remains the same, the body has correct
> > > typing use of
> > > > |this|, and the class  is non-final? This seems to have the same
> > > > integrity as method overriding in  subclasses. Being able
> > > to do this
> > > > (and possibly dynamically adding methods  to classes) would
> > > bring the
> > > > level of dynamicism that Mark had suggested with  his ES4 sugar
> > > > proposal (being able to create classes on the fly), but  without
> > > > destroying the fundamental ES4 typing/fixture system. This
> > > could be
> > > > used to solve AOP as well, and bring a distinctly higher level of
> > > > dynamicism  which could be leveraged to progressively
> > > build, serialize (with proper  introspection), and
> > > deserialize classes.
> > > >
> > > >  Essentially, are there mutations to classes and object
> > > instances that
> > > > do not  effect integrity and do not violate explicit
> > > contracts against
> > > > mutation  (final annotation=no method mutations) that we
> > > could allow?
> > > >
> > > >  Thanks,
> > > >  Kris
> > > >
> > > >  _______________________________________________
> > > >  Es4-discuss mailing list
> > > >  [hidden email]
> > > >  https://mail.mozilla.org/listinfo/es4-discuss
> > > >
> > > _______________________________________________
> > > Es4-discuss mailing list
> > > [hidden email]
> > > https://mail.mozilla.org/listinfo/es4-discuss
> > >
> > >
> >
> >
> >
> >
>
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Class method addition and replacement (was Re: AOP Compatibility)

Lars Hansen-3
In reply to this post by Kris Zyp-4
Most of the time I would not agree that "changing a method
is an explicit indication that a developer doesn't want
the class to be invariant".  Most of the time it's just an
indication that I'm (a) hacking to make something (appear to)
work or (b) tired and making a mistake.  And this goes
doubly for team programming and for programs that have a
long maintenance life.

Classes provide the integrity that is necessary for large
systems written by many people over significant periods of
time to work; such systems reward commitments to invariants
even if those invariants later can become a straightjacket
(and require reengineering).  In such a system the variation
points are (and need to be) explicit.  

--lars

> -----Original Message-----
> From: Kris Zyp [mailto:[hidden email]]
> Sent: 3. april 2008 18:02
> To: Lars Hansen; Peter Hall
> Cc: es4-discuss Discuss
> Subject: Re: Class method addition and replacement (was Re:
> AOP Compatibility)
>
> > Just to echo Peter here, changing a method violates
> integrity in the
> > worst way.  If I say "new Cls" I *know* that the object I get is of
> > type Cls, and if I know the implementation of that class I
> know what a
> > call to a method of the type will do.  There is no way
> subclassing can
> > get in the way of that knowledge, but allowing methods to be
> > arbitrarily assigned to (even with constraints on type
> compatibility)
> > completely destroys that invariant.  But that invariant is
> one of the
> > main benefits of having classes in the first place.
>
> But if I want the class to behave exactly the same as when I
> created, why would I change the method? Isn't changing a
> method an explicit indication that a developer doesn't want
> the class to be invariant?
> I believe this is more a philosophical/preferential question.
> Do you value class integrity/immutably more or
> dynamicism/mutably? Obviously my preference is towards the
> latter camp, but perhaps I am in the minority, and the
> concerns over efficiency are certainly important as well.
> Thanks,
> Kris
>
>
> >
> > (There are efficiency concerns too, but I think the violation of
> > integrity is the important part.)
> >
> > --lars
> >
> >> -----Original Message-----
> >> From: [hidden email]
> >> [mailto:[hidden email]] On Behalf Of Peter Hall
> >> Sent: 3. april 2008 09:58
> >> To: Kris Zyp
> >> Cc: es4-discuss Discuss
> >> Subject: Re: Class method addition and replacement (was Re:
> >> AOP Compatibility)
> >>
> >> Replacing a method effectively changes the type, even if the
> >> signature is the same. If some code creates an instance of a class
> >> using "new"
> >> it should be able to rely on it being that type, and make
> assumptions
> >> about how that object will behave. (This is not a matter
> of breaking
> >> polymorphism because the same code created the instance such that
> >> there is no possibility of a sub-type instance being present).
> >> Allowing methods to be replaced means that other parts of
> a program
> >> could alter the behaviour of an object in a way that could
> contradict
> >> those assumptions.
> >>
> >> Additionally, allowing methods to be replaced could reduce the
> >> effectiveness of early binding optimisations. (Jeff Dyer
> can correct
> >> me if I'm inaccurate here..) In AS3, class methods are
> referenced via
> >> the class's traits table. They may be accessed by name,
> but calls are
> >> bound to addresses where possible, at compile time via the traits.
> >> Allowing methods to be overridden would mean a choice of
> copying the
> >> traits for each instance, which would increase memory usage
> >> dramatically; or else checking for overrides at runtime for every
> >> method call, which would hurt performance.
> >>
> >>
> >> Peter
> >>
> >>
> >> On Thu, Apr 3, 2008 at 4:23 PM, Kris Zyp <[hidden email]> wrote:
> >> > >> the moment, but I assume you can't do replace a method
> >> on a user
> >> > >> class
> >> >  >> with
> >> >  >> another ad-hoc function.
> >> >  >
> >> >  > Absolutely not with fixtures,
> >> >
> >> >  I was thinking about this, is there any reason why you
> >> can't replace
> >> > a  class's method with another method or install a method on an
> >> > instance object  that overrides the class's method,
> >> assuming that the
> >> > method signature  remains the same, the body has correct
> >> typing use of
> >> > |this|, and the class  is non-final? This seems to have the same
> >> > integrity as method overriding in  subclasses. Being able
> >> to do this
> >> > (and possibly dynamically adding methods  to classes) would
> >> bring the
> >> > level of dynamicism that Mark had suggested with  his ES4 sugar
> >> > proposal (being able to create classes on the fly), but  without
> >> > destroying the fundamental ES4 typing/fixture system. This
> >> could be
> >> > used to solve AOP as well, and bring a distinctly higher
> level of
> >> > dynamicism  which could be leveraged to progressively
> >> build, serialize (with proper  introspection), and deserialize
> >> classes.
> >> >
> >> >  Essentially, are there mutations to classes and object
> >> instances that
> >> > do not  effect integrity and do not violate explicit
> >> contracts against
> >> > mutation  (final annotation=no method mutations) that we
> >> could allow?
> >> >
> >> >  Thanks,
> >> >  Kris
> >> >
> >> >  _______________________________________________
> >> >  Es4-discuss mailing list
> >> >  [hidden email]
> >> >  https://mail.mozilla.org/listinfo/es4-discuss
> >> >
> >> _______________________________________________
> >> Es4-discuss mailing list
> >> [hidden email]
> >> https://mail.mozilla.org/listinfo/es4-discuss
> >>
> >
> >
> >
>
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Class method addition and replacement (was Re: AOP Compatibility)

Brendan Eich-2
On Apr 3, 2008, at 6:12 PM, Lars Hansen wrote:
In such a system the variation
points are (and need to be) explicit.  


/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
12