With this capability in mind, it is possible for write to automatically change modes based on its argument. For example, we can detect a binary type and force the write to be binary.
Using the contents of the above example to illustrate:
ofile: open %out
write ofile str
write ofile bin ; in /binary mode
The first part is written in string (text) mode with line conversions. The second part is written as binary, without conversions.
(And, of course we will continue to allow /binary to be used to always write as binary.)
If we decide to allow it, we will probably also support:
write %out bin ; uses /binary mode
The binary is written to the file without line conversion.
I'd be leery of unexpected 'auto' line conversions while mixing string! and binary! writes. May lead to data related issues that can be hard to test for.
My initial vote is to let/make the coder control the write operations explicitly...so no.
Goldevil 28-Feb-2007 2:37:47
It's a simple feature that follows the rebol spirit : Keep it simple. I agree with the idea.
Henrik 28-Feb-2007 3:02:06
I don't know if I agree with it regarding ports, but the ability to debug what's going on is important.
Regarding WRITE: I really never use WRITE, only WRITE/BINARY.
Brian, as long as you control the input data, probe it and figure out its type, then the result would strictly speaking not be unexpected as you can tell the type of input.
But it has to be clearly mentioned in the help for WRITE what WRITE does for each supported datatype.
If you want ultimate control in R3:
write %out to-binary "String"
I think it's 2% more elegant. :-)
OTOH, we lose some symmetry for READ and WRITE, as in you'd still need READ/BINARY to read the file.
Anton Reisacher 28-Feb-2007 3:50:15
I really don't like this proposition.
If we want this feature, why you do not introduce a new refinement like /auto for automatic mode adaptation to the data type?
Oldes 28-Feb-2007 7:39:05
I like it, as I mostly use write/binary anyway.
write %out as-binary "String"
But don't know, if it's so important. I can live with current state as well.
Anton Rolls 28-Feb-2007 7:47:55
I think it has potential to save keystrokes.
But I'd be very cautious with that one.
Maxim Olivier-Adlhoch 28-Feb-2007 12:18:54
it makes for simpler implementation in mixed mode I/O where you need some data to go in both formats... I had such an issue this year implementing a webservice. and had to switch port modes and all.. not fun trying to make it work when you have no clue that modes can be changed on the fly.
how many times do we forget to switch /binary on when saving raw data, its already identified as binary by its type... why not stream it properly. In any case if you want to save a string in binary, you still have to use /binary switch so its not really changing any current code.
If the data drives I/O and a binary is detected, there is no point in ever sending it in non binary mode... so I am for it.
You have one lest either [][] to implement all the time to switch between binary data or not .
Dave Cope 2-Mar-2007 5:47:42
I think Anton's idea of a /auto refinement is good. It would help to illustrate the action of the code - a add a bit of self documentation.
Regards.
Gregg Irwin 2-Mar-2007 11:23:44
At first glance it seems like a good idea to me. It makes REBOL smarter on our behalf, but doesn't take control away from us. Kind of how JOIN/REJOIN use the first value to determine the datatype.
Robert 2-Mar-2007 11:45:01
I'm more for explicit writing down what you want to do (even it it's more work to type. Hey, than learn to type faster) as having implicit things happend behind the scene that you have to keep in mind.
Oldes 2-Mar-2007 15:21:08
I cannot help myself, but I think, that it would be better if the default state for read/write was binary not string.
Coccinelle 5-Mar-2007 4:42:23
Since when read or write can have a port! as source ?
Volker 10-Mar-2007 17:52:17
I like it. 'as-string and 'as-binary are no overhead, if one wants to be explicit.
And when downloadig by cgi, the headers are written in text and the data in binary. Keeps the scripts short.
