[1:13]<Dantman> tlrobinson, ^_^ Need any flags to go with that? Hmmm... I think todays sysop flag is coloured Midori [16:40]<Sembiance> :) [17:34]<nrstott> Is 'extend' the community convention for JS Mixins, or is this meant more to imply inheritance? [17:38]<ashb> to me it signals mixin [17:40]* ondras uses that for inheritance [17:40]<ondras> :) [17:48]<nrstott> ashb, do you prefer that to actually using 'mixin' ? [17:53]<ashb> oh probably do use mixin. [17:55]<nrstott> I notice that SproutCore uses "extend" [17:55]<nrstott> I want to use whatever is going to be best understood by CommonJS users [17:56]<nrstott> I personally prefer "mixin" because "extend" from Java has different connotations. [17:56]<ashb> yeah you are probably right [17:56]<ashb> mixin is certainly unamibigious [18:12]<inimino> nrstott: 'extend' is used by jQuery and prototype.js [18:13]<inimino> nrstott: but I think it's worth using 'mixin' since it is a little less ambiguous [18:13]<nrstott> so if everyone prefers the unambiguity of 'mixin', why did 'extend' become so popular ;0 [18:13]<ashb> Rule 1 [18:24]<inimino> the people in this channel probably aren't a good representative sample of the people who make a JavaScript library popular [18:24]<nrstott> yeah I know that, damn experts [18:24]<nrstott> I imagine extend is more popular thanks to Java [18:34]<ondras> wow [18:34]<ondras> the html5 audio element is not bad [18:34]<ondras> but ff is having some issues with ogg vorbis, as opposed to plain .wavs [23:43]<ashb> hmmm - i just hit a need for a muttable but fixed sized binary [23:53]<kriskowal> ashb what does this change? [23:53]<ashb> kriskowal: depends how i do it [23:53]<kriskowal> by mutable and fixed-size, do you mean that accessing beyond bounds should throw an error, or that setting the length should throw an error? [23:53]<ashb> both [23:53]<kriskowal> why the latter? [23:53]<ashb> the case is a ccallback function for libcurl [23:54]<ashb> it passes be a char* and says 'write up to n bytes here' [23:54]<ashb> *me [23:54]<kriskowal> yeah, pretty common [23:54]<ashb> so its half way between a BString and an BArray [23:54]<kriskowal> i think a byte array would suffice for that case. that's what it's intended for anyway [23:55]<kriskowal> would libcurl retain the reference to the buffer after completing? [23:55]<ashb> well it would probably recycle it internally [23:56]<ashb> right now i'm creating a returning a BA from JS and copying the data over [23:56]<kriskowal> google's blob has funny caveats about the underlying allocation that seem to indicate that the storage is not owned by javascript and can vanish at any time. [23:56]<kriskowal> as i recall. [23:56]<ashb> is probably useful in certain cases [23:57]<ashb> but i can probably just create a special object type which has some/most of the BA API [23:57]<kriskowal> bear in mind that binary/e is on the horizon [23:57]<ashb> yeah [23:57]<ashb> whats new in that? [23:57]<kriskowal> whatever needs to be. [23:57]<ashb> ah k [23:58]<kriskowal> but for one, i'm ditching string-likeness and array-likeness [23:58]<ashb> it probably wont be missed [23:58]<kriskowal> it might, but we won't know until we see [23:59]<ashb> yeah [23:59]<kriskowal> i'll prolly break it into a bytearray and bytestring in one proposal with an extension for bitarray and bitstring [23:59]<ashb> any more feedback from that Apple guy? [23:59]<kriskowal> who? [23:59]<ashb> who ever started the discussion about blobs on es-discuss [23:59]<kriskowal> you might be referring to binary42