synonyms

Ben Rubinstein benr_mc at cogapp.com
Tue Jul 4 17:39:42 CEST 2017


On 04/07/2017 09:18, Mark Waddingham via use-livecode wrote:
> Syntax is just sugar - you need to implement the feature at all levels 
> underneath for it to work... Like most things (unfortunately), there's usually 
> a great deal of depth involved - usually directly proportional to the 
> generality of the change... In this case (as it is dealing with parameter 
> passing) it is quite general indeed.

May I hijack this thread to have another go at promoting my feature request 
for a bit of syntax sugar around parameters which I _think_ would not have a 
very deep implementation requirement?

My (initial) request is for "@" to be ignored - treated as "/* @ */" - at the 
start of a parameter in a command or function call.

It seems to me a significant risk of error that it's possible to invoke a 
command or function which takes a parameter by reference, without realising 
it. Certainly it's not an aid to readability that, when looking at code that 
makes such a call, there's no clue that this is what is happening.

A change that ensured "@' is effectively ignored immediately before a 
parameter, would at least give the careful coder an elegant and concise way of 
indicating in the code that this parameter is passed by reference. Of course, 
my long term plan is that in five years or so the compiler might (at least in 
explicitVars mode) actually warn you if the @ marking is inconsistent between 
caller and callee.

There is a very low risk, in my view, of breaking backwards compatibility. At 
present, if you have explicitVars set, you cannot use @ in this way - it is an 
error. If you don't have explicitVars set, then with this code
	put 23 into x
	mycommand @x

mycommand would currently receive "@x" as the parameter, but after my 
suggested change would receive "23". That would be bad. But what kind of 
person would do the above anyway?!?

Arguably it would be possible to process @ in this way only when explicitVars 
was set, in which case there would be no incompatibility issues at all.

This is also at:
http://quality.livecode.com/show_bug.cgi?id=8945

cheers,

Ben



More information about the use-livecode mailing list