On Thu, May 10, 2007 at 03:33:41AM -0500, Joshua Isom wrote: > > On May 9, 2007, at 4:01 PM, Nicholas Clark wrote:
> >So, !s->strlen does scan as quickly and easily. > > > > To some, but it isn't as easy to just literally read. "Not s's strlen" > is a lot different than "STRING_IS_EMTPY". Since the code will be read > often, and often by people not familiar with parrot's internals, it > makes sense to make it easily readable. It takes me a second to read > !s->strlen, but half a second to read STRING_IS_EMTPY. Whilst I agree with the .5s vs 1s, I'm still not convinced that I agree [and we may have to agree to disagree] It comes down to the level of understanding of the internals. If every construction is hidden behind macros that explain its function, then I think it will help the beginners (as you say) and the knowledgeable (who know what STRING_IS_EMPTY() expands to). But when I read STRING_IS_EMPTY() I stop and wonder "right, how?" and stop to look up what it expands to. Which one does need to do, if one is chasing down a bug. (Because with a bug, things *aren't* working as at least one of the designer or implementor intended, which means assumptions need to be checked. Maybe I'm odd) So, personally, I find it easier with a comment on the struct by that member, saying that an empty string has zero length. Mmm, looking at it right now: struct parrot_string_t { pobj_t obj; UINTVAL bufused; char *strstart; UINTVAL strlen; /* parrot_string_representation_t representation;*/ struct _encoding *encoding; struct _charset *charset; UINTVAL hashval; /* cached hash value computation; not yet used */ }; It makes me wonder what's the difference between bufused and strlen. > >s == NULL is also more tersely written as !s, which, I feel, is also > >clearer > >to regular C programmers. > > Eh, if we have one, may as well have the other, although this one seems > simple enough. STRING_IS_NULL() might not mean !s !s can only mean !s That's why I don't like it. > >Clearly 5 years isn't a rapid learning curve. > > And one of the major reasons I don't want to even look at the perl5 > source to find the code I'm wanting. Plus the documentation of the > code isn't great last I saw(like where's the definition of what SvPVNL > is?). Parrot does have a couple flaws for finding struct definitions, man perlapi. Or it's not documented. But probably last you looked it wasn't documented - there has been work in this area. Nicholas Clark