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
