HTML5 deployment: progress comes into sight

[Mark Waddingham]

On 2017-05-31 23:13, hh via use-livecode wrote:
> Call, send , dispatch, do script ...
> It is very impressive how the core team can still have all that
> messaging in mind while developing LC Builder.

The problem here is what syntax to use in LCS to 'call into a widget' - 
widget's need to be able to expose public handlers which can be called 
from LiveCode Script (not just properties and events).

> Now why not use kind of a mnemonic naming in LCB e.g.
> 
>    sendHandler <handler> <to object>
>    callHandler <handler> <of object>
>    dispatchHandler <handler> <of object>
>    doHandler <handler> <of object>?

The problem is that all the keywords (naturally) associated with 
'calling' something in another context are already taken (i.e. send, 
call, dispatch, do) and their context is the script of the object. So:

    call "foo" in widget 1

Means send the message 'foo' to the *LiveCode Script* side of the widget 
- it is not entirely clear how that could work to mean 'call the handler 
'foo' exported by the widget's implementation'.

I've pondered 'invoke' as a new keyword - but I'm not sure how much I 
like that, but it would 'fill the gap'.

The other way to slice and dice things is to make it so that any 
handlers you want to export to act on the widget internally are added as 
'library handlers'. e.g.

   widget foo
     public handler CopySpecial() returns nothing
       ... do magic stuff ...
     end handler
   end widget

Would export fooCopySpecial() as a function accessible from LCS where 
you can do:

    fooCopySpecial(the long id of widget 1, ...)

Or similar. This is closer to how the engine does syntax - which are all 
non-object based functions in C++, which then dispatch to the object. 
e.g.

    copy widget 1

Ends up calling a C++ function:

    MCInterfaceExecCopyControl(ctxt, ptr-to-widget-1)

Which then does:

    ptr-to-widget-1->copy()

> We could still have
> 
>    do <script> <in object> [as language]
> 
> the default for a browser widget being "as javascript".
> Could be used parallel to
>    doHandler <handler> of <browser widget>
> (where <handler> has to be a javascript function name).

This would almost fix the 'overloading' problem of 'do in <browser 
widget>'. If we require you to do:

    do X in <browser widget> as javascript

If you want to execute the code fragment *inside* the browser widget; 
then that means:

   do X in <control>

Could be taken to mean execute X as LCS in the context of <control>.

Anyway, a bit more to think on here :)

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps