std.jgrandson

[Sönke Ludwig via Digitalmars-d]

Am 03.08.2014 20:57, schrieb w0rp:
> On Sunday, 3 August 2014 at 18:37:48 UTC, Sönke Ludwig wrote:
>>
>> The "undefined" state in the vibe.d version was necessary due to early
>> API decisions and it's more or less a prominent part of it
>> (specifically because the API was designed to behave similar to
>> JavaScript). In hindsight, I'd definitely avoid that. However, I don't
>> think its existence (also in the form of Algebraic.init) is an issue
>> per se, as long as such values are properly handled when converting
>> the runtime value back to a JSON string (i.e. skipped or treated as
>> null values).
>
> My issue with is is that if you ask for a key in an object which doesn't
> exist, you get an 'undefined' value back, just like JavaScript. I'd
> rather that be propagated as a RangeError, which is more consistent with
> associative arrays in the language and probably more correct.

Yes, this is what I meant with the JavaScript part of API. In addition 
to opIndex(), there should of course also be a .get(key, default_value) 
style accessor and the "in" operator.

> A minor
> issue is being able to create a Json object which isn't a valid Json
> object by itself. I'd rather the initial value was just 'null', which
> would match how pointers and class instances behave in the language.

This is what I meant with not being an issue by itself. But having such 
a special value of course has its pros and cons, and I could personally 
definitely also live with JSON values being initialized to JSON "null", 
if somebody hacks Algebraic to support that kind of use case.