Re: Bug in new get()?
Jason Gade wrote:
>
> Okay, I'm writing a stub to test your new get.e with regards to sanity.ex, so
> I can fix sanity.ex.
>
> And I'm looking at your docs. I don't quite understand them and I have a
> change
> suggestion.
>
> Your docs say:
> get() returns a 4 element sequence, like value() does:
> a status code (success/error/end of file),
> the value just read (meaningful only when the status code is
> GET_SUCCESS),
> the number of characters read,
> the number of leading whitespace characters.
>
> I'm getting a bunch of 1s, -1s, or 0s for the last two elements. In fact I'm
> not getting any other values.
>
Indeed get() had a problem which value() did not. A forgotten ! in a != test
DUH! Fixed yesterday night, will commit tonight.
> Are these really useful return values? Maybe a different function to read
> those
> last two numbers would be better (state kept in a file variable of course)?
>
I just contributed an eval library which uses it. It really simplifies some
sorts of murky coding.
> Plus your comment at the top of Get2() doesn't seem to reflect reality: you
> say that Get2() will return a 2-element sequence unless record_whitespace flag
> is set. Get2() seems to return 4 elements regardless.
The comment there was left untouched. Will change this. The docs say the right
thing though (didn't find that line 549-552 in the .htx file - which one?
>
> I would see more value in returning (in this order) "success or failure",
> "sequence
> of interest", "sequence containing invalid characters until next valid
> character
> (not read)" and "total characters read". And probably not even that, as I
> would
> prefer to see it separated from get(). get()'s pointer, of course, would point
> to the next valid character.
For the third item, you mean the exact string that was interpreted? Ok, but bear
in mind that only leading invalid stuff will be seen, only trailing comments
will. Looks good, but perhaps not consistent with the way the functions work.
>
> So the optimal situation in my opinion would be to leave get() returning a
> two-element
> sequence as now, but add get_leading_whitespace_count(), get_chars_read(), and
> get_last_invalid(). Obviously, those names suck, but the point still stands.
Do you really want to have one function for minimal things, one for this item
more, one for this item more and so on? I would vote against this sort of
evolution. Even with acceptably short names, because that's not the issue.
CChris
>
> Same for value().
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
|
Not Categorized, Please Help
|
|
