See my comments bellow

On Friday, April 4, 2003, at 02:25 PM, Raymond Irving wrote:


Please see below:


--- Benoit Marchant <[EMAIL PROTECTED]> wrote:
I would prefer
I  prefer the syntax super.setSize(w,h).

What about adding

DynAPIObject.prototype.overwrite = function(sC,n) {
     var c = this.frame[sC];
     var superMethod =
c.prototype._superPrototype[n];
     var capitalized = n.charAt(0).toUpperCase() +
n.substring(1,n.length);
     var        superMethodOverridename = 'super'+
capitalized;
     if(superMethod &&
!c.prototype[superMethodOverridename]) {
         c.prototype[superMethodOverridename] =
superMethod;
     }
};

and in the class you want to overwrite:
p.setSize = function(width,height) {
        this.superSetSize (widt h,height);
        //Then do your stuff
}
dynapi.overwrite('EventObject','setSize');//which
basically does
p.superSetSize = mySuperClass.prototype.setSize


that way it's in the same fashin as the setPrototype() ? It's "clean" in the sense that it's important to overrides only the implementation defined is in your super class, guaranteeing a correct overriding if different subclasses overrides the same method multiple time. In javascript, it's easy to directly get the implementation of an of your ascendant, and bypass some !


Looks good. One question though... How would this work with multiple overrides?

example:

function MyClass1(){}
var p= dynapi.setPrototype('MyClass1','DynLayer');
dynapi.overwrite('MyClass1','setSize');
p.setSize=function(w,h){
  this.superSetSize(w,h);
   // code here
};

function MyClass2(){}
var p= dynapi.setPrototype('MyClass2','MyClass1');
dynapi.overwrite('MyClass2','setSize');
p.setSize=function(w,h){
  this.superSetSize(w,h);       
  // will the above superSetSize be DynLayer's or
MyClass1 setSize function?
The above will call MyClass1.prototype.setSize
  // If it's MyClass1 then how will the MyClass1 code
access DynLayer's setSize()?
Because the overwrite method creates MyClass1.prototype.superSetSize = DynLayer .prototype.superSetSize


// code here };

Also, how will it work with multiple extensions?

It doesn't ! There's the exact same problem with categories in Objective-C. If you define the same method (even for new method that didn't exists) on a class in 2 different source files, depending on the loading mechanism, either the first or the last would win.
There's no way to determine an order between the multiple definitions, and even if there were an order, at best you want to control which one wins, but defining any combining of the different implementations looks risky to me.
So bottom line we should decide which one wins, and stick with that.
In the implementation I did, the first one win as I check if the superSetSize exists, and if it does, then subsequent use overwrite would have no effects.
If we don't check, then the last call win. I guess, if you provide a extension it would be called after and you would expect it to win.


This overwrite use is meant for overriding method in subclasses. Now if you want to re define setSize on DynLayer with your custom implementation, and then have all subclasses that inherit from DynLayer and override setSize to use your new implementation, you really have to assign DynLayer.prototype.setSize = myNewSetSize

And all should be as expected. But that usage could be described as a "hack". The same can be done in the Objective-C run-time, but I've only done it once. This usage should be pretty rare, and therefore you can do it manually I think.

Make sense ?

Benoit

example:

// extension library #1
dynapi.overwrite('DynLayer','setSize');
DynLayer.prototype.setSize=function(w,h){
   this.superSetSize(w,h);
  // code here
};

// extension library #2 - loaded after extension #1
dynapi.overwrite('DynLayer','setSize');
DynLayer.prototype.setSize=function(w,h){
   this.superSetSize(w,h);
  // code here
};

When setSize id called will it execute code in the
following order?

object -> extension #2 setSize() -> extension #1
setSize() -  DynLayer's orginal setSize()

Is the term "subclass" correct or should we term
it as
"overwrite"?
We should use overwrite, it's the appropriate term
in OO terminology
when a subclass modify an inherited method.

Thanks


--
Raymond Irving


Benoit



Any comments?


--
Raymond Irving

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators,
forms, and more
http://tax.yahoo.com




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of
bandwidth!
No other company gives more support or power for
your dedicated server


http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]


http://www.mail-archive.com/[EMAIL PROTECTED]/




__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com


------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED] http://www.mail-archive.com/[EMAIL PROTECTED]/




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/

Reply via email to