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 < jjusti...@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 < >> jjusti...@googlemail.com >> <mailto:jjustincc@googlemail.**com<jjusti...@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@lists.berlios.de >> <mailto:Opensim-dev@lists.**berlios.de<Opensim-dev@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@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@lists.berlios.de > https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev> >
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev