return result with it

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, LCMark

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

return result with it

Post by monte » Wed Nov 06, 2013 9:43 am

Hi

I was thinking of implementing return result with it so you can set it and the result from a command easily, however, it looks like someone hacked some undocumented stuff in there for libURL so without changing libURL it wouldn't be possible to accept it. libURL seems to use:
return <result> with <something>
return <result> with url <something>
return <result> with cachedURL <something>

All three appear to set the url result so perhaps the namespace can be cleaned up to allow return <result> with <something> to set it to <something>?

Cheers

Monte
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: return result with it

Post by monte » Wed Nov 06, 2013 10:00 am

It appears "return <result> with <something>" is almost exclusively used for the MC 2.4.1 engine... perhaps libURL doesn't need to support that engine any more? At least not new versions of libURL? That would nearly free it up but there are quire a number of return whatever with empty in libURL that would need to be changed to return whatever with url empty or just drop the with empty if it's not really needed... perhaps all cases that set the url result could use:
return <result> with urlResult <result>...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1097
Joined: Thu Apr 11, 2013 11:27 am

Re: return result with it

Post by LCMark » Wed Nov 06, 2013 8:47 pm

I think we can safely remove the 2.4.1 engine 'ifs' in liburl now :)

This has long been on the cards, but we've never gotten around to it - something related came up today with the ongoing work on the refactor project... Really 'it' should always be there and be part of the context that flows as commands and handlers are executed, but at the moment it is only created if a command that uses 'it' is parsed when a handler is. With that, I guess the best way to implement it would be to add a reference to the calling ExecPoint in MCExecPoint, so that the return command could store the value there.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: return result with it

Post by monte » Wed Nov 06, 2013 11:07 pm

Ah... yes ofcourse... setting it on that exec point would be pointless... adding the parent exec point would make implementing the caller trivial too... Could we get it by just using MCnexecutioncontexts-1?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3263
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: return result with it

Post by mwieder » Thu Nov 07, 2013 2:04 am

Really 'it' should always be there and be part of the context that flows as commands and handlers are executed, but at the moment it is only created if a command that uses 'it' is parsed when a handler is.
Indeed. And the compilation errors that happen when you try to get "it" and the compiler disagrees are quite non-intuitive.

trevordevore
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1005
Joined: Sat Apr 08, 2006 3:06 pm
Location: Overland Park, Kansas
Contact:

Re: return result with it

Post by trevordevore » Thu Nov 07, 2013 2:38 pm

I was thinking of implementing return result with it so you can set it and the result from a command easily
Thank you! I know I've been wanting this for a long time (I can finally get rid of my executionContexts hack).

I assume the 'it' value would be lost if you use 'dispatch'? A note should probably be made in the docs so that people are aware.
Trevor DeVore
ScreenSteps - https://www.screensteps.com

LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1097
Joined: Thu Apr 11, 2013 11:27 am

Re: return result with it

Post by LCMark » Thu Nov 07, 2013 2:42 pm

Could we get it by just using MCnexecutioncontexts-1?
That should work - yes.
I assume the 'it' value would be lost if you use 'dispatch'? A note should probably be made in the docs so that people are aware.
How vexing - that hadn't occurred to me. I wonder if there's a solution to that - any thoughts?

trevordevore
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1005
Joined: Sat Apr 08, 2006 3:06 pm
Location: Overland Park, Kansas
Contact:

Re: return result with it

Post by trevordevore » Thu Nov 07, 2013 3:09 pm

How vexing - that hadn't occurred to me. I wonder if there's a solution to that - any thoughts?
'the real it'. Can only be used by those daring enough to use 'this me'.

I can't think of a good solution that uses 'the result' and 'it' given the current behavior of 'dispatch'. From a functionality standpoint I'm okay with dispatch eating 'it' as I always use 'the result' and 'it' in libraries that are available in the message path. From a language standpoint I don't really like the fact that using dispatch would override the data returned by the command being called.

If we go back to why someone might want to use 'the result' and 'it' then perhaps we can find a different solution?

My use of 'the result' and 'it' in my own libraries is to return an error message (the result) and data (it). I often use this technique with commands that make calls to the internet or to databases. Both are situations where there is potential for an error to occur while retrieving the desired data.

What are the other use cases for 'the result' and 'it'?

If the primary use is error reporting then what other options exist?

* Returning the error in 'the result' and getting data via a parameter that is passed by reference (or vice versa).
* Using throw with any and all errors.

Personally I don't like either of the above options. Perhaps another approach would be the addition of an error object? The developer could push errors onto the error object so that multiple errors could be represented and returned to the caller. This would leave 'the result' for the actual data that a command returns.

Code: Select all

put "you forgot your username" into the errors
put "you forgot your address as well" after the errors
put "did you actually read the directions?" after the errors

repeat for each error theError in the errors
    # report each error to the user
end repeat
I guess one potential problem with my suggestion above is that 'the result' is already used for error reporting in lots of commands. In any case, some thoughts to get things started.
Trevor DeVore
ScreenSteps - https://www.screensteps.com

LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: return result with it

Post by monte » Thu Nov 07, 2013 8:42 pm

I suspect it's too late to change dispatch to have a dispatchResult to avoid the conflict. Could we add syntax to dispatch to set a variable to whatever it would be?

Code: Select all

dispatch [function] <handlerName> to <objectReference> [with <params>] [into <ItVar>]
I couldn't really think of good syntax obviously... perhaps it just doesn't work for dispatch. I think Trevor is right that most use cases for this will be in the message path. If not then there's always other means like sending callbacks or passing parameters by reference.

Ah... error reporting... I think my head would hurt if we added yet another way to handle errors... If the result could consistently be used for errors and it could consistently be used for data then it would clean error reporting up significantly.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: return result with it

Post by monte » Thu Nov 07, 2013 9:59 pm

Should return with it only work in a command? The use of get confuses things here. For functions it would be nice if the value could be distinct from the result so return with would set the value and result. That way even from a function you can use the result for error/status reporting. It doesn't seem very LiveCodish for a function to set it without using get.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1097
Joined: Thu Apr 11, 2013 11:27 am

Re: return result with it

Post by LCMark » Fri Nov 08, 2013 1:36 pm

Should return with it only work in a command? The use of get confuses things here. For functions it would be nice if the value could be distinct from the result so return with would set the value and result. That way even from a function you can use the result for error/status reporting. It doesn't seem very LiveCodish for a function to set it without using get.
Yes - no functions set 'it' currently, so I think that it makes sense to only have it work for commands.

Whilst there is possibility to use 'return ... with ...' value to make functions both set the return value and the result I do wonder whether that is wise. The problem is that it is really confusing for functions to return two values - i have a hunch that if you look at all the function in the engine that do set 'the result', then they would be better posed as commands, or throw the error. Additionally, if functions are able to set the result, then it ends up meaning you can easily lose error results:

Code: Select all

put funcWhichSetsResult() && funcWhichSetsResult()
Which I'm not sure is something which should be actively encouraged (after all, you end up just having to rewrite the code when you get a bug reported about it, and the rewrite would end up being the same as if funcWhichSetsResult() had been a command in the first place).

Code: Select all

I suspect it's too late to change dispatch to have a dispatchResult to avoid the conflict. Could we add syntax to dispatch to set a variable to whatever it would be?
I think there might be something in that suggestion:

Code: Select all

dispatch [function] <handlerName> to <objectReference> [with <params>] into <resultVar>
This would send the message, <resultVar> would contain the value of 'the result' after execution for commands, and the return value for functions. Then 'the result' would be handled/not handled etc. This would mean there is no need for dispatch to touch 'it' - 'it' would be whatever the (command) handler set it to, assuming it used the 'with' form. Note that this idea doesn't work if we do let function handlers return a value and set the result.
Ah... error reporting... I think my head would hurt if we added yet another way to handle errors... If the result could consistently be used for errors and it could consistently be used for data then it would clean error reporting up significantly.
Error handling has always irked me in LiveCode - it is somewhat inconsistent and quite low-level. I'm sure there is a fair bit that could be done to improve matters (to make coding more robust and easier) - however I must confess I had put off having any deep thoughts about it until the refactoring we are currently doing is done...

Anyway, I'm current taking a look at how it is referenced and stored in the engine (as it needs to be done for the refactor project) - once that's sorted 'return ... with ...' should be easy enough to do...

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1097
Joined: Thu Apr 11, 2013 11:27 am

Re: return result with it

Post by LCMark » Fri Nov 08, 2013 2:34 pm

Anyway, I'm current taking a look at how it is referenced and stored in the engine (as it needs to be done for the refactor project) - once that's sorted 'return ... with ...' should be easy enough to do...
Just finished doing this - the branch is 'refactor-it' in the livecode repo. The 'it' variable is now accessed with MCExecPoint::getit(), and all places that referenced it have had their 'it' varref's removed, and updated to use ep.getit() instead.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: return result with it

Post by monte » Fri Nov 08, 2013 8:15 pm

Hmm... how could we change dispatch so substantially at this point?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1097
Joined: Thu Apr 11, 2013 11:27 am

Re: return result with it

Post by LCMark » Fri Nov 08, 2013 9:02 pm

Hmm... how could we change dispatch so substantially at this point?
We wouldn't be - at the moment you get the value returned from the command/function in 'the result' and extended info about the handling in 'it'. That doesn't need to change - if you use the current form, you lose the value of it...

If you use the new form (with into <container> ... or something similar), then you get the new behavior. 'dispatch' won't touch 'it', 'the result' will be the result of the send ('handled', 'not handled' etc.) [ which perhaps makes more sense than now ], and the return value of the command/function handler that is invoked would be placed into the specified target container.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: return result with it

Post by monte » Fri Nov 08, 2013 9:52 pm

OK, as long as I don't have to write the docs explaining the difference then I'm ok with it ;-)
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Post Reply

Return to “Engine Contributors”