SC.Statecharts sendEvent parameters

[Maurits Lamers]

Hi all,

I ran into a problem when I noticed that only two parameters given to SC.Statechart#sendEvent reached the statechart, and any subsequent parameters didn't.
I assumed the sendEvent function would work the same like the SC.Request#notify function, but reading the code it turns out sendEvent indeed only supports two arguments.
Is there any specific reason why this is?

cheers

Maurits

[Dave Porter]

I've seen this code too, and I can't for the life of me figure out why it doesn't use apply to support an arbitrary number of arguments. Two possibilities: one, it was a quick implementation that was supposed to get improved later but wasn't; two, I think the "standard practice" with passing arguments around is to create a single hash object with all your named variables in it and pass that around. It keeps all your variables together in one (by-reference) place as it gets passed around the statechart. I couldn't make a coherent argument though for why that's such an overwhelmingly good idea that sendEvent actually restricts you though.

Thoughts? This would be an easy fix to fix.

Maurits

--
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.

[mir ion]

:-) probably we all noticed this at a given moment. My conclusion is Dave's 2nd. I think that when you have complex call paths it is safer and cleaner to pass hashes (via named arguments) than unnamed arguments that can be easily misplaced, etc. Code is more readable and simpler to debug. Usually I'm using the 1st param as a context and the 2nd as extra data hash. If you agree with this view I think that we should simply rename the 2 params accordingly to clearly mark their role and of course put a small comment into the doc.

[Topher Fangio]

I agree with passing the hash. Originally, I thought it was stupid that it didn't allow more than two, but now that I have stuck with it, it makes the code a lot easier to understand and, in my mind, it has become a best practice.

On the flip side: allowing more arguments won't change how we currently use the code, so I guess it's not a big deal to allow them :-)

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Tyler Keating]

I just wanted to point out that apply is often slower than call in most browsers, sometimes by 50%, and that accessing arguments is almost universally slower and should be avoided (there's a lot of articles on this, although with some conflicting results).

In any case, supporting n arguments via apply + arguments is not a good idea and it is faster to instead use call with one context argument (or two arguments, context and options?).

If people like the fixed two argument method, we could make that a standard format used everywhere through the framework.

--

Tyler Keating

ty...@sproutcore.com

[Topher Fangio]

I'm all for standardization, however, I'm guessing this is a breaking change so something we should think about for 2.0?

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Tyler Keating]

Agreed, although I'm only aware of a couple methods that allow multiple arguments and shouldn't:  SC.Object.prototype.invokeLater and SC.Object.prototype.invokeOnceLater.  Otherwise extending methods to support an extra context argument and possibly a second argument (options?) should be backward compatible.

Thoughts on usefulness of two vs one extra argument?  Thoughts on argument names?

--

Tyler Keating

ty...@sproutcore.com

[mir ion]

+1 for context & options asap.

This problem is not concerning only this case: there are a lot of methods that are accepting optional and arguments with multiple meaning depending on type. For example, see the mess with queries that was recently fixed. If you read the code you find a lot of if-s depending on context and types of arguments.

And I think that we should find a way to optimize/replace sc_super. I don't have any hard proof but I feel that it eats a lot of time.

[Topher Fangio]

I agree with context & options as I think they are pretty universally understood at this point.

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Dave Porter]

sc_super needs discussing but elsewhere.

What's the benefit to two arguments over one? If there's a semantic reason, I'm all for it; if not, then why bother? (Possible semantic reason: the first argument is intended for passing around to multiple functions a la multiple statechart events and actions, while the second one is more of a one-off thing?)

[mir ion]

semantic and practical too (code is easier to read and understand). as your example 1st may be the event, 2nd the extra data for the event, etc.

[Maurits Lamers]

The problem in my case is that I use the statechart to initiate a node js style callback mechanism, but then wrapped as a sendEvent to the state chart.

Because I fire off quite a few requests simultaneously, it is nice to know which requests is actually sending the event. (SC.Request.notify style)

As the nodejs style callback already has 2 arguments, I need a third one.

I agree with that having endless lists of parameters is not a good idea, but just having two parameters feels like an arbitrary amount.

cheers

Maurits

[Dave Porter]

"Arbitrary" is my feeling too, which is why I was looking for a semantic reason for two. One makes sense, but then why have two? If you have two, why not have infinite?

[mir ion]

It is arbitrary but we can be pragmatic: it covers lot of cases with context/params and semantically, it is a good model

[Maurits Lamers]

Also (reading up from the other posts): what is the speed of having to create an object literal to put the arguments in and then read them out again?

Second thought: in ES5 strict arguments are a proper array, so is the apply there similarly slow?

Maurits

[Dave Porter]

(Maurits, have we discussed moving to "use strict", or is that just an idle question?)