On 2021-09-08 11:35, Andre Garzia via use-livecode wrote:
I just don't understand this one, so no comment.
As I understand, this is LC version of the “spread operator”. It
allows you to spread the elements of an array as the arguments to a
handler.
The code:
put “an...@example.com <mailto:an...@example.com>” into tDataA[1]
put “Andre Garzia” into tDataA[2]
sendEmail …tDataA
Is syntactically equivalent to:
put “an...@example.com <mailto:an...@example.com>” into tDataA[1]
put “Andre Garzia” into tDataA[2]
sendEmail tDataA[1], tDataA[2]
Which means that you can code the “sendEmail” command to have two
string arguments instead of an array, as shown below:
command sendEmail pEmail, pFullName
// send your email
end sendEmail
The spread operator will pass every array element as an argument to
the handler.
Yes - that is precisely what it is :)
It would be beneficial if this feature would also come paired a “rest
operator” that collected extra arguments in an array, so that we could
declare the “sendEmail” handler as
command sendEmail pEmail, pFullName, …pMoreArgumentsA
// stuff
end sendEmail
This way, if the call uses an array that contains more than two
elements, the remaining parameters are collected in the final
“pMoreArgumentsA” array. That if what I would like to have, LC didn’t
say anything about this but it is very common in other languages to
implement both operators at the same time.
Indeed.
The key thing here is that doing that adds to the handler signature
syntax which I'd prefer to do as part of a more substantial improvement
to the expressibility of that aspect of the language.
Therefore...
In the case of LiveCode there is an alternative though. We can use
“paramCount” and “param()” to grab the extra parameters, but that
requires us coding it while something like a “rest operator” do that
for us automatically.
The feature I omitted from the list and which does pair with the spread
(or tail) operator is a tweak to the params function... Namely:
params(N) => returns a sequence or params starting from the Nth
So in the above:
command sendEmail pEmail, pFullName
local tMoreArgumentsA
put params(3) into tMoreArgumentsA
...
end sendEmail
This is a direct evolution / useful addition to the current way existing
handlers manipulate arguments - and, more importantly, saves a blob of
code I've seen 100's of times in code which needs to forward arguments:
command foo
local tParams
repeat with i = 1 to the paramCount
put param(i) into tParams[i]
end repeat
...
end foo
Also this feature is largely orthogonal to any tweak to handler
signature (i.e. the merge operator, Andre suggests above) as it just
manipulates the parameters as defined by the signature. For example, in
the imagined case of a 'merge' clause:
command merged pFoo, pRestA...
put the paramCount into tCount -- gives 2
put param(1) into tFoo -- would give pFoo
put param(2) into tRestA - would give pRestA
end merged
Here there are two parameters - pFoo, and an (array) pRestA which
contains the rest of the parameters passed.
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
