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