new cryptic syntax rules now approved by Nuno
Really nothing to write more, All are more clear to me now, nothing to ask, nothing to discuss .
Somehow I sense that the urge to reply will be stronger than you..
Now it is ended
Hope we can now keep the tone of this discussion to a more professional level to analyze the facts.
---------------------------------------------------------------------Context reminder from the first topic:
Why is cryptic syntax used?
Let's be professionals and express good valid arguments why each method is better in certain situations than others and possibly identify the weak points as well.
Commas and "" are some of the reserved parameters that are suggested to be encoded so that the engine can easily distinguish them.
There are wb commands where commas can be inserted without causing troubles because we know that after the first ,"
the rest of text will belong to the same parameter until the next "
Example: echo,"Hello, I'm Nuno"
However, if for some reason we use echo,"Hello, I'm "Nuno""
Then we will only get as output: "Hello, I'm
Since there are rare cases where we want to output "", this brought us the need for the #$x: echo,"Hello, I'm #$xNuno#$x"
that will output correctly Hello, I'm "Nuno"
It's not a pretty solution but if you really want to output a "" then it's a way that doesn't add too much overhead on the engine to process, otherwise we'd be left trying to guess which "" belonged to where.
---------------------------------------------------------Cryptic Syntax on the SET command
There are specific situations that drove the need for cryptic syntax. The first one appointed was the SET command because it could contain another command inside the command parameters and this was a terribly confusing situation to deal.
Using cryptic chars allows to distinguish these two parts. However, I have the opinion that the SET command should only be used to set the value of a variable. There are scripting alternatives that completely bypass the need for cryptic chars or complex notations that I will demonstrate in the last section of this topics.How this affects the SET command
To better understand this impact, I will clarify why the cryptic syntax notation became necessary for the syntax requested by Galapo
There are a few problematic details in this code.
The first is the fact that a variable is being designed with the value of another variable which in turn might have it's own set of "" wrapped inside the value.
When the interpreter evaluates the value of "Exec,%scriptfile%,test", if for example %scriptfile%
had the value of "c:\wb 080\Projects\LiveXP\test.script"
then we would have a problem because the space on the path of c:\wb 080
will forcefully require "" under windows to keep it together.
The interpreter would ultimately understand the parameter from this case as: "Exec," because the rest of the parameter got cut by the second ".
The second problem are commas. As mentioned on the "Hello" example for the echo command. It's ok if we use a comma when we know what is the length of the parameter since it will either be enclosed between "" or it's the last parameter and we'll just copy until the end of line.
However, for Galapo's example:
We don't know what is the last parameter. Since there is the risk that %scriptfile% breaks the enclosed "" and since there cases where not even "" are used to define when parameter ends and begins, we rely on commas to break the command onto it's distinct parameters. If one of the parameters contains several commas, how will we know when to stop?
Since there is the possibility to use switches in the last position, there is a huge overhead in trying to guess what is what inside the command.
Meaning that encoded chars are used once again to provide some sense on where each parameter begins and ends with a comma or possibly "", resulting in:
Galapo and Lancelot publicly expressed their dislike for the above solution and I don't think that anyone enjoys it as well.
But I hope to have explained how the above notation came to appear as necessary since it's an overly complex combination.Why are cryptic chars really needed in SET?
If we try to adopt this:
It will not work well and be vulnerable to bugs and processing overhead which I think that most people will now understand how they occur when an unknown number of "" and commas appear inside a command parameter.
This is the reason that drives the need for encoding them in the first place.
I don't like it, but it's necessary on this case.
However, keep in mind that we are talking about the usage of SET on a complex case for a purpose to which it was not originally coded for.
--------------------------------------------But how about an alternative?
Instead of fighting between a syntax prune to bugs or being forced to apply an overly complex syntax, I would propose an equivalent code that could be placed inside the script.project
file of the project:
This example had been mentioned before
, and although it's not a perfect solution, it does solve the issues associated with the processing of an overly complex syntax and is compatible with older wb versions as demonstrated on the API commands since 2007.
So, sometimes we already
had simpler ways of getting the same result that require neither SET nor cryptic syntax.
-----------------------------------Reflection about the SET command
Please let me hear your thoughts about the SET command. I think I've covered most of the reasons why and when the cryptic syntax is needed to get some sense on things.
Let's not get extremists about the use of cryptic chars and claim that a more strict syntax will look something like Echo#$cHello#$c#$sI'm#$shere!
and please don't add any more posts saying that "a hundred years ago it was written on the magical stone that cryptic chars shall not be adopted"
or something like that.
That's not our goal, we also code scripts by hand just like humans do but there are times when they're needed and there are times when you just need to use your head to simplify the code by yourself without requiring rambo syntax on wb commands..
If there are any other wb commands that are troubling your mind, let's hear them but please keep the tone of professionalism and provide valuable facts to work and find solutions.
Thank you for reading.