17:04 < ashb> Wes-: btw just how much do you want toSource output to be evalable?
17:05 < ashb> its kinda a pain as a debugging repr if it is
17:05 < Wes-> ashb: absolutely convinced it should be
17:05 < Wes-> if you want debugging repr, should be some other method
17:05 < MisterN> ashb: how about a toDebugString()?
17:06 < ashb> Wes-: and what should toSource return when its not?
17:06 < Wes-> ashb: when it's not what?
17:06 < ashb> such as for a DOM node that to get the same state would need the entire document
17:06 < Wes-> ashb: do DOM nodes have toSource methods?
17:06 < ashb> not currently
17:07 < Wes-> well there ya go, lol
17:07 < Wes-> seriously, prepending require("binary") to the output is not a big readability impediment
17:07 < ashb> nor does anything not from a mozilla engine mind :)
17:07 < Wes-> OTOH it is a /huge/ functionality difference
17:08 < Wes-> I frequently use .toSource(), aka uneval, for JSON-like operations
17:08 < Wes-> you could theoretically have an object of objects of ByteStrings, call toSource() on the top-level one, store it on disk, and eval it at a later date
17:09 < Wes-> without the require() statement, that code is no longer reliable
17:10 < ashb> that doesn't work very well for packages.
17:10 < ashb> well
17:10 < ashb> it means a package has to know how it can be indentified globally
17:10 < ashb> which given package names can be aliases poses some problems
17:10 < ashb> but i guess each package should have a canonical name
17:11 < ashb> require('com.github/ashb/http-fetch-flusspferd#http-fetch') i guess
17:11 < ashb> could be the canonical form