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

2008-04-06 Thread Nathan de Vries
On 06/04/2008, at 1:38 AM, Brendan Eich wrote: Sure, developers will be able to explicitly mark areas in their code which they deem appropriate for another developer to change, but that strikes me as a bit of a fantasy land. The fantasy here would be that JS has been kept down on the same-

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

2008-04-06 Thread Garrett Smith
On Thu, Apr 3, 2008 at 5:20 PM, Peter Hall [EMAIL PROTECTED] wrote: 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; } } A

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

2008-04-06 Thread Nathan de Vries
On Sun, 2008-04-06 at 13:07 -0700, Brendan Eich wrote: You're doing it again: wholesale locking down is false as a general statement, and almost entirely false broken down into particulars. You're right, wholesale locking down is false. However, it is the migration path for developers who

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

2008-04-05 Thread Nathan de Vries
On 04/04/2008, at 1:35 PM, Brendan Eich wrote: EIBTI! Perhaps not the best reference given the topic, given that Python makes class overriding and resurrection of overridden classes possible with their __builtin__ module. I'm actually quite surprised to hear that there are so many on this

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

2008-04-05 Thread Brendan Eich
On Apr 5, 2008, at 12:42 AM, Nathan de Vries wrote: On 04/04/2008, at 1:35 PM, Brendan Eich wrote: EIBTI! Perhaps not the best reference given the topic, given that Python makes class overriding and resurrection of overridden classes possible with their __builtin__ module. Good point.

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

2008-04-03 Thread Kris Zyp
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

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

2008-04-03 Thread Peter Hall
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

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

2008-04-03 Thread Lars Hansen
of integrity is the important part.) --lars -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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

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

2008-04-03 Thread Brendan Eich
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

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

2008-04-03 Thread Lars Hansen
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