Comparison operators...

[admin]

I just uploaded a new beta with the following change note:

Code: Select all

    * Scripting, ternary conditionals:
      NOTE: To prevent ambiguities with XY internal variables 
      (<curpath>, <xyver>...) the comparison operators must be 
      surrounded by blanks!

This is necessary to make stuff like this work:

Code: Select all

::$minver="7.60.0009"; assert <xyver> >= $minver,
          "This script needs at least XY $minver!"

However, now I might have a better idea (and remove the enforcement of surrounding blanks which is not so nice...): New syntax rule: XY internal variables must be inside double quoted strings by law! Or more simply put: XY internal variables are literal strings! Reason: They are not "real variables" (things like $a...) from the perspective of the script, but some hardcoded magic applied to strings.

So the above example should be rewritten like this (resp. could be if I'd remove the surrounding blanks rule):

Code: Select all

::$minver="7.60.0009"; assert "<xyver>">=$minver,
          "This script needs at least XY $minver!"

and comparison operators will work fine without surrounding blanks!

Good thinking?

[jacky]

Well, I don't like that idea.

I don't like the idea of having to put XY vars into quotes, because while you say they're not "real" variables but "literal strings" I would disagree, or don't like the idea at all. Plus, that means what: ::msg 'This is XY <xyver> = '."<xyver>"; ?? Really !?

I don't like the idea to start singling out XY vars, because then "variables" as a general term doesn't mean the same thing whether it's a user var or an XY var, which will certainly lead to confusion at some point. Plus, what about Environment variables ?

I don't see having to put spaces around the comparison operators as such a bad thing, at all, in fact it makes thing much better/easier to read anyways, so it's a win-win Anyways, in my opinion, if you really want to get ride of the required spaces, fine, but you should do it without enforcing anything else...

[admin]

Well, I don't like that idea.

I don't like the idea of having to put XY vars into quotes, because while you say they're not "real" variables but "literal strings" I would disagree, or don't like the idea at all. Plus, that means what: ::msg 'This is XY <xyver> = '."<xyver>"; ?? Really !?

What's the problem? Looks good to me:

Code: Select all

::msg "This is XY " . '<xyver>' . " = <xyver>";

Yes, environment vars would be just the same: literal strings. The scripting engine passes them to some non-scripting module which will do the replacements.

[jacky]

What's the problem? Looks good to me:

Code: Select all

::msg "This is XY " . '<xyver>' . " = <xyver>";

Sure, so could be

Code: Select all

::msg 'This is XY <xyver> = '."<xyver>";

But doesn't change the fact that having to do that doesn't really sound good, when it means this wouldn't work anymore:

Code: Select all

::msg 'This is XY <xyver> = '.<xyver>;

I mean, plus all that to gain what? Why couldn't XY deal with this properly:

Code: Select all

  $minver="7.60.0009";
  assert <xyver>>=$minver, "This script needs at least XY $minver!";

<xyver> is an XY variable, but ">" alone is nothing, neither is "<", why the need for anything?

And really, if anything I would enforce that all strings must be quoted, not to say that now some variables aren't really variables and must be quoted. What I mean is, this doesn't shock me:

Code: Select all

set $path, <curpath>;
$path = <curpath>;

However, this does:

Code: Select all

set $foo, Current path is <curpath>;
$foo = Current path is <curpath>;

Plus, that's really not a good way to do things, cause soon you'll use a "." or a ";" or something that will break everything and you'll wonder why.

Which is why I personally would do this

Code: Select all

// one var to another
set $path, <curpath>;

but this

Code: Select all

// string involved
set $path, "<curpath>\";

And if anything I say enforce the rule that strings must be quoted, but not that some variables are now literal strings and must be quoted -- double-quoted that is, cause single-quotes won't do the trick, because they're not variables but literal strings, only there's string & string... or something

[admin]

Looks like I found a way to solve the ambiguity by other means.

[PeterH]

Looks like I found a way to solve the ambiguity by other means.

Good to hear that - I'm with jacky: don't like to call "(internal) variables" "strings"...

But: is it here where you break the idea of refering to PHP-rules - when talking about names of predefined or internal variables? "some hardcoded magic applied to strings", as you call them
As far as I lerned from PHP doku, PHP reserves variable names $_... as internal names - so wouldn't it be correct to use such names for XY-internal variables, too? So <xyver> would be $_xyver (or $_XYver?), and so on? And it seems, $_xy... (or $_XY...) is unique with respect to other PHP-internal varnames, I'd expect? But for <curpath> you had to decide: $_curpath or $_XYcurpath? (XYcurpath means: the XY-var curpath)

Seems this relates somehow to environment vars, too. But couldn't find, how PHP does this?

[admin]

Looks like I found a way to solve the ambiguity by other means.

Good to hear that - I'm with jacky: don't like to call "(internal) variables" "strings"...

But: is it here where you break the idea of refering to PHP-rules - when talking about names of predefined or internal variables? "some hardcoded magic applied to strings", as you call them
As far as I lerned from PHP doku, PHP reserves variable names $_... as internal names - so wouldn't it be correct to use such names for XY-internal variables, too? So <xyver> would be $_xyver (or $_XYver?), and so on? And it seems, $_xy... (or $_XY...) is unique with respect to other PHP-internal varnames, I'd expect? But for <curpath> you had to decide: $_curpath or $_XYcurpath? (XYcurpath means: the XY-var curpath)

Seems this relates somehow to environment vars, too. But couldn't find, how PHP does this?

At the moment this is not necessary. Less work for me and for you.