[Opensim-dev] Change JSON constants to be able to act as independent flags?

[Mic Bowman]

then lets go with #2. i really dislike bit constants unless size matters
and it absolutely does not in this case. and "lsl does it" doesn't carry
any weight with me (as you well know). :-)

--mic


On Tue, Feb 19, 2013 at 2:40 PM, Justin Clark-Casey <
jjustincc at googlemail.com> wrote:

> On 19/02/13 18:01, Mic Bowman wrote:
>
>> I'm generally not in favor of bit fields. they are too hard to extend.
>> two alternatives that might work based on the
>> idea that there are really two pieces of information we want to convey...
>> the type of the JSON node (null, object/hash,
>> array, value) and the type of value in a value node.
>>
>
> An LSL integer would give you 31 bits to play with - do you envisage
> needing more than 31 constants (ignoring the potential to use negative
> constants)?  I'm also curious as to what extendability you're thinking of -
> JSON is unlikely to change.
>
>
>
>> 0) take the OSD approach and just return the type of the node/value
>> (which is where I had planned to end up), null is 0,
>> hash/object is 1, array is 2, value is anything greater than 2, string is
>> 3, integer 4, etc...
>>
>
> The caller then has to know that there is an order to the constants.  If I
> want to see if something is a value then I need to do > JSON_TYPE_VALUE
> whereas for any other type I would use ==, which doesn't feel particularly
> intuitive to me.
>
> Using a flag approach also appears very common in LSL and would work more
> as scripters expect (using bit operators for comparison, etc.).  I know
> you're not a fan of LSL but I believe it's better to try and work with the
> grain where possible.
>
>
>
>> 1) partition the return into a node type and value type. use the bottom
>> three bits for node type and the rest for the
>> value type if the node is a value node; this at least provides some space
>> for future extensibility
>>
>
> I think a mixed bits and values approach is the worst of both worlds -
> callers then need to know which constants can be tested with bit operators
> and which cannot!
>
>
>
>> 2) split the operations into two.. JsonGetNodeType() and
>> JsonGetValueType()
>>
>
> You could do that.  It would match the JsonGetValue(), JsonSetValue(),
> etc. functions.  I would argue they are still both better off using flag
> constants for the reasons above.
>
>
>> --mic
>>
>>
>>
>> On Mon, Feb 18, 2013 at 5:02 PM, Justin Clark-Casey <
>> jjustincc at googlemail.com <mailto:jjustincc at googlemail.**com<jjustincc at googlemail.com>>>
>> wrote:
>>
>>     Hi Mic.  One small thing in case I don't catch you on IRC - could we
>> change the Json node types to be independently
>>     flaggable values rather than 0, 1, 2, 3 as they are at the moment?
>>  That way, one would be able to more easily flag
>>     a node as both Value and String in the future, for example.
>>
>>     --
>>     Justin Clark-Casey (justincc)
>>     OSVW Consulting
>>     http://justincc.org
>>     http://twitter.com/justincc
>>     ______________________________**___________________
>>     Opensim-dev mailing list
>>     Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.**berlios.de<Opensim-dev at lists.berlios.de>
>> >
>>     https://lists.berlios.de/__**mailman/listinfo/opensim-dev<https://lists.berlios.de/__mailman/listinfo/opensim-dev><
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>> >
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>
>>
>
> --
> Justin Clark-Casey (justincc)
> OSVW Consulting
> http://justincc.org
> http://twitter.com/justincc
> ______________________________**_________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20130219/86bfba1a/attachment-0001.html>