"DH" == Dick Hardt <DickH(_at_)ActiveState(_dot_)com> writes:
DH> yes, so that the script writer can decide the context
DH> So, module writers will have to "fix" and code that makes assumptions about
DH> char size. You could consider this similar to writing subs that could be
DH> either called directly or as method calls, and the sub having to figure out
DH> how it was called.
But having the outside context leak through make life difficult. I
hate Action at a distance, and give that Rule #1 has it as all pragmas
default to no (i.e. no utf8)
Let's look at it this way, according to Larry's rule, all modules are
_already_ encoded with 'no utf8' at the top.
DH> A different example is modules used with threading. We have come across
DH> several modules that assume that they are in a single threaded space and
DH> store data in statics that is not valid between different interpretors. We
DH> are having to find and "fix" this issue as well.
You are looking at it from the wrong perspective. Think recursively. A
module declares itself to be thread safe, If it uses a sub-module that
isn't it has lied (violated its contract). Threadness is a fundemental
environment issue (think $^O or unix, win32).
A module defines an interface, part of that definition would be the
utf8-ness of the input, output, and file formats. This is not
fundemental, it is a format issue, something that is part of the
contract.
Think of it like reaching behind the back of an object and tweaking
its private instance variables.
Then there is the question of what is character oriented and what is
not. And will it change over the life of perl.
$foo = substring($exe, 32, 15); # Character or Byte?
DH> good point -- this leads to the thought that there should be a pragma that
DH> says "I want to deal with things as bytes" so that if there is a utf16
DH> pragma in the future, you will not break code that is treating scrings as
DH> binary data.
DH> C<use byte> ???
It's already here 'no utf8', 'no utf16', 'no nothing';
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
chaimf(_at_)pobox(_dot_)com
+1-718-236-0183
