Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2009-10-31:

[0:00] <ashb> .read could just as easily return a ByteArray couldn't it?
[0:00] <kriskowal> so, i'm willing to entertain the notion of a single blob type?
[0:00] <ashb> what brought this up?
[0:00] <kriskowal> it would need to have some reasonably string-like behaviors *and* some reasonably array-like behaviors all in one?which i'm concerned might be problematic
[0:01] <ashb> hmmm might be.
[0:01] <ashb> i do think that we put too many things in 'just cos String or Array have them tho'
[0:01] <ashb> without actually thinking if they would be useufl
[0:01] <kriskowal> hdon had a concern about object identity issues for equivalent byte strings
[0:02] <kriskowal> i actually agree, really.
[0:02] <ashb> b"abc" === b"abc" type thing is what you think should happen?
[0:02] <kriskowal> we might as well start with a small proposal and grow it out?but having a comprehensive proposal at this point helps us scope out the future-compatibility landscape
[0:03] <kriskowal> in the distant future, yes
[0:03] <ashb> so i guess that makes sense if bytestrings are immutable
[0:03] <kriskowal> which is the intent
[0:03] <ashb> but its not implementable in any engine that i'm aware of :)
[0:04] <kriskowal> not easily
[0:04] <kriskowal> typeof b"abc" == "bytestring" or something like that too
[0:04] <ashb> anyway - thats a pipedream right now
[0:04] <kriskowal> tyepof ByteString() == "bytestring" and typeof new ByteString() == "object", mirroring the distinction between String and new String
[0:05] <kriskowal> yes, but we're establishing pivotal API's right now.
[0:05] <ashb> re |Array.prototype.slice.call(arguments);| doesn't |Array.slice(arguments)| work everywhere
[0:05] <kriskowal> it would be prudent to make types that can grow into the future, rather than having to revise our API's to use different types in the future
[0:06] <kriskowal> i think the generics are a relatively "recent" addition to the language
[0:06] <ashb> oh true if you want to work on IE 6 then i guess the ydont
[0:06] <ashb> yes - they were JS 1.6
[0:07] <kriskowal> they're only in JavaScript, none of the other impls that i can see
[0:07] <kriskowal> e.g., not so much in chrome
[0:07] <kriskowal> nor jsc
[0:07] <ashb> chrome is resolutely ES 262 for reasons i've never quite got
[0:08] <kriskowal> they're following webkit
[0:08] <ashb> huh. so its not. I thought it was in more places
[0:10] <kriskowal> so i think that in the near time, we're talking about new ByteString objects, with the intent of being analogous to new String objects
[0:10] <kriskowal> which means that new ByteString([97]) != new ByteString([97])
[0:10] <ashb> yeah, its nothing else is acheivable in the near tearm (3 years or so)
[0:10] <kriskowal> with the eventual hope that native bytestrings will be possible in the future
[0:12] <ashb> yeah
[0:12] <kriskowal> we should explicitly forbid the newless variant, reserving it
[0:12] <ashb> it would ceratinly be a nice to have
[0:13] <kriskowal> so, i also think that a byte buffer has distinctly different uses than an immutable byte string
[0:13] <ashb> yeah
[0:14] <kriskowal> but perhaps we can get away with just one type that does both
[0:14] <ashb> probably - but i'm not up to thinking about that right now
[0:14] <kriskowal> especially if we're clever about making it duck-type compatible with the future native byte string
[0:14] <kriskowal> aight.
[0:14] <kriskowal> in any case, i think byte string indexing is irrelevant in the short term
[0:15] <kriskowal> javascript strings didn't even support indexing for a long time. you had to use charAt
[0:15] <ashb> o_O really
[0:15] <ashb> wonder how i didn't know that
[0:16] <kriskowal> i'm talking late 90's
[0:17] <kriskowal> it was a common hazard that code that used indexing worked in some browsers and not *cough* others
[0:17] <ashb> ah i was barely involved in the web then
[0:17] <ashb> anyway - continue this convo tomorrow
[0:17] <kriskowal> aye
[0:17] <kriskowal> ttyl
[12:43] <ondras> starting from rev. 631, v8cgi now supports modules/1.1 :)
[12:45] <ashb> :)
[18:36] <ashb> afonso: it was you hwo mentioned JS/cc wasn't it?
[18:37] <ashb> whats your take on it? some of hte things i read in the doc dont inspire me with confidence
[18:49] <kriskowal> ashb: i looked into it. there's a preprocessor that sets it up with a name space
[18:49] <kriskowal> it would greatly benefit from migration to commonjs, especially for the paring out of engine specific components
[18:50] <kriskowal> i contacted the author; he's not terribly interested in pursuing commonjs
[18:50] <kriskowal> not for js/cc anyway.
[20:05] <MisterN> wtf
[20:06] <MisterN> oh, my chat client just had a bug, sorry.
[21:55] <angelm> hi ondrey!

 

 

Logs by date :