Hello,
So far, I've suggested that two mechanisms, used in conjunction, could provide
a better api for encodings:
An 'encoding' variable
A way to explicitly set the encoding of a stream
These work in many cases, but there's an exception which doesn't play nicely:
file-contents.
Of course, I'm proposing the original stack effect for file-contents:
: file-contents ( path -- str )
The question is, how do you override the encoding in a convenient fasion? You
never get ahold of the stream. So you pretty much have to use the 'encoding'
variable. There's one usage of file-contents in core:
: malloc-file-contents ( path -- alien )
binary file-contents >byte-array malloc-byte-array ;
It would be unwise for malloc-file-contents to operate under the assumption
that the 'encoding' is binary. This is one way to do it:
: malloc-file-contents ( path -- alien )
[
binary encoding set
file-contents >byte-array malloc-byte-array
] with-scope ;
I'm not satisfied with that. There should be a better way that's as concise as
the original.
Slava and I have been discussing the idea of having "path" objects which are
richer than plain strings. In fact we already have 'pathname' objects.
A path object can have an encoding slot
Attaching an encoding to a path object is a good thing because the encoding
will move around with the path object.
Here's an example:
"/etc/passwd" file-contents
That just works because the file is plain text.
"a-font-file" file-contents
If the font file is binary, we'd like to explicitly specify this:
"a-font-file" binary-file file-contents
So you ask, how is that better than this:
"a-font-file" binary file-contents
It's better because the stack-effect of file-contents in the first example is:
: file-contents ( path -- str )
Because of this, specifying the encoding is optional.
How does binary-file work?
: binary-file ( string -- path ) ... ;
It takes a string and returns a path object with the encoding slot set
appropriately.
Path objects are the right thing
Words which operate on filenames should accept strings, or the more endowed
path objects.
Ed
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk
