Thank you very much indeed for the comprehensive reply.
I shall deal with the children's confusion by using neither 'object' or
'control' and
just refer to buttons, fields and so on.
I know this is dodging the issue; but I can see no other way round it at
the moment.
Richmond.
On 20.06.2016 12:28, Mark Waddingham 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.
_______________________________________________
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
