Re: [Factor-talk] How will it be more difficult?
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 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 } ;
METHOD: set-encoding { encoder encoding } >r delegate r> set-encoding ;
METHOD: set-encoding { output-stream encoding } ;
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/vse012070mrt/direct/01/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] How will it be more difficult?
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 On Mon, Mar 10, 2008 at 9:09 PM, Eduardo Cavazos <[EMAIL PROTECTED]> wrote: > Matthew Willis wrote: > > > I REALLY don't want working with the various formats I work with to > > become any harder than it already is. I do not want to sacrifice the > > ease of saying 'iso-2022-jp ', 'shift-jis ', > > and all the other adorable encodings japanese people like to use. > > In the api that I'm proposing, the examples you give above still look like > this: > > iso-2022-jp > > shift-jis > > How is that "harder" than the current api? It's in fact identical. > > Ed > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] How will it be more difficult?
Eduardo Cavazos wrote: > In the api that I'm proposing, the examples you give above still look > like > this: > > iso-2022-jp > > shift-jis > > How is that "harder" than the current api? It's in fact identical. Ed, your "smart pathname" proposal has two distinct parts. The first part is the automatic promotion of a string to a UTF8 pathname; we can think of this as specifying that UTF8 is the 'default'. The second part is that the pathname and encoding travel as one item on the stack. Can you give some examples where having the pathname/encoding be one item rather than two simplifies code? Where do we pass these pairs around? In all the cases I've seen the encoding is a literal symbol that's pushed right before calling the constructor. Slava - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
