> > OK, I can understand this from the parser point of view. How about
> > the functions themselves? Is it realistic to allow variable and
> > property names to contain leading and trailing spaces?
>
> Why not?
Because spaces in these fields are not completely obvious in the
configuration dial
On 08/05/2008, Michael Giroux <[EMAIL PROTECTED]> wrote:
> > The documentation may not make clear that all spaces are significant,
> > but equally it does not say that leading and trailing spaces are
> > ignored.
>
>
> My expectation was that spaces were ignored. If this is not the case,
> it w
> The documentation may not make clear that all spaces are significant,
> but equally it does not say that leading and trailing spaces are
> ignored.
My expectation was that spaces were ignored. If this is not the case,
it would be handy to make that point clear in the docs.
> > Is there a reas
2008/5/7 Michael Giroux <[EMAIL PROTECTED]>:
> I used __setProperty and included some spaces for readability.
>
> ex. __setProperty( name, ${varName} )
>
> Later in the test when I referenced __P(name) I got a value of '1' as
> if the property was not defined.
>
Because you defined a diff
I used __setProperty and included some spaces for readability.
ex. __setProperty( name, ${varName} )
Later in the test when I referenced __P(name) I got a value of '1' as
if the property was not defined.
This seems like a bug in the parser to me. Is there a reason that the
parser did not
5 matches
Mail list logo
