sc_super in SC2

[Dave Porter]

Maurits and I discussed this a while back, and then mirionc brought it up over in the sendEvents chat. There are several things wrong with sc_super(). First of all, it's a build-tool string replacement. Not a dealbreaker, but it would be great to remove that random requirement. Second, it uses "arguments.callee", which is slow and which Maurits will remind you is deprecated in "use strict". Mirionc, your instinct is probably right that sc_super is slow.

From the limited thinking I've done about it, it seems like any viable replacement that doesn't use arguments.callee is going to lose the ability to blindly call superclass methods without knowing the name of the method you're in. Instead, we would have to get the superclass, and call the method ourselves. It's less concise than "sc_super()", but does anyone have a problem with requiring that in SC2?

If so, then any suggestions on syntax? Something better than

doAThing: function(foo, bar) {

  this.get('superclass').doAThing(foo, bar);

}

[Topher Fangio]

What about something like this?

    doAThing: function(foo, bar) {

      this.super('doAThing', foo, bar);

    }

Could super() be defined on SC.Object and have it do something like you suggested Dave?

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

--
You received this message because you are subscribed to the Google Groups "SproutCore Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sproutcore-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dave Porter]

That would be sweet but I think it would require the use of .apply(…, arguments) which according to the other thread is slower than we'd like. Anyone else, thoughts? I'd love it to be as concise as Topher's suggestion here.

[mir ion]

We'll just drop this slow arguments stuff - we'll use the named arguments if they are 1, 2, 3, etc. . And also, it is not necessary to replace everything at once. We find the best way to implement the right mechanism and then we pass through all modules. We will split/share the effort to gradually replace all or most sc_super occurrences. If each of us takes over a slice of code, we'll finish quite quickly. sc_super will be maintained, but we'll mark it as deprecated so we'll not risk anything. We'll just have to take care on the methods that are using arguments overloading (= multiple uses for the same slot). And again, in case of doubts, these methods can be processed later into 2.0 so we don't risk any collateral damage.

Mircea

[Maurits Lamers]

This is one of the things we might take a look at Ember for...

Maurits

[mir ion]

Just noticed the subject. Why wait SC2?

[Topher Fangio]

Out of curiosity, do we need to use .get()? Could it just be

    this._super.doAThing(foo, bar);

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Dave Porter]

I don't think underscores belong at the beginning of public APIs, but otherwise, yeah, this.super.doAThing would be fine by me! Can anyone think of any weird edge cases where super would be a calculated property?

[mir ion]

Just counted (manually ;-) ) we have 261 occurrences of sc_super into the frameworks dir

[Topher Fangio]

In regards to the SC 2 question: this would definitely be a breaking change. We could potentially deprecate it in SC 1.x, but if we actually removed it, it would need to be in 2.0 as most developers would have to go back and change their code to use the new method.

If we're interested in the speed improvements in 1.x, then I think we could get started, but from what I was hearing, this didn't seem like a huge thing we wanted to get "fixed" right away :-)

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Dave Porter]

Mircea, it's a big change to a well-known part of the API, so in my opinion, better to do it all at once and put it in SC2.

While limiting sendEvent arguments to two may make sense, I strongly disagree that we should force every method that may ever be overridden to only accept two arguments.

[mir ion]

I really don't understand why you consider it as a breaking change? We preserve sc_super but gradually remove it from the framework using a better construct that will be supported into SC.Object.

Concerning the arguments, I never considered that such move should be generalized. I'm thinking only at sendEvent and similar cases. Sorry if I was not clear.

[Dave Porter]

Cool, apologies, I thought you were applying it to sc_super.

It is a big change, and it's going to be different syntax; you're right that it doesn't have to be all at once (or breaking), but it would be nice to get everyone on board with it quick, and excise the old way. Otherwise it'll never go away. And SC2 is a big opportunity to do that sort of thing.

Anyway 261 ain't bad!