std.data.json formal review

Dmitry Olshansky via Digitalmars-d digitalmars-d at puremagic.com
Tue Aug 11 11:15:16 PDT 2015


On 11-Aug-2015 20:30, deadalnix wrote:
> On Tuesday, 11 August 2015 at 17:08:39 UTC, Atila Neves wrote:
>> On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
>>> Start of the two week process, folks.
>>>
>>> Code: https://github.com/s-ludwig/std_data_json
>>> Docs: http://s-ludwig.github.io/std_data_json/
>>>
>>> Atila
>>
>> I forgot to give warnings that the two week period was about to be up,
>> and was unsure from comments if this would be ready for voting, so
>> let's give it another two days unless there are objections.
>>
>> Atila
>
> Ok some actionable items.
>
> 1/ How big is a JSON struct ? What is the biggest element in the union ?
> Is that element really needed ? Recurse.

+1 Also most JS engines use nan-boxing to fit type tag along with the 
payload in 8 bytes total. At least the _fast_ path of std.data.json 
should take advantage of similar techniques.

> 2/ As far as I can see, the element are discriminated using typeid. An
> enum is preferable as the compiler would know values ahead of time and
> optimize based on this. It also allow use of things like final switch.

> 3/ Going from the untyped world to the typed world and provide an API to
> get back to the untyped word is a loser strategy. That sounds true
> intuitively, but also from my experience manipulating JSON in various
> languages. The Nodes produced by this lib need to be "manipulatable" as
> the unstructured values they represent.
>


-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list