Array literals and script only stack initialization (was Re: Developing first on android)

[Mark Waddingham]

On 2017-08-21 12:06, Monte Goulding via use-livecode wrote:
>> On 21 Aug 2017, at 7:58 pm, Mark Waddingham via use-livecode 
>> <use-livecode at lists.runrev.com> wrote:
>> 
>> I think its been suggested before that a 'loadStack' message might be 
>> quite useful (perhaps it should be 'createStack' - we have 
>> 'deleteStack' which is probably sufficient for the antonym) - allowing 
>> a stack to 'do something' when it is loaded into memory, and then 
>> unloaded (equivalent to OnCreate / OnDestroy in LCB) as 
>> loading/unloading is a slightly different part of the life-cycle 
>> compared to opening and closing.
> 
> @LCMark I feel bad snipping discussion of the array literals because…
> AWESOME!!!  but I actually only wanted to comment on `createStack`
> feelign a bit wrong if we also have `newStack` and the `create stack`
> command would send `newStack` not `createStack`.. or maybe it would
> send both but you can see why I have an issue with it ;-)

Heh! That post was perhaps a bit 'thick' on content. The literals stuff 
probably should have got its own thread - they are pretty cool, the 
extra symbols needed are irksome but (just like with strings) I think 
resigning ourselves to the fact that different bracket types (in 
particular) are the best way to represent (in text) hierarchical data is 
just something we will have to do.

Back to the point of your post... I see what you mean about 'newStack' / 
'deleteStack' - I had a similar thought whilst writing the email. Too 
many messages and it will just get confusing, too few and its not 
flexible enough. However, it might be we do need a new pair of messages 
here, and clarify precisely what the existing and new ones are for.

Of course, we also have the 'lock messages' issue - something which 
increasingly makes me wonder whether the message path is being 
'overloaded' in use. It works very very well for events which you might 
want to 'bubble'; but I'm becoming increasingly convinced that is not 
quite right for (1) things which are related to a specific object (e.g. 
life-cycle messages); (2) libraries. [ There's a whole corollary here 
with being able to call methods 'inside' widgets here too - the 'do ... 
in widget' problem; it is a similar if not quite the same ].

Anyway, the latter is a somewhat large thought-project in and of itself. 
Certainly there are aspects of LCB which I think work better where the 
message path is very much a separate thing which widgets use (but aren't 
strictly a part of); but on the other hand there are issues still with 
integrating widgets into the message path (mouse messages and such).

So, in the short term, if there is an extra message-path message which 
*would* help make script-only-stacks more flexible, then we should 
perhaps seriously consider it - if we can make it tasteful enough!

Of course, another approach here is to keep script only stacks as they 
are (the header uses 'script' for a reason) - and then have a different 
form for objects which is a text serialization of *core* properties and 
script:

   stack "MyStack"

   set property behavior is ...

   set property title is ...

   on openStack
   end openStack

Or something (I just came up with that off the top of my head - so needs 
'reading between the lines' of the intent). With array properties, 
hierarchical properties could also be set.

As with any text-based representation of stackfiles, custom properties 
cause a significant problem here which is why I suggest that only core 
persistent properties should be allowed. So, even with this kind of form 
you'd still need a way to init them, which takes us back to the adding a 
message which allows such init - and then the need for 'stack ...' type 
script only stacks reduces - it is entirely equivalent to just having 
code in that init message which uses literals to init properties. 
Anything like the above just becomes 'syntactic sugar'.

In terms of language design, we need to be careful to ensure that 
anything you can do with 'syntactic sugar' does have a code-based 
equivalent - the latter coming first. The reason here is that it means 
that there is no engine 'magic', it can all be done in script; and the 
more engine 'magic' which is de-magicised, the more script can do.

Warmest Regards,

Mark.

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