Re: Feedback requested on returning null/void or throwing an exception

Hi Nathan.

Nathan:
> We have the following interface:
> 
> [NoInterfaceObject]
> interface TypedLiteral : RDFNode {
>     readonly attribute stringifier DOMString value;
>     readonly attribute IRI                   type;
>     any valueOf ();
> };
> 
> If a converter is registered with the API for the specific `type`
> then valueOf() returns the native type (for instance Date in the
> case of xsd:dateTime).
> 
> We are currently looking for input on what valueOf() should return
> when there is no converter registered. Choices we're looking at are:
> 
>  1: unconverted value
>  2: throw an exception
>  3: return null
>  4: return void

What are the unconverted values?  If they’re not values in the IDL value
space, you’ll need to define some sort of conversion.

> 1 and 2 aren't really any option tbh - 3 I prefer, 4 another member
> of the WG prefers, but primarily we're looking for best practise in
> this scenario, and whether 4 is even an option.

Well, the operation is defined to return “any”, so you have to return
something.  You could define it so that undefined is returned in ES.
Could “null” ever be a converted value?

I guess I would need to understand the problem space a bit better.

BTW, I guess it is deliberate that you have a function named valueOf on
there, so that you get funky behaviour when you use these objects in
arithmetic expressions in ES?

It *may* be confusing.  Since the TypedLiteral prototype will have both
a toString and a valueOf, you can get situations where converting the
object to a string by passing it to the String constructor function
results in different value from concatenating '' on to it:

  var p = { toString: function() { return 'a string' },
            valueOf: function() { return 123 } };
  var a = Object.create(p);
  alert(String(a));  // alerts "a string"
  alert(a + '');     // alerts "123"

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 28 October 2010 22:59:57 UTC