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). :-)<div><br></div><div>
--mic</div><div><br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 2:40 PM, Justin Clark-Casey <span dir="ltr"><<a href="mailto:jjustincc@googlemail.com" target="_blank">jjustincc@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 19/02/13 18:01, Mic Bowman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm generally not in favor of bit fields. they are too hard to extend. two alternatives that might work based on the<br>
idea that there are really two pieces of information we want to convey... the type of the JSON node (null, object/hash,<br>
array, value) and the type of value in a value node.<br>
</blockquote>
<br></div>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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,<br>
hash/object is 1, array is 2, value is anything greater than 2, string is 3, integer 4, etc...<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
1) partition the return into a node type and value type. use the bottom three bits for node type and the rest for the<br>
value type if the node is a value node; this at least provides some space for future extensibility<br>
</blockquote>
<br></div>
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!<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) split the operations into two.. JsonGetNodeType() and JsonGetValueType()<br>
</blockquote>
<br></div>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--mic<div class="im"><br>
<br>
<br>
On Mon, Feb 18, 2013 at 5:02 PM, Justin Clark-Casey <<a href="mailto:jjustincc@googlemail.com" target="_blank">jjustincc@googlemail.com</a> <mailto:<a href="mailto:jjustincc@googlemail.com" target="_blank">jjustincc@googlemail.<u></u>com</a>>> wrote:<br>
<br>
Hi Mic. One small thing in case I don't catch you on IRC - could we change the Json node types to be independently<br>
flaggable values rather than 0, 1, 2, 3 as they are at the moment? That way, one would be able to more easily flag<br>
a node as both Value and String in the future, for example.<br>
<br>
--<br>
Justin Clark-Casey (justincc)<br>
OSVW Consulting<br>
<a href="http://justincc.org" target="_blank">http://justincc.org</a><br>
<a href="http://twitter.com/justincc" target="_blank">http://twitter.com/justincc</a><br></div>
______________________________<u></u>___________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a> <mailto:<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.<u></u>berlios.de</a>><br>
<a href="https://lists.berlios.de/__mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/__<u></u>mailman/listinfo/opensim-dev</a> <<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a>><div class="im">
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
-- <br>
Justin Clark-Casey (justincc)<br>
OSVW Consulting<br>
<a href="http://justincc.org" target="_blank">http://justincc.org</a><br>
<a href="http://twitter.com/justincc" target="_blank">http://twitter.com/justincc</a><br>
______________________________<u></u>_________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div>