Daniel Ehrenberg wrote:
> I don't understand how this will interact with byte array readers,
> sockets and other kinds of streams which don't have paths as such. I
> don't see how it could be any different from how things are right now,
> unless you want to generalize paths significantly. Unless this
> generalization (which I don't fully understand the workings of) is
> used, there would be two different parallel ways of using encodings,
> and twice as many words.
>
>
Dan,
Of course it would be a bit of a stretch to generalize paths to socket
addresses and processes, but that's not what Ed is proposing.
Ed is proposing that encoding symbols are defined as follows:
: utf8 \ utf8 set-encoding ;
: binary \ binary set-encoding ;
etc.
Where set-encoding is defined as follows (using multimethod syntax from
extra):
GENERIC: set-encoding ( obj encoding -- newobj )
METHOD: set-encoding { string symbol } >r <pathname> r> set-encoding ;
METHOD: set-encoding { pathname symbol } >r clone r> >>encoding ;
METHOD: set-encoding { stream symbol } construct-empty set-encoding ;
METHOD: set-encoding { decoder encoding } >r delegate r> set-encoding ;
METHOD: set-encoding { input-stream encoding } <decoder> ;
METHOD: set-encoding { encoder encoding } >r delegate r> set-encoding ;
METHOD: set-encoding { output-stream encoding } <encoder> ;
Even if we decide not to do pathnames, we could have a set-encoding that
implements the last five methods only.
Personally I think this design is pretty nifty. Unlike using an encoding
variable, or having the user write 'binary >>encoding' on new streams,
it doesn't make me want to vomit. :-) I still don't think it represents
a big improvement over the current system, but at least I don't consider
it a regression, and if other people speak up in favor of this idea then
we can probably implement it.
Of course, to do this properly, we will need multimethods and
inheritance in the core (for stream and encoding superclasses).
So, that gives me a convenient excuse to postpone this discussion :-)
Back to work!
Slava
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
