FlashFXP Forums - View Single Post

DayCuts · 12-23-2014, 07:58 AM

I did notice the ordering issue but did not realize it was so extensive and forgot to mention it.

I was unaware that /echo existed, it is not listed in the help file that I could see. Though /noop would be more appropriate since the point is to prevent it being sent outside of the parser but /echo certainly suffices, thanks.

Variables was an afterthought really but for the sake of discussion is there a particular reason why %key or $var(key) would be an issue? I guess it comes down to how you parser is designed. If it allows nested 'token modifiers' (a kind of misleading name for them) then $var(localvar) could be used with minimal effort without needing much change to the parser. If not then %localvar might seem a better solution (and would comply more closely with the %globalvar form already used) but would obviously need a little error checking to avoid conflicts with global vars (or blacklist them from being used with local vars). Time/date vars shouldn't interfere because they already use a different form.

In any case would a prefix or encapsulation be needed at all for /set? wouldn't the code to process that command know that the second token on the line is the key and 3-N is the value, without the need to be told by some non-alphanumeric indicator? Again I suppose this all depends on how the parser is designed.

12-23-2014, 07:58 AM
DayCuts Senior Member Join Date: Dec 2003 Posts: 421	I did notice the ordering issue but did not realize it was so extensive and forgot to mention it. I was unaware that /echo existed, it is not listed in the help file that I could see. Though /noop would be more appropriate since the point is to prevent it being sent outside of the parser but /echo certainly suffices, thanks. Variables was an afterthought really but for the sake of discussion is there a particular reason why %key or $var(key) would be an issue? I guess it comes down to how you parser is designed. If it allows nested 'token modifiers' (a kind of misleading name for them) then $var(localvar) could be used with minimal effort without needing much change to the parser. If not then %localvar might seem a better solution (and would comply more closely with the %globalvar form already used) but would obviously need a little error checking to avoid conflicts with global vars (or blacklist them from being used with local vars). Time/date vars shouldn't interfere because they already use a different form. In any case would a prefix or encapsulation be needed at all for /set? wouldn't the code to process that command know that the second token on the line is the key and 3-N is the value, without the need to be told by some non-alphanumeric indicator? Again I suppose this all depends on how the parser is designed.