EXPath binary module - comments - endianness

On 03/08/2013 15:11, Adam Retter wrote:
> 1) Using a string for a binary value seems overkill to me, and dangerous (2)(3).
> 2) Using a boolean allows the compiler to statically enforce the
> choice. The error can be caught at compile time.
> 3) Developers can't put in an invalid value (typo or nonsense) e.g.
> "little-encidan"
> 4) The error code (if any) at Runtime caused by an invalid value is
> not detailed in the spec. It should be if there is a dynamic error.
>
> Perhaps if I am mistaken, and there are more than two octet orders,
> then using a string would be fine. If you are going to use a string,
> how about declaring two variables in the module, that define these
> (i.e. constants). This would could help people rely on the compiler to
> statically enforce their intention and guard against mistakes. Of
> course the same could be done for binary values to make your code more
> readable! e.g.
>
> bin:pack-double(12245, "LE")   becomes  bin:pack-double(12345,
> $bin:little-endian)
> bin:pack-double(12245, "BE")   becomes  bin:pack-double(12345, $bin:big-endian)
On 03/08/2013 15:12, Adam Retter wrote:
>> As Little Endian is the default that equates to false() and Big Endian
>> would equate to true(). So why should we make this change?
>> bin:pack-double(12245, "LE")   becomes  bin:pack-double(12345, false())
>> bin:pack-double(12245, "BE")   becomes   bin:pack-double(12345, true())

On 03/08/2013 17:25, Michael Kay wrote:
> I made this suggestion on the grounds that anyone reading the code would have to look up the spec to work out what false() means; boolean parameters make for poor code readability. It's hard enough to remember what big-endian and little-endian mean without trying to remember what true() and false() mean.

On 03/08/2013 15:51, Michael Sokolov wrote:
> I like to avoid booleans for function signatures since code like 
> bin:pack-double(12245, true()) is obscure.  Your suggestion of a 
> constant is OK, but would probably get ignored by a lot of users. I 
> understand the concern about the need for dynamic checking of the 
> value, though: How about defining a subtype of xs:string 
> (bin:byte-order) that is only allowed to take on the two values ("BE", 
> "LE")?  I'm probably not as conversant with the XQuery type system as 
> I could be, but would that make the restriction easier in any way?

Obviously I'm in favour of an explict or 'enumerated' value, rather than 
a boolean. I defer to others on the best approach for static checking - 
the dynamic one isn't terribly difficult to code.....

But there is another issue we haven't addressed - the default being 
'little endian'. Whilst I understand that the common x86 architecture is 
little-endian, I'm more concerned that I very rarely (perhaps never?) 
see little-endian data in my own limited practice - mostly its been 
big-endian. And we write our (hex) numbers big-endian. Can anyone give a 
really compelling important use case that really favours a little-endian 
default?

John

-- 
*John Lumley* MA PhD CEng FIEE
john@saxonica.com <mailto:john@saxonica.com>
on behalf of Saxonica Ltd