On Fri, Apr 23, 1999 at 06:07:31PM -0700, Gurusamy Sarathy wrote:
On Sat, 24 Apr 1999 00:42:51 BST, Tim Bunce wrote:
could be allowed such that the utf8 sub is only called when utf8 is in
effect, the ascii (or byte whatever) is called when we are in that mode
(which currently is when we are not in utf8 mode) and the last would be
called for any other utf8-like pragma, say if we had utf16 in effect.
Whoa! I think this whole thread is going off in the wrong direction.
Whether an _individual_ argument string contains utf8, utf16, ascii or
a gif has nothing to do with the lexical context of the sub that called
you.
Right, but I didn't think we were talking about how we mark data
as being of a particular type. Rather, we were talking about
how to inherit the caller's context for perl builtins within a
subroutine, so it would behave as if it were inlined where it
was called.
Think of a custom mychomp() subroutine that you may want to write
that returns the result rather than the number of chopped characters.
How will you write it so that it behaves as expected when the caller
is in utf8 mode?
I agree that there's a need to be able to discover more a callers
context. (Including the hints value in the output of caller seems like
one obvious approach.)
But I think other people were thinking, wrongly, that this would be a
general solution to the bigger problem.
As for marking data types in general, it is up to the module's API to
provide a mechanism to pass extra information that suggests what type
of data is being passed. One could bless() it, for example. As another
example, one could use the Win32 API model, where functions that expect
string arguments to be unicode have a 'W' suffix.
Yeap, all that and more is possible. People just need to remember that
there is a problem here and there's no magic bullet.
Tim.
