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@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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to