I ran into that problem with java.beans. It doesn't specify a lot of
stuff it needs to. I ended up just making it compatible with Sun's by
comparing their output with mine and guessing (using the scientific method)
what it did.
I find that the hardest part of writing the classes is the beginning.
I suggest you write it to what you believe makes the most sense, compare
your output to Sun's in a test, and modify appropriately, checking
especially in places where the spec is broken.
In other words, Do What You Think Is Right, Until You Hear Otherwise.
:)
Is / really an alpha character? Doesn't it define what alpha
characters are?
--John Keiser
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron
> M. Renn
> Sent: Monday, August 03, 1998 9:03 PM
> To: [EMAIL PROTECTED]
> Subject: Broken Specs
>
>
> What if the spec seems to be broken? I'm thinking of the supremely brain
> dead StreamTokenizer. It lists various strategies for parsing,
> but doesn't
> say what order they should be applied in (other than white space
> is skipped
> first) except that I guess we could assume that we should apply
> the criteria
> in order (which looks wrong) or what should be done if conflict is
> encountered.
>
> First, there are five character attributes. The spec says a character can
> have more than one attribute, but says nothing about the
> precedence they the
> various attributes have. For example, words are terminated by the first
> non-alpha/non-numeric char encountered. This (from the example) seems to
> imply that a whitespace char terminated the word. But what if the
> whitespace char is also an alpha char?
>
> Second, then the parsing criteria states to do the following,
> though not the
> order. This is the order the JLS lists them in though.
>
> -- Skip whitepace (explicitly stated as the first thing to do)
> -- Check numeric
> -- Check alpha
> -- Check comment
> -- Check quote
> -- Check C++ comment
> -- Check C comment
> -- Default
>
> Even if a given character can only have one attribute, the spec
> still seems
> broke from what I can tell. For example, a word (alpha) token is
> terminated
> by the first non-alpha token. But if C++ comments are enabled, then "//"
> might not terminate the word, but instead would be included as part of the
> word. Ditto for "/*" (C style comments). That probably isn't
> what the user
> expected.
>
> Any insights?
>
> --
> *****************************************************
> * Aaron M. Renn *
> * Email: [EMAIL PROTECTED] *
> * Homepage: <URL:http://www.urbanophile.com/arenn/> *
> *****************************************************
>
>
