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
