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

Hi Cameron,

Thanks for your reply, comments in-line from here:

Cameron McCormack wrote:
> 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.

The values can be anything which is valid in the object position of an 
rdf triple, which is anything tbh, normally one of the xsd:types though.

To handle conversion the API has a core set of TypedLiteralConverters 
implementers must implement for things like dataTime/numerics/boolean 
etc - however people can also register there own TypedLiteralConverters 
to support more types (for instance base64 encoded binary). A 
TypedLiteralConverter is a just a callback that given a string value and 
for a specific string-iri type will do the conversion to native js type 
or "something else" which the user has implemented.

The toValue method implementation checks to see if a typed literal 
converter is registered for the given .type and then passes in the .type 
and .value (as a string) to get the converted/native type back.

Thus, the any definition is because it entirely depends on the .type as 
to what is returned.

This specific toValue method on this interface may be dropped, however 
the functionality will still be on another interface, so perhaps best to 
focus on that.

Given a function:

   any convertType( in DOMString value , in DOMString type );

where value is a string of say "1234" and type is an IRI for say 
xsd:integer - and where (critically) a function to convert the specified 
type may not be known, what should the return be? null, void/undefined 
or other?

I imagine this isn't the most common use-case, but it is required 
functionality we have to specify as part of the API.

In reply generally to everything below, the names aren't set in stone, 
nor the interface on which the functionality will be exposed, but 
regardless of where we put it and other details aside, it's the specific 
situation above that's causing the questions / being a pita.

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

We're debating this at the minute, one person has said yes "null" could 
be a converted value for them, which means yes it could be - however 
it's also been suggested that "null" is a single value thus, we could 
disallow it / reserve it, because a TypedLiteral with a type of 
"http://example.org/types/null" could only ever be null, thus detected 
and specified without needing any conversion functionality.

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

Hopefully the above clarifies, if not just let me know - can easily pull 
the time to sort this out whenever you're free, via mailing list, irc or 
other.

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

Good point, I have no idea why valueOf was originally chosen TBH as I'm 
new-ish to the working group, however I'm sure it could be changed / 
renamed or even removed to avoid confusion.

Thanks again for your reply thus far, much appreciated,

Nathan

Received on Friday, 29 October 2010 03:55:46 UTC