On Sun, 11 Nov 2001, Alex Gough wrote:
> On Sun, 11 Nov 2001, Alex Gough wrote:
> > ook, cool, but string_length returns an INTVAL, not an int.
> Remember that people who say "negative" usually mean "positive", they
> just don't know it yet. Always look on the bright si-ide of life, de
> do, de do de do de do.
Huha? Anyway, it doesn't matter. INTVAL's and ints will be casted
implicitly in C.
> Yes, also this doesn't follow the style of the rest of string.c
> (s->strlen is your friend)
No, it isn't. I'm not sure s->strlen is always gaurnteed to be correct;
string_length(s) is. (I found a case where it was wrong when coding my
version of ord() once, though that ended up being a problem with my
version of chr(). The point is that string_length is an API, but the
contents of the struct are not.)
> and I'm not sure that (char*)[index]
> is the right way to get ord for $encoding.
It is in fact quite wrong; it's return is useless for anything but
singlebyte and 7-bit utf8.
> Have we actually worked out what ord should do yet?
The meaning that I like is this:
Two-arg ord sets $1 to the codepoint of $2's first character in $2's
current chartype. (This means that it isn't very useful without another
op to get the current chartype of a string.)
Thus, ord(s, index) looks somthing like:
if (s->encoding == ENCODING_SINGLEBYTE) {
return (char*)s->bufstart[index];
} else {
transcode(s, ENCODING_UTF32, NULL);
return (utf32_t *)s->bufstart[index];
}
> if (index < 0 ) {
> string_ord should be more like this anyhow:
> index = s->strlen + index; /* zero based */
> }
I'd tend to disagree; this is more of a language thing then a runtime
thing. If it's done on a Parrot level, then it should be in the oplib,
not in string.c (I'd also say that this goes for all the
negitive-index-from-end stuff that Perl does. (Which I like, but biases
the Parrot's core in a way that I don't like.))
> Also, is it wise to be #defining every one of our errors to be 1,
> aren't these better being an enum, or is there merely not yet a plan
> for exceptions that works?
I think there's not yet a plan for exceptions. (Note, though, that the
values of the exception #defines are currently only used for errorlevels
on the intepreter's death.)
> (The general gist of the patch is damn good, btw)
I agree. (The documentation is even more lacking then in mine, though.
Dan'll complain. Or should, anyway.)
-=- James Mastros
--
Put bin Laden out like a bad cigar: http://www.fieler.com/terror
"You know what happens when you bomb Afghanastan? Thats right, you knock
over the rubble." -=- SLM
