Re: Optional method arguments in the DOM
On Fri, 23 Jun 2006 16:50:52 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote: Now there are several obvious modifications to this system that could be made: [...] How about having specified in the IDL which parameters default to certain value when omitted? So both the parameter being omitted is specified and it's value to be assumed by the UA is. void() test(foo, [bar] null) Would be a way to do it I guess. (I don't really like the syntax though...) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Optional method arguments in the DOM
We didn't do optional arguments for the same reasons we didn't do some other things in the DOM: they aren't supported in enough languages that they really belong in the core/portable/standardized specification. I'm not convinced there's a need to re-evaluate that decision. __ ... Three things are most perilous: Connectors that corrode, Unproven algorithms, and self-modifying code! ... -- Threes Rev 1.1 - Duane Elms / Leslie Fish (http://www.ovff.org/pegasus/songs/threes-rev-11.html)
Re: Optional method arguments in the DOM
On Jun 29, 2006, at 22:12, Joseph Kesselman wrote: We didn't do optional arguments for the same reasons we didn't do some other things in the DOM: they aren't supported in enough languages that they really belong in the core/portable/standardized specification. Given that they can be mapped naturally onto Javascript and Java (and a bunch of others), and given that language-specific bindings can override that to make them required if it's really needed, I don't see why we shouldn't have them. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: Optional method arguments in the DOM
Jim Ley wrote: You're argument that a library would be difficult to write, it's easy for a library not to use ===, so that's a rather strange argument. My point was that there are suddenly all sorts of gotchas involved in writing a library if you allow this sort of thing. It's part of the specification of ES, and there are no problems with it in any implementations - a million scripts would break: I didn't say there are problems; I said the behavior is not as simple as you make it sound. Not at all, given the large number of optional properties already in browser OM I'll assume you meant optional arguments. In which case there really aren't all that many. It might be worth it to make a list of the existing ones to see what things look like. it would make much more sense to use an Interface language that supported optionals I'd be much happier with that than with using IDL but then hand-writing exceptions in the ECMAScript bindings, which is what the original proposal sounded like to me. Perhaps I should clarify what my initial concern was with the example of how Mozilla actually works. At the moment, when you make a call from JS on a DOM object, there is a layer that translates the JS function invokation into a C++ function call. This layer has to know how to translate the arguments to the JS function (which are typically JS Objects, JS Strings, etc) into C++ objects, wchar_t pointers and so forth. Since C++ is strongly typed, the translation needs to figure out which exact type to convert to; this is where the IDL is actually used. The translation layer looks up the IDL declaration for the function being called, and that tells it whether to convert a JS Object to Node or Element or whatever. Like I said, automating this part makes incredible amounts of sense -- otherwise you'd have to hand-write the argument conversion for every single function in the DOM. We do do manual argument conversion for a small number of functions that have optional arguments in DOM level 0, and it's quite a pain to do that way. Now there are several obvious modifications to this system that could be made: 1) It could be assumed that any time the number of arguments actually passed to the function is smaller than the number declared in IDL, the remaining ones should be assumed to be undefined and attempts be made to convert them to something reasonable. This would mean that _all_ DOM methods would sprout optional arguments. I'm OK with this. 2) Functions in IDL could be somehow tagged with the number of arguments at the end that are optional. If a different interface language needs to be used here, so be it. I'm OK with this too. 3) We could leave the IDL exactly as-is and write non-computer-parseable prose to indicate where optional args are OK and where they're not OK. This was the original proposal. I'm NOT OK with this, for the reasons I've already stated. Note that solutions #1 and #2 do not address a lot of common argument-defaulting scenarios (e.g. document.open type stuff) in DOM0 because those involve defaulting to a value that's not == to undefined. but window.undefined is of course read only. Why? This isn't particularly relevant to the javascript library author, as a hash on window is not something you can do in a library for hopefully obvious reasons. Why not? Just createElement an iframe that loads some of your stuff (e.g. this is the only sane way to convert an HTML document into a DOM in browsers), and then use the window in it. There's more than one Window object around. ;) -Boris
Re: Optional method arguments in the DOM
Jim Ley wrote: In ECMAScript DOM's definately, anything that accepts null should definately work if a user doesn't explicitly define null, because ES authors expect functions to behave that way, with all non-passed functions simply set to undefined. undefined and null are not at all the same thing, though. Script authors should expect consistency here between host objects and native ES objects, so optional methods are expected, even if the only defaults are undefined and things that == undefined. So what should undefined become? Null? False? True? Some random default DOM node in some cases? This makes authoring JS library's very easy in my mind Only if the library never uses === and if all defaulting is done in ways that only default things to something == to undefined, and as long as the object passed in is not used as a key to store stuff on other objects [1]. That's off the top of my head in about 3 minutes of thinking; if someone wants to do extensive research on all the ways undefined and null differ across different ECMAScript impls, go for it. It'd be a prereq for the proposal anyway. So the only argument for avoiding it is for UA authors who want to directly generate the interface by the IDL Which seems like an eminently sensible thing to do to me. Dealing with each interface by hand would be a huge undertaking, given how many DOM interfaces there are and how many more are being added all the time. I don't think it's sensible to limit ourselves due to a deficiency in something completely unrelated. Sure, if you don't care whether UAs implement your spec. ;) -Boris [1] Try this: I get interoperable results in Opera, Konqueror, and Gecko that indicate that window[undefined] behaves weirdly: var x = window; x[null] = 1; x[undefined] = 2; alert(x[null]); alert(x[undefined]); here setting x to new Object() instead of window actually gives different behavior from having it be window (but interoperably different!) in all three browsers.
Re: Optional method arguments in the DOM
Anne van Kesteren [EMAIL PROTECTED]
What do implementors and authors think of having more optional method
arguments in the DOM where that makes sense?
In ECMAScript DOM's definately, anything that accepts null should definately
work if a user doesn't explicitly define null, because ES authors expect
functions to behave that way, with all non-passed functions simply set to
undefined.
Script authors should expect consistency here between host objects and
native ES objects, so optional methods are expected, even if the only
defaults are undefined and things that == undefined.
This makes authoring JS library's very easy in my mind, I don't understand
Boris's point, you can wrap mozilla's broken xmlhttp.send() by having
function myxmlhttp.prototype.send(chicken) {
this.xmlhttp.send(String(chicken))
}
(which will of course not pass exactly the same as in other browsers, but it
will work just as well as using send(Broken UA) does now...)
So the only argument for avoiding it is for UA authors who want to directly
generate the interface by the IDL, I don't think it's sensible to limit
ourselves due to a deficiency in something completely unrelated.
cheers,
Jim.
Re: Optional method arguments in the DOM
Anne van Kesteren wrote: What do implementors and authors think of having more optional method arguments in the DOM where that makes sense? I frankly think it's a bad idea. For UA-provided objects, it significantly increases the implementation complexity. Since the IDL used can't express optional arguments, the UA would need to either ad-hoc define the default values for them or have a long hardcoded list of optional things with some sort of automated system for checking against that list on method calls... Even worse, it increases complexity for _anyone_ who wants to implement these interfaces. Right now, if I want to write a JS library that allows authors to, say, abstract away XMLHttpRequest differences between UAs, and I want to use DOM events to communicate with my callees, I would implement EventTarget and authors could just use patterns they already know to set up listeners for events they're interested in. If you start allowing optional args, then I have to deal with authors not passing in all the args, which means more code for me. -Boris
