bigeasy / packet / 297
80%

DEFAULT BRANCH: master
Ran
Jobs 1
Files 109
Run time –
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
297

push

travis-ci

bigeasy 
Remove pure-JavaScript IEEE754.

With this commit, I'm disabling many of the 32-bit floating point tests
until the next commit when they'll all work correctly.

I'm getting tired of Packet now. I'm getting tired of Packet and I'm getting
used to letting go of decisions I made over two years ago. In Strata, I was
preserving the ability to use `null` as a key.

Why? Because when I first wrote that little bit of code, `null` didn't matter.
Over time, it's been a muddle. Remember, the user can use `null` as a key, so
you'll need to store the key in an array, and if the array length is zero, that
means the key does not exist, but if it's `null`, that's because we allow a
`null` key.

When is the user ever going to want an index that permits a single `null` key?
They might allow `null` keys, fine, but they're going to want to have
duplicates, multiple `null` keys. That is the only real world use case.

I let go of that recently, with a huff of frustration with myself. Why in the
world, if you're going to simulate duplicate keys, would not not also insist on
a simulation of null keys? If the user wants a null key, they can define their
key as that possibly array I'm defining for them.

I'm feeling the same early frustration with maintaining IEEE754 in
pure-JavaScript in Packet. It feels like baggage I'm dragging around. When are
people going to want to use Packet outside of the context of Node.js? In the
browser? Sure, but they can use Browserify to get a `Buffer` that provides the
IEEE754 conversion. Or, better still, they can use `ArrayBuffer`, because I'm
not going to provide moral support for someone who wants to create a binary
packet parser that runs on Internet Explorer 6. Binary is the future of
JavaScript and Packet paves the way to the future. It's not used by anyone right
now, so why carve out legacy support at it's inception.

It's not used by anyone right now and the first few bytes are by people who want
to use it with Node.js. If someone want to use it outside of Node.js they should
work with the `ArrayBuffer` and `DataView`. If they really want to support older
browsers with no support for `ArrayBuffer` and `DataView`, then they can use a
polyfill.

If someone does want to support an older browser, the module loading involved
becomes their problem. I'm not saddled with generating parsers that need to
account for a module loading mechanism.

In the future, I seem some means by which the user can define functions for use
in the Packet pattern language, and pass variables to Packet functions, but
pulling in support libraries for the basic Packet patterns, that is something
extra that is only required by IEEE754, and only if I assume that there is no
support for parsing IEEE754 on the platform.

In fact, I now intend to implement IEEE754 using `ArrayBuffer` and `DataView`
because they are available in JavaScript, in the browser and in node, and it
means that Packet can parse Buffer, Array, and ArrayBuffer objects.

With this commit I close the issue that asks me to preserve IEEE754 in
pure-JavaScript against `Array`. In future commits, as the generic parser is
phased out, I can remove `ieee754.js`.

Closes #189.
Closes #188.
Closes #186.
Closes #185.

2282 of 2966 relevant lines covered (76.94%)

140.15 hits per line

Jobs
ID Job ID Ran Files Coverage
1 297.1 0
76.94
 Travis Job 297.1
Source Files on build 297
Detailed source file information is not available for this build.