On 13 May 2012 13:57, Brendan Eich <[email protected]> wrote:
> Protocols are fine and perhaps a new-free one will take over some years
> hence, but not soon.
>
>
> - Should there be alternate, possibly less confusing, ways of coercing
>> values? ToPrimitive() would certainly be nice to have.
>>
>
> An object may need to be coerced to a number of value types. How would
> ToPrimitive know which one to use? There may be a default, but not a unique
> target type.
>
Vaguely-related use-case, mentioned only so that TC-39 et al get end-user
feedback :)
In GPSEE (a server-side embedding of SpiderMonkey with a focus on POSIX) we
have a number of data types which share a common type of backing
store....we call them "ByteThings", and, really, they are just C pointers +
size, and the JS object wrappers wind up being a sort of memory access
protocol.
When you have C-stuff, and in particular an FFI that can return pointers to
JS space, you find that, at some point, you need to cast. We decided to
arrange our ByteThing constructors so that they create *new* ByteThings
when invoked with the new operator, and otherwise treat their argument sort
of like a coercion source. We call this "ByteThing casting". So we can
write code ~ like this:
var mem = new Memory(2);
mem[0] = 65;
mem[1] = 0;
var sb = new MutableStruct("struct stat"); /* Make a new object that maps
properties to a struct stat */
stat("filename", sb);
print(Memory(sb).asString());
print(mem.asString());
which is basically
char *mem = malloc(2);
mem[0] = 65;
mem[1] = 0;
struct stat sb;
stat("filename", &sb);
printf("%s\n", (char *)sb):
printf("%s\n", mem);
Clearly this is a contrived example, but -- being able to have |new
Memory()| and |Memory()| mean different, but related, things is useful to
us. We could solve the same class of problems without the new operator by
overloading based on argument type, but the code would be a little less
legible and harder to reason about if the argument types weren't apparent
at the callsite.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
