At 03:35 AM 11/11/2001 -0500, James Mastros wrote:
>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.
Doesn't matter--we should do The Right Thing from the beginning. (And we're
not guaranteed they're the same, since we're not guaranteeing that
sizeof(INTVAL) == sizeof(int))
> > 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.)
We shouldn't cheat--the string length field should be considered a black
box until we need the speed, at which point we play Macro Games and change
string_length into a direct fetch.
It's possible that for speed reasons some code will not bother setting the
length field in the string struct. The GC system needs the bytes allocated
to be right, but that's it.
> > 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.))
I don't mind biasing Parrot's core this way. negative-from-the-end doesn't
get in the way of other languages, so I'm fine with it, and it's
potentially a speedup.
> > 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.)
Exceptions are close to the top of the list for things, since we've gotten
to the point where stuff can throw more than fatal errors.
> > (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.)
Will. Docs, darn it! Must have docs! Tests, too, but if you have docs you
can rope someone into writing the tests and the lot of 'ya can submit a
chunk of patches. :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
