std.data.json formal review

[Andrei Alexandrescu via Digitalmars-d]

On 8/18/15 1:21 PM, Sönke Ludwig wrote:
> Am 18.08.2015 um 00:37 schrieb Andrei Alexandrescu:
>> On 8/17/15 2:56 PM, Sönke Ludwig wrote:
>>> - The enum is useful to be able to identify the types outside of the D
>>> code itself. For example when serializing the data to disk, or when
>>> communicating with C code.
>>
>> OK.
>>
>>> - It enables the use of pattern matching (final switch), which is often
>>> very convenient, faster, and safer than an if-else cascade.
>>
>> Sounds tenuous.
>
> It's more convenient/readable in cases where a complex type is used
> (typeID == Type.object vs. has!(JSONValue[string]). This is especially
> true if the type is ever changed (or parametric) and all has!()/get!()
> code needs to be adjusted accordingly.
>
> It's faster, even if there is no indirect call involved in the pointer
> case, because the compiler can emit efficient jump tables instead of
> generating a series of conditional jumps (if-else-cascade).
>
> It's safer because of the possibility to use final switch in addition to
> a normal switch.
>
> I wouldn't call that tenuous.

Well I guess I would, but no matter. It's something where reasonable 
people may disagree.

>>> - A hypothesis is that it is faster, because there is no function call
>>> indirection involved.
>>
>> Again: pointers do all integrals do. To compare:
>>
>> if (myptr == ThePtrOf!int) { ... this is an int ... }
>>
>> I want to make clear that this is understood.
>
> Got that.
>
>>
>>> - It naturally enables fully statically typed operator forwarding as far
>>> as possible (have a look at the examples of the current version). A
>>> pointer based version could do this, too, but only by jumping through
>>> hoops.
>>
>> I'm unclear on that. Could you please point me to the actual file and
>> lines?
>
> See the operator implementation code [1] that is completely statically
> typed until the final "switch" happens [2]. You can of course do the
> same for the pointer based Algebraic, but that would just
> duplicate/override the code that is already implemented by the pointer
> method.

Classic code factoring can be done to avoid duplication.

>>> - The same type can be used multiple times with a different enum name.
>>> This can alternatively be solved using a Typedef!T, but I had several
>>> occasions where that proved useful.
>>
>> Unclear on this.
>
> I'd say this is just a little perk of the representation but not a hard
> argument since it can be achieved in a different way relatively easily.
>
> [1]:
> https://github.com/s-ludwig/taggedalgebraic/blob/591b45ca8f99dbab1da966192c67f45354c1e34e/source/taggedalgebraic.d#L145
>
> [2]:
> https://github.com/s-ludwig/taggedalgebraic/blob/591b45ca8f99dbab1da966192c67f45354c1e34e/source/taggedalgebraic.d#L551

Thanks.


Andrei