This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26901 - Stop using "octet"
Summary: Stop using "octet"
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-25 10:25 UTC by Anne
Modified: 2014-12-05 16:45 UTC (History)
7 users (show)

See Also:


Attachments

Description Anne 2014-09-25 10:25:24 UTC
People are justifying using "octet" as terminology because IDL has it.

Per https://encoding.spec.whatwg.org#byte we standardize on byte.

So...

Perhaps avoid calling these bytes directly altogether, as we have ArrayBuffer and friends for that. "short short" and "unsigned short short"?
Comment 1 Anne 2014-12-04 18:37:00 UTC
We should just adopt the ES terms here. Int8, Uint8, etc. See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-typedarray-objects
Comment 2 Tab Atkins Jr. 2014-12-04 18:38:53 UTC
+1, the ES terms are easy to understand and pretty standard.
Comment 3 Travis Leithead [MSFT] 2014-12-04 18:49:01 UTC
(In reply to Tab Atkins Jr. from comment #2)
> +1, the ES terms are easy to understand and pretty standard.

+2 :-)
Comment 4 Domenic Denicola 2014-12-04 18:54:46 UTC
I dunno, I'd rather do something more ambitious (we have another bug for it) where the only type is "number" and you use a restriction specifier for parameters like

foo(ClampBetween(0, 255) number bar)  // clamps to range
baz(EnsureBetween(0, 255) number bar) // throws outside range
Comment 5 Marcos Caceres 2014-12-05 00:44:29 UTC
Elsewhere [1], I proposed something like:

typedef Number[−128..127] Byte;

Having that would shrink the WebIDL spec significantly too ;) 

[1] https://github.com/heycam/webidl/issues/14
Comment 6 Tab Atkins Jr. 2014-12-05 00:55:31 UTC
"Byte" is ambiguous - it means 8 bits, but doesn't specify how to interpret it.  Int8 and Uint8 have no such issue.
Comment 7 Marcos Caceres 2014-12-05 02:55:30 UTC
(In reply to Tab Atkins Jr. from comment #6)
> "Byte" is ambiguous - it means 8 bits, but doesn't specify how to interpret
> it.  Int8 and Uint8 have no such issue.

for sure, the point is just to have some syntax to declare ranges... we might be able to kill a whole bunch as they are probably not used in specs.
Comment 8 Boris Zbarsky 2014-12-05 08:32:35 UTC
> we might be able to kill a whole bunch as they are probably not used in specs.

The following are used in specs as function arguments or writable attributes:

octet, short, unsigned short, long, unsigned long, long long, unsigned long long.

So the only unused one seems to be "byte".  It's used for return values and constant values, but I don't see any obvious coercious to "byte" offhand.
Comment 9 Domenic Denicola 2014-12-05 16:45:46 UTC
One problem with using the uint8 name is that in theory ES wants to add native int8/uint8/etc. types: https://github.com/nikomatsakis/typed-objects-explainer/blob/master/core.md#primitive-type-definitions. It would be confusing for WebIDL to mean something (very) different.

Still it'd be nice to fix the problem in the OP, without having to first solve the whole ambitious reform-number-types idea. Not sure what to do.

(I plan to go comment on Marcos's GitHub issue with ideas for number types.)