Dispatching entirely off argument types and not anything else (like count) is an interesting idea. I'm not sure it's on topic for this discussion though. Is there a way to actually do type dispatch in ES at present, let alone efficiently?
Based on my understanding of current VMs, you'd have to do a song and dance (per argument) like this: Is it undefined? Terminate argument scanning. Check typeof to see if it is a special type; dispatch based on that if so. If it's not a special type, check to see if it's null. If so, dispatch based on 'object' since you can't know more about the type than that and have to guess. If it's not null, call Object.getPrototypeOf and then somehow look up that prototype against the type information you're doing overload dispatch against. It's not clear to me how this would interact with newish features like proxies, either, but I suppose it would at least work. At present doing fast dispatch based on argument count and THEN only doing per-argument type checks if necessary is a huge performance boost because VMs can actually generate relatively fast native code for an arguments.length check. Typeof checks and getPrototypeOf do not generally produce fast code in my experience so it would be problematic to do them for every overloaded call site instead of just call sites that actually care about the types of particular arguments. Doing this type of dispatch is comparatively simple in .NET since for any non-null value you can request a Type object for it (via GetType) and then use that as a key into a lookup table/dictionary - so the operation becomes 'if (x == null) typeId = 0 else typeId = typeTable[x.getType()]' or something along those lines, which you can optimize down to a set of conditionals when the number of types you care about is small. The fact that ES does not allow setting properties on all values means it's impossible to hang type information off values like that. To put it another way, if I have an overloaded functions with two signatures - like say writeline(s) and writeline(f, s) - then in practice I just dispatch off the argument count. Because there are not multiple signatures with the same count, there's no way the user could have intended to call something else. In use cases where correctness is more important, you'd probably want to rigorously check every argument and dispatch off that. >From a performance perspective I also find the idea of having to 'scan' the arguments list sequentially looking for an undefined sentinel to be pretty gross. Do we really need to introduce the awful null terminated string pattern, along with all its problems, in more places? On Sun, Nov 10, 2013 at 1:49 PM, Mark S. Miller <erig...@google.com> wrote: > On Sun, Nov 10, 2013 at 1:30 PM, K. Gadd <k...@luminance.org> wrote: > >> JSIL and embind both need arguments.length for efficient method call >> dispatch when dealing with overloaded functions. Is it your intent that all >> such scenarios must now pay the cost of creating an array (to hold the rest >> arguments) and then destructuring it, for every call? At present it's >> possible to avoid this overhead in V8 and SpiderMonkey by using >> arguments.length + arguments[n] or by using arguments.length + patterned >> argument names. >> > > Hi Katelyn, > > No one is taking arguments away. Perhaps we would if we could but we > can't. So as I said just now to Allen, if you really need to do this, go > ahead and use arguments.length. > > But do you really need to do this? Assuming for a moment that we were all > agreed that the best practice is to treat absence the same as undefined, > why not go with the best practice and be done? > > > >> >> >> On Sun, Nov 10, 2013 at 1:24 PM, David Bruant <bruan...@gmail.com> wrote: >> >>> Le 10/11/2013 22:19, Brendan Eich a écrit : >>> >>> On Nov 10, 2013, at 9:12 PM, Andrea Giammarchi < >>>>> andrea.giammar...@gmail.com> wrote: >>>>> >>>>> Not sure why this is so needed though. >>>>> >>>> Allen's posts make the case: webidl and varargs-style functions. Not >>>> all legacy. >>>> >>> WebIDL creates spec, not code. The language syntax doesn't need to >>> evolve for that. Allen showed that rest params+destructuring allows >>> self-hosting without |arguments| >>> Varargs functions have rest parameters. >>> >>> David >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
