return result with it

[monte]

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

[monte]

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>...

[LCMark]

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]

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?

[mwieder]

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]

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.

[LCMark]

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]

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.

[monte]

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.

[monte]

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.

[LCMark]

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]

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]

Hmm... how could we change dispatch so substantially at this point?

[LCMark]

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]

OK, as long as I don't have to write the docs explaining the difference then I'm ok with it