On 2017-07-04 17:39, Ben Rubinstein via use-livecode wrote:
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?
http://quality.livecode.com/show_bug.cgi?id=8945
It is no longer a hijack - I've changed the name of the thread :)
(Although I have hijacked your original post by rewriting the content
slightly - I hope you don't mind too much!)
The underlying problem here is that whether or not an argument passed to
a handler is treated 'by value' or 'by reference' is determined by the
handler at the point it is invoked - not at the point it is called
(remember that the message path means that one call can end up invoking
several handlers as it passes through the message path).
This is the only way it can work at the moment because LiveCode Script
does not require you to explicitly mark arguments that should be passed
by reference - without that bit of information, the only thing you have
to 'trust' is whether '@' is present in the signature of the parameter
in the handler definition *when that handler is actually executed*.
Ben's suggestion (which I think is a really good one - even though I've
not commented on it at all up until now - including the original
enhancement request) is that we use '@' as an explicit marker for
whether an argument should be passed by reference.
I can think of at least one other language which has a similar thing -
C#. C# has both by-ref and by-value - and it requires 'ref' to be used
on arguments to method parameters which are 'by-ref'. It requires this
because C# allows method overloading - you can have two methods in a
class with the same name as long as their parameters are different:
class RefOverloadExample
{
public void SampleMethod(int i) { }
public void SampleMethod(ref int i) { }
}
Because C# requires 'ref' on arguments it can disambiguate the call to
'SampleMethod' - SampleMethod(tFoo), SampleMethod(ref tFoo).
[ For more details about this see
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref
]
The weak form of the proposal would not require @ before arguments to
reference parameters, but would require that it is not present before
arguments to value parameters:
command myHandler @xRef, pValue
end myHandler
myHandler tRefVar, tValueVar - fine
myHandler @tRefVar, tValueVar - fine
myHandler [@]tRefVar, @tValueVar - not fine: passing tValueVar by
reference to by-value parameter
The strong form of the proposal would require @ before arguments to
reference parameters:
command myHandler @xRef, pValue
end myHandler
myHandler tRefVar, tValueVar - not fine: passing tRefVar by value to
by-ref parameter
myHandler @tRefVar, tValueVar - fine
The weak form would still allow you to make the 'accidentally passing
the wrong argument to a reference parameter' coding fault, but at least
if you used @ consistently then it would catch the 'passing the wrong
argument to a value parameter' coding fault. The strong form would
eliminate ref-parameter related coding faults entirely.
Even in its weak form, there are a few other fringe benefits:
- we could allow @<literal> to mean: I know this is a by-ref
parameter, but I don't care about what it gets changed to, I just want
it to be <literal> on input
- we could allow 'put x into param(y)' if the y'th argument was marked
with '@'
- if @ is used consistently then it solves the mismatched reference
parameter markings in the message path problem:
group: on myHandler @isRef
card: on myHandler isRef -- oops, I forgot the '@'
There is a very low risk, in my view, of breaking backwards
Ignoring lexical issues (i.e. @ being allowed in an identifier - which
is only the case because of the way the parameter list of handlers is
parsed - ick!), then the weak form has no backwards-compatibility issues
as far as I can see.
In terms of the lexical issue, then the change would mean that '@' would
become a self-delimiting token - and not be allowed in identifiers.
I can't imagine there is any reasonable code out there which uses '@' in
identifiers, a bit like "'" is also allowed in identifiers - so changing
that is probably 'completely' safe. Indeed, we are already considering
removing various characters from the definition of identifier to allow a
little more flexibility in the symbols we can use (not that I
particularly want to add that many symbols, however I fear that adding a
few more is unavoidable if we want to keep the language ergonomic).
My general feeling is that the weak form is much better than we have
now, but the strong form is actually how things should be. Indeed, as
'by-ref' is a more complicated concept in many ways than 'by-value' it
seems fitting that it should be explicitly marked - especially as if we
were able to move to the strong form, we would eliminate the by-ref
related coding faults - at least insofar as getting a runtime error when
we make a mistake (if not a compile-time error - which we could only do
for private handlers due to the dynamic nature of the message path).
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
