clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   If a color is expected but a string is found instead, then that string
> > could be interpreted as a color definition in HTML (or other similar)
> > syntax.
> > 
> >   In other words, where you would normally write eg:
> > 
> >     rgb <.5, .75, 1>
> > 
> > you can write instead:
> > 
> >     "#7FBFFF"

> I don't like this one, because it adds some stuff (the quotes) which 
> shouldn't be necessary in an ideal world.

  The quotes allow putting there more than just a hex value prepended
with a #. You can put color names and everything else HTML supports,
plus more.

> (In addition, it might make 
> people try to use other strings there, which would open up the problem 
> of how to deal with unrecognized ones

  What kind of problem? Just give a parsing error.

> and whether only string literals 
> would be allowed or also string variables.)

  Why shouldn't variables be allowed?

> How about this - it should be perfectly safe:

> A hash sign (#) followed by six uppercase(!) hex digits could denote a 
> HTML color.

  "HTML color" can be more than just hex values. By making it a non-string
you are removing the possibility of other color definitions being used
(such as named colors).

  Besides, from an implementation point of view the string is just perfect
because there's no ambiguity: When a color is expected, if a string
expression is found instead, the string is parsed as the color. However,
having a # followed by something exceptional is only going to cause severe
problems, besides being awkard, rigid and limited.

-- 
                                                          - Warp

Post a reply to this message