Mark,
Thanks for this fantastic explanation of controls and objects and lots more.
I’m happy to learn that what I’ve always thought I understood is not far off
from reality. :) The definig of audioclips and videoclips as objects, not
controls, within the stack tree, cleared up one point of confusion for me. I
had always explained *clips to students as “objects that have no visual
component.”
Now as regards any fixes and changes to terminology in the docs (Guides or
dictionary API), I would be happy to help anyone who sees a confusing passage
and who would like to fix it. I have recently been doing a fair amount of work
as time permits to make improvements to the dictionary and user guides. If you
see a problem in the docs and don’t have the time to grok the Github system,
drop me a note and I’d be happy to help out.
Regards,
Devin
> On Jun 20, 2016, at 3:28 AM, Mark Waddingham <m...@livecode.com> wrote:
>
> On 2016-06-19 09:19, Richmond wrote:
>> I am currently teaching some children Livecode programming and ran
>> into some difficulty
>> on Friday when a child asked me why the menus were full of the word "Control"
>> when I had been talking about "Objects".
>> Well?
>> How about changing every use of the word "Control" to "Object"?
>
> Replying to the original post, as a lot was mentioned in this thread (it
> tries to cover most of what came up in the thread, not just this particular
> question).
>
> An object (regardless of what language it is rendered in, or with whatever
> specific kind of 'oop' methodology you care to subscribe to) is simply some
> state (i.e. variables which are distinct for each instance of the object)
> with an associated list of handlers/methods/functions which act on that
> state. (Indeed, really I think one should require that the state is entirely
> hidden and encapsulated within the object and not visible from the outside
> world - although most OOP languages do this very very poorly).
>
> In LiveCode, this is perhaps slightly hidden behind the English-like
> syntactic sugar. For example, one can imagine that:
>
> get the fooBar of myObject
>
> Is the same as (in a non English-like language):
>
> it := myObject.GetFooBar()
>
> Or something like:
>
> copy myObject
>
> Is the same as (again, in a non English-like language):
>
> myObject.Copy()
>
> Therefore, I have absolutely no hesitation in saying that LiveCode is
> object-oriented (for some definition of object-oriented). Indeed, it always
> has been - everyone who has ever programming in an xTalk had been doing
> object-oriented programming since it started to become 'popular' (HyperCard
> appeared in 1987, Cfront - the original C++ - appeared in 1985 - although the
> first 'object oriented' languages such as Simula appeared perhaps a decade
> before).
>
> The reason why I tend to hesitate saying LiveCode is object-oriented
> explicitly (well, up until 8, at least) is that the kind of way you do
> programming in LiveCode is perhaps not quite the same as what people expect
> when they hear that 'a language is object oriented'. The LiveCode model is
> essentially that of aggregation and adaptation, rather than inheritance
> (people tend to be highly aware of the later, but not aware of the former
> even though they will be implicitly doing it day-in-day-out in any
> programming language they are a practitioner of).
>
> In LiveCode, you build applications by using the building-blocks you drag
> from the control palette to build more complicated things (aggregation), and
> then you apply scripts to each object to change the behavior of the
> building-blocks appropriate to your app (adaptation).
>
> Now, inheritance is orthogonal to the idea of aggregation and adaptation -
> and it should be noted that most 'traditional' OOP languages allow you to do
> inheritance, but you have to build the framework to do aggregation and
> adaptation yourself (hence why Java, Obj-C, C++ etc. all have a large variety
> of 'frameworks' you can leverage to actually build apps - if you tried to do
> so with the 'raw' language, you'll find yourself just reinventing some sort
> of structure which is probably not too dissimilar to LiveCode's).
>
> When we added 'behaviors' you could argue that 'inheritance' did actually
> start to creep in - behaviors allow you to factor out the code which you use
> to adapt the building blocks (i.e. your scripts) into an informal hierarchy.
> (Informal here refers to the fact you don't need to make type definitions -
> which is entirely appropriate to LiveCode which tends not to force that kind
> of thing on you anywhere - except in Builder, and only then if you really
> want to).
>
> With 8, however, you can start to see the 'class inheritance' ability being
> added to LiveCode - that is what widgets are. i.e. You can write your own
> building blocks (in LiveCode Builder). (For those of you who have looked at
> Builder, then although it is not yet explicit - a module is essentially a
> class - a widget is a module which can have multiple instances and a library
> is a module which only ever has a single instance).
>
> So, right now in LiveCode, the objects you have to play with are stacks,
> cards, audioclips, videoclips, fields, buttons, scrollbars, players, images,
> buttons, groups, graphics and widgets. However, remember that 'widgets' are a
> completely extensible set of things, so this list is no longer fixed as it
> was before.
>
> To go back to the original point about controls vs objects then this is
> actually very well defined (indeed, it is embodied in the source of the
> engine - i.e. how LiveCode is actually implemented). A control is an object
> which sits on a card or in a group.
>
> Indeed, you have the following 'inheritance' hierarchy:
>
> Object
> Stack
> Card
> AudioClip
> VideoClip
> Control
> Group
> Field
> Button
> Scrollbar
> Player
> Image
> Button
> Graphic
> Widget
> <all widgets>
>
> This means that a stack is an object, but not a control. A player is a
> control, and therefore an object. AudioClips and VideoClips aren't really
> 'controls' in this sense because they sit on a stack , and not a card
> (although the Import Menu does call them so - which is perhaps the reason for
> the slight amount of confusion).
>
> At runtime, objects in LiveCode form themselves into a tree (note this tree
> is about *ownership* of instances of objects, not inheritance):
>
> Stack
> Substack
> <same as stack>
> AudioClips
> Videoclips
> Cards
> Controls
> Groups
> Controls
>
> You use LiveCode Script to attach 'adaptations' to your objects, and the
> message path allows a simple way for these adaptations to communicate.
>
> As LiveCode Script does not have 'strong references to objects' (and cannot
> have them unless we want to lose stringyness entirely - which is actually one
> of the main differences between Script and Builder) you create named objects
> in this hierarchy and then manipulate them using chunk expressions - i.e.
> references are strings describing a path in the object tree such as 'button
> "Foo" of card "Bar" of stack "Baz".
>
> Another way to think about this is that, in LiveCode Script, every object
> must have an explicit name. You use chunk expressions to select an object
> based on various criteria (type, owner). Once created, objects exist in the
> tree until they are explicitly deleted.
>
> Indeed, one of the reasons 'OOP as you see it in other languages' is very
> unlikely to appear in LiveCode Script is because there is no way to represent
> a reference to a temporary object which disappears when there are no
> references to it. As all references must be strings, and strings can sit in
> arbitrary other strings, there is no way for the engine to ever know when you
> don't need an object anymore - you have to tell it. I don't really see this
> as a limitation, however, because that is the object model of LiveCode Script
> - you adapt named instances of building blocks with your scripts!
>
> Of course, it would be nice if you could write widgets in 'LiveCode Script' -
> however, I'm not sure it is entirely appropriate. The stringy type system
> which Script has compared to Builder means that some things you really need
> to be able to do to write widgets in the way Builder does become quite
> tortuous. That being said, there is room for 'Builder' to come closer to
> 'Script' in terms of its strictness - at least as an option - i.e. Script
> without the 'everything is a string' concept.
>
> Perhaps the thing which is much more important at the Script level is the
> ability to take a collection of LiveCode objects and scripts etc. and wrap
> them up with an 'inner script' which presents them as a single black-box
> control - just like a widget. This is the idea of 'template objects', or
> custom controls 'done properly' (for some definition of properly, of course).
> This is a recursive application of the ideas which you are already familiar
> with when you build your apps and has a very nice 'self-similarity' and
> symmetry ("It's turtles all the way down").
>
> So, anyway, to sum up:
>
> 1) Objects and Controls are very well defined concepts in LiveCode and
> always have been. There might be some places in the docs and IDE, however,
> where it uses the wrong term and I that should be corrected (i.e. if you
> notice an instance of this file a report, and we'll look into correcting it).
>
> 2) LiveCode is definitely object-oriented:
>
> i) You build black-box objects in LiveCode Builder (which is, although
> not explicitly yet exposed, class-based).
>
> ii) You aggregate black-box objects together then adapt and glue them
> together using LiveCode Script.
>
> 3) LiveCode Script is designed to allow this rapid gluing and adaptation,
> and as such has a loose stringy type-system and dynamic message path to aid
> this rapidity.
>
> 4) LiveCode Builder could become less strict in the future as an option, to
> make it easier for people who are familiar with Script to write Builder to
> build widgets.
>
> 5) LiveCode Script is probably not the thing to use to write widgets, but
> the ability to be able to package up a group of controls as a black-box just
> like a widget would be entirely consistent and self-similar with the existing
> environment.
>
> The final thing which was touched on in this thread (and indeed was the point
> of it originally) was about how to teach LiveCode to kids - and I have to say
> that I'm not sure I'm qualified to actually help there! All I will say is
> that surely kids at the level you are talking about are able to reason about
> facts like:
>
> i) A Car is Vehicle; a Lorry is a Vehicle; a Car is not a Lorry so not all
> Vehicles are Cars
>
> ii) A Potato is a Vegetable; an Onion is a Vegetable; a Potato is not an
> Onion so not all Vegetables are Potatoes
>
> Which has the direct analog with (something similar to):
>
> A Control is an Object; a Card is an Object; a Card is not a Control so not
> all Objects are Controls
>
> Of course, having just written that, I do remember a number of computer
> science textbooks I have read (which are aimed at undergraduates) belabouring
> such points as these (almost in this direct fashion) - which suggests that it
> isn't a very easy concept to get across even to those who are 18+. i.e. I
> suspect it is more difficult to teach than I perhaps imagine!
>
> 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
Devin Asay
Office of Digital Humanities
Brigham Young University
_______________________________________________
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
