[MAL] > If you are already using the buffer feature for e.g. array which > also implement "s#" but don't support "t#" for obvious reasons > you'll run into trouble, but then: arrays are binary data, > so changing from text mode to binary mode is well worth the > effort even if you just consider it a nuisance. Breaking existing code that works should be considered more than a nuisance. However, one answer would be to have "t#" _prefer_ to use the text buffer, but not insist on it. eg, the logic for processing "t#" could check if the text buffer is supported, and if not move back to the blob buffer. This should mean that all existing code still works, except for objects that support both buffers to mean different things. AFAIK there are no objects that qualify today, so it should work fine. Unix users _will_ need to revisit their thinking about "text mode" vs "binary mode" when writing these new objects (such as Unicode), but IMO that is more than reasonable - Unix users dont bother qualifying the open mode of their files, simply because it has no effect on their files. If for certain objects or requirements there _is_ a distinction, then new code can start to think these issues through. "Portable File IO" will simply be extended from simply "portable among all platforms" to "portable among all platforms and objects". Mark.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4