Hugh Senior wrote:
Agreed... Leave the existing behaviour alone.
It is not a bug but an undocumented feature. And yes, it will break
at least one of my products if changed!
When I submitted the request to the bug DB I'd hoped for either a fix or
an explanation, whichever the engine team
Agreed... Leave the existing behaviour alone.
It is not a bug but an undocumented feature. And yes, it will break at least
one of my products if changed!
This issue has already been discussed some time ago. It was determined to
leave the behaviour unchanged for both flexibility and backwards
Definitely bug. This is incorrect behaviour.
On 15/11/2014, at 12:00 PM, use-livecode-requ...@lists.runrev.com wrote:
On 11/14/2014, 5:28 PM, Bob Sneidar wrote:
I guess what I am saying is that since test1 did not*explicitly*
return anything, the mouseUp handler should put nothing in the
J. Landman Gay wrote:
I'm trying to understand how it follows any known rule of messaging.
I don't see it yet. To me it looks like a bug.
Agreed - reported as such:
http://quality.runrev.com/show_bug.cgi?id=14034
We'll either get a fix or an explanation; either would be useful.
--
Richard
Jacque-
Friday, November 14, 2014, 5:46:08 PM, you wrote:
On 11/14/2014, 5:28 PM, Bob Sneidar wrote:
I guess what I am saying is that since test1 did not*explicitly*
return anything, the mouseUp handler should put nothing in the
message box. However I am discovering that
Assuming that this has been the behaviour of Metacard, Revolution, Livecode
(and possibly Hypercard) for 22 years (or more), it is perhaps best just
accepted as a fait accompli. If no-one has noticed this aberrant
behaviour in those 2 (or more decades), then fixing it now might well lead
to
On 11/15/2014, 11:55 AM, Mark Wieder wrote:
I've only followed this thread sporadically because it's been a busy
week at work, but I'm quite amused. This is the way ruby works, and if
memory serves, go works the same way. The last statement executed is
the current result.
That's what I get for
Jacque-
Saturday, November 15, 2014, 10:44:33 AM, you wrote:
That's what I get for being a one-trick pony. But it sure seems that
having to keep track of the last result would cause a lot of non-obvious
errors.
I'm not necessarily saying I like it, I've just gotten used to it in
ruby because
On 11/15/2014, 3:43 PM, Mark Wieder wrote:
What I'd like in LC is for the
compiler to barf if a function has no return statement, or if it has a
return statment with no returned parameter.
I like it. Then we wouldn't have all those multi-lingual LiveCoders
using return instead of exit. :)
On Sun, Nov 16, 2014 at 2:44 AM, J. Landman Gay jac...@hyperactivesw.com
wrote:
That's what I get for being a one-trick pony. But it sure seems that having
to keep track of the last result would cause a lot of non-obvious errors.
Bernard mentioned it might be long-standing behavior that
Also from the Dictionary entry for return:
To halt the current handler without returning a result, use the exit
control structure instead.
On Sun, Nov 16, 2014 at 8:01 AM, Kay C Lan lan.kc.macm...@gmail.com wrote:
On Sun, Nov 16, 2014 at 2:44 AM, J. Landman Gay jac...@hyperactivesw.com
wrote:
By accident I noticed that I don't have a return at a certain point of a
function but nevertheless the value was passed back without a return to the
calling handler.
I can reproduce the issue to this scenario:
--Btn script
on mouseUp
put foo1() into myVar1 -- I get the value Test
Interesting. If I modify foo1 like that:
function foo1
put foo2() into myvar2
put anotherTest into myvar3
end foo1
the process still returns “Test”.
I can only guess that ‘return’ saves the returned value in a ‘last in, first
out’ pile somewhere and that the top value is used by the
-Original Message-
From: Tiemo Hollmann TB toolb...@kestner.de
To: 'How to use LiveCode' use-livecode@lists.runrev.com
Sent: Fri, Nov 14, 2014 3:47 am
Subject: how are variables passed from functions?
By accident I noticed that I don't have a return at a certain point of a
function but nevertheless
Gesendet: Freitag, 14. November 2014 16:12
An: use-livecode@lists.runrev.com
Betreff: Re: how are variables passed from functions?
I don't see any anomaly here. Since the intermediate function calls yet
another function, it never needs to close, that is, return, a value. It
is a
pass-through
of these intermediate
handlers.
Craig
-Original Message-
From: Tiemo Hollmann TB toolb...@kestner.de
To: 'How to use LiveCode' use-livecode@lists.runrev.com
Sent: Fri, Nov 14, 2014 10:38 am
Subject: AW: how are variables passed from functions?
Hi Craig,
I wasn't aware of this behaviour.
I
] Im Auftrag
von dunb...@aol.com
Gesendet: Freitag, 14. November 2014 17:00
An: use-livecode@lists.runrev.com
Betreff: Re: how are variables passed from functions?
Hi.
Putting intermediate returns will immediately terminate the function call. How
would you reach the next stage
Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von dunb...@aol.com
Gesendet: Freitag, 14. November 2014 17:00
An: use-livecode@lists.runrev.com
Betreff: Re: how are variables passed from functions?
Hi.
Putting intermediate returns
Tiemo,
Interesting. It looks like functions return the value of the result in the
absence of a return statement.
Other languages would probably return void or null or something similar,
and we might expect Livecode to return empty.
I've no opinion on whether it is a bug or not, but I think it
Yes, it is ’the Result’, I just checked it - good hint, Dave ! didn’t think
about that before…
Jacques
Le 14 nov. 2014 à 17:56, Dave Cragg dave.cr...@lacscentre.co.uk a écrit :
Tiemo,
Interesting. It looks like functions return the value of the result in the
absence of a return
@lists.runrev.com
Sent: Fri, Nov 14, 2014 11:21 am
Subject: AW: how are variables passed from functions?
Hi Craig,
perhaps I didn't expressed myself correct, I'm not a native speaker.
For me the result seems the same, if I put a return myVar2 at the end of
function foo1 or not (see below). The intermediate
For anything other than this simple case, the returns matter.
Take for example
local tvar1,tvar2,tvar3
on mouseUp
--get a random value to use
put random(10) into tvar1
put Start Value: tvar1 cr Final Return: myfunc1(tvar1)
cr tvar3
end mouseUp
function myfunc1 pvar
put 2 *
The value returned in the previous scenario (basing the return on 10 being
the number used) is 20. The final doubling disappears.
On Fri, Nov 14, 2014 at 10:40 AM, Mike Bonner bonnm...@gmail.com wrote:
For anything other than this simple case, the returns matter.
Take for example
local
Hi Tiemo,
That seems like an unexpected behavior to me but definitely good to know.
I've christened this behavior the point of no return!
I'm triyng to wrap my head around what might happen in this scenario with a
recursive function.
Pete
lcSQL Software http://www.lcsql.com
Home of
On 11/14/2014, 9:12 AM, dunb...@aol.com wrote:
I don't see any anomaly here. Since the intermediate function calls yet another function,
it never needs to close, that is, return, a value. It is a pass-through
entity, a card carrying member of the chain of handler calls. Step through this
Not sure what you are asking, but here is how functions work.
As soon as the script execution encounters a return command, the function
terminates and returns control to the calling handler. Nothing that comes after
the return in the function is executed.
Now here is what weirds me out:
on
I agree with you Jacque. I think the only workaround is when creating a
function, immediately enter the return command before scripting anything else.
This will prevent the inadvertent exclusion of a return command
Bob S
On Nov 14, 2014, at 10:28 , J. Landman Gay
test2
function test3
return blah3
end test3
-Original Message-
From: Bob Sneidar bobsnei...@iotecdigital.com
To: How to use LiveCode use-livecode@lists.runrev.com
Sent: Fri, Nov 14, 2014 2:36 pm
Subject: Re: how are variables passed from functions?
Not sure what you are asking
I guess what I am saying is that since test1 did not *explicitly* return
anything, the mouseUp handler should put nothing in the message box. However I
am discovering that functions *implicitly* return data that the programmer did
not tell them to return.
Some find this ok. I find it
On 11/14/2014, 5:28 PM, Bob Sneidar wrote:
I guess what I am saying is that since test1 did not*explicitly*
return anything, the mouseUp handler should put nothing in the
message box. However I am discovering that functions*implicitly*
return data that the programmer did not tell them to return.
30 matches
Mail list logo