Equivalent of classes in LiveCode

[Thierry]

There are ideas and concepts in LiveCode that are unique to it,
and need to be explained with what LiveCode newbies already know from prior languages.

Hi Bill,

Are you aware of this blog?

https://livecode.com/resources/guides/developers-guide/

It has been written for C, C++ and Java developer.

HTH,

Thierry

[jacque]

Are you aware of this blog?

That's the page I was looking for. Unfortunately it's somewhat out of date but the basic info is still correct. For example, tool icons have changed and there are more to the of them now, and the language isn't called Transcript any more. But those things are very minor.

[aetaylorBUSBnWt]

Hi,

I am old school, started programming with toggle switches and graduated to paper tape. My wife hated the smell of the oiled paper tapes. I had one I used a lot: Subtract Double Byte (SBDB), you say paper tape, she says SBDB. Nothing worse than dropping a box of cards on the way to submit them for running - even if they were numbered (yeah, you had to do that manually).
So, yeah, C++ was a godsend from my viewpoint.

LiveCode is new to me. My interest in it comes from a need to create a cross platform desktop application.

One issue I thought I saw in the discussion is lots of misunderstanding in the use of terms. I thought I saw too many assumptions of understanding of terms and then potential misunderstanding of the use of terms. Some of this misunderstanding is probably from my lack of experience with LiveCode.

Definitions from my point of view (C++ programmer);

Class - A definition of a thing that has named properties(fields), a blueprint. A Class has no visiblility to the user of the program. You can't do anything with a Class until you instantiate it as an Object. Neither the program, nor a user of the program can do anything with a Class until it is instantiated as an Object.
This is the biggest thing about "Class", it is a blueprint where everything has a name and that is how you "get" to it.
As an Object, now you can put values into the properties and operate on them. Each property has a type and only one type. The Class has functions (called methods) that can operate on the properties. Normally ONLY the Class's functions can access and manipulate its properties. Yes, a property can have a default value, but that is a detail.
Another way to look at a Class is that it is a Structure with functions attached to it.

In no way is a Class an Array.

Given the above, what is the closest abstract element of LiveCode that maps to Class?

Where does one store such abstract elements, whatever it is that maps to Class?


I just noticed on Jul 14, 2020 that a new post happened with the following link:
https://livecode.com/resources/guides/developers-guide/

The above link helps a lot, although does not answer all questions. I think my answers to the questions I posted are:

Given the above, what is the closest abstract element of LiveCode that maps to Class?
It seems that what LiveCode refers to as an "Object" is close to a Class.
An Object has named properties and code that is applied to those properties.
Confusing because when LiveCode says "Object", a C++ programmer thinks that is the instantiation of a Class.

Leads to new questions:
What is a Button? Is it an Object?
Is there such a thing as an "abstract customized Button" (call it absButton) that supplies the functionality for all the visible Buttons in all windows that you want to look and function the same way as defined in "absButton"?

Inheritance is sort of handled with the message passing hierarchy and the idea of Groups, but not really.

Still not certain how to create a Class that is not visible to the user?
(maybe make a bunch of Buttons, with the Visible property set to false?)
That just feels wrong.

Where does one store such abstract elements, whatever it is that maps to Class?

One thing that comes to mind.
If you have a database full of records. Each record's abstract concept can be represented by a Class and each record itself is an instantiation of that class. Depending upon the circumstances there are going to be fields in that record that are not going to be visible to the user and some that will never be.
How does one handle that?

Be wonderful if someone could provide clarity.
In the meantime I will continue on with the LiveCode Tutorials.

Thanks,
Andrew

[mwieder]

Andrew-

Excellent writeup. Thank you.
From another old-school paper-tape programmer, here are a few things off the top of my head:

I don't think trying to approach LiveCode the same way you'd approach C++ is that valid.
LiveCode has elements of object-oriented programming, but it's not that.
The inheritance is there, especially now with behavior scripts, and we have built-in objects (buttons, fields, cards, etc) but I wouldn't try to take the analogy much farther than that.

You're correct in that if you want something like abstract classes you'd need to do something like make a button invisible and set it as the behavior of other objects. It works a treat, and this is something I do a lot. Each subclassed object (those that share a common behavior object) will have its unique properties.

The lack of proper subclassing in the traditional sense in the language gets to be a pain when you need to create something like a linked list, but that's doable as well. You just have to rethink things.

Another way to look at a Class is that it is a Structure with functions attached to it.

LOL. That's mostly the way I view classes as well, but that's because I'm old school and still think of C++ as "a better C".
I also still think of references in terms of pointers.

[dunbarx]

Hi.

Many are likely lurking here.

Since you already have a sense of LC, and how it differs from other languages, can you give a couple of short examples of things you are not sure how to implement, or if they even can be? Mark's example of an invisible button acting as an abstract class would be something like what I am talking about.

I am optimistic that LC can do most of what you need and want, though I bet it will be in ways you are not familiar with. That single point can be a deal killer to some, and a magical gift to others, depending on, well, lots of things.

Craig

[jacque]

I am not old-school, but perhaps the idea of an uninstantiated class would be the template objects: templateButton, templateField, templateImage, etc. These do not "exist" per se, but you can set their properties and then instantiate them.

All "objects" (also called "controls") are the things you see in the tools palette and which appear on the card. LC has already created the classes in the engine: button, field, widget, etc. Those exist by the time we get to them. All we need to do is assign properties. There is really only one button class, one field, one scroller, etc. even though there are several different types of each in the tool palette. For example, the button types you see there are just different variations of the button class that already have pre-defined properties set. So you are basically correct: an object (or "control") is an instantiation of a class.

An abstract, customized button can be created by setting properties on the templateButton and then creating a new button on the card. Newly created objects always use the properties of their template object.

Inheritance is different from the message hierarchy. Inheritance refers mostly to the appearance of objects (a card inherits its colors from the stack, for example, or a field inherits its text properties from its group, card, or stack) while the message hierarchy determines which object will act on a message (the first control that traps the message acts on it; if there is no handler that traps the message, nothing happens.)

LC is much different from what you're used to (don't worry about classes, they don't exist in the way you think) but that's what makes it so easy to use. Half the work is already done for you.

[mwieder]

Jacque-

Inheritance in an OOP sense does indeed mean the message path.

And while setting properties of a template does indeed allow subclassing new objects created afterwards, it's ephemeral. Changing aspects of that template won't affect any of the newly created objects. I suppose you could create a framework that creates a superclass from the template, then retrives the superclass properties in order to set the template again when subclassing a new object, and assigning the superclass object as a behavior to the new object, but I haven't gone down that road.

...although now that I think about it, it's got possibilities.
Hmmm... there goes the rest of the week...

[aetaylorBUSBnWt]

Hi,

More Details on my needs coming from C++...

At present I am just beginning to learn LiveCode - still reading through the tutorials and looking at the forums for understanding of what is available and this thread jumped out at me.

My normal mode of development is build the data handlers and functionality, as divorced from the environment as possible, both operating system and UI, and then add in the dependencies of the operating system vendors and UI around the core functionality.

So I have a library of C++ classes that handle a lot of that core functionality. Now the trick is to layer a UI on top, as well as data collection that delivers data down to the core C++.

My application is based around a database. I have a number of similar tables that have common fields, with common functionality. So I have base classes that implement core Sqlite access functionality, subclasses that drive sets of more subclasses for tables with similar structures and so on.

There is lots down there that the user really wants to avoid seeing or even knowing it exists. But for those parts of the records in particular tables that they do need to see and interact with, that is where I would need to map certain fields of those database tables to be displayed in tables for the user to interact with.

In some cases a record that is displayed to the user has fields from multiple database tables that are related. I do have a mechanism for describing these meta-tables so that data can be delivered to the UI and collected from the UI.

And of course, just to be difficult, several of the tables that the user interacts with are similar, so there are sets of display classes (in Objective-C on Cocoa) that are similar, so that meant a hierarchy of classes with common functionality at the base subclassing down to each particular need.

I created an application on MacOS using XCode and Objective-C/Cocoa that uses all these concepts and it works fine. But, of course, it only runs on a Macintosh.
I am in the process of re-implementing a prior application that I had been working on that uses my C++ database class library. I had started the UI in Cocoa, but stopped because a significant number of potential customers will be using Windows.

My core C++ database Class library is probably best not fooled with, I am going to need to figure out the means of interfacing from LiveCode to the C++ class library. The mechanisms I used in Objective-C would have to be primarily rewritten in LiveCode or portions of them shoved down into an interface mechanism in C or C++

So given all that what kinds of LiveCode functionality?

I think of a record as a class. Some fields are displayed/modified, some (a record ID or a support table reference) are used behind the scenes.
One of my displays would show the rows of a database meta-table with a number of fields displayed. In addition, the selected record would have an edit box with all user modifiable fields in it. Some fields are text, some checkboxes, some popup menus, buttons for bringing up associated records.
And of course, just to be difficult, I intend that the user can modify what fields get displayed in the table area because sometimes more information is useful at times and sometimes it is just distracting clutter. Probably want to store several presets with different numbers of fields in different orders with field widths for the display.

I need to log into a web site using the OAuth 1.0a spec. (vendor refuses to update his implementation). So that means launching the default web browser, letting the user do their login and cause the verification code to be generated.
Anybody got the library to redirect a web browser callback URI back to a desktop application?
If not, then the customer will have to copy/paste into my application.

Need to parse JSON responses from that web site. I do have JAVA library for that I suppose I could try to integrate instead of rewriting.

One of the functionalities is alarms based on future dates, stock prices and other data. So I will need a background thread checking that stuff. User might want to have an alarm be reported via email. So a means to send email.

One thing that is not clear to me yet is how to use stacks and cards to either segregate or aggregate various bits of functionality in the application. Would I work from the idea that a Stack is a collection of windows, where each window is a Card? Then collect different parts of the application's functionality into different Stacks?

It sounds like I can call into other Stacks to get other functions to run or open a window(card) contained in that Stack, correct?

Since I posted last I have seen more discussion, especially the templates - where are those found?

Thanks for enduring my rambling. Be back tomorrow.
Andrew

[mwieder]

Mmmm... a lot to process there.

A few things:

The templates don't exactly "exist" anywhere. Think of them as C++ abstract classes - you instantiate an object, say a button, by configuring the button template and then creating a new button. But the buttontemplate can then be changed at will, and it doesn't affect the created button. That's where the analogy with classes and subclasses falls apart. There are templates for all the primitive objects.

Code: Select all

set the width of the templatebutton to 54
set the height of the templatebutton to 23
create button "aNewButton"

While you can extend the basic LiveCode capabilities with LiveCode Builder (LCB:another learning curve) or with the older externals interface, if you need to hook in C++ libraries you're going to need to unmangle the C++ exports to plain C syntax. It's doable, but adds another level of complexity.

If you're dealing with REST APIs (OAuth1.0a? ick...) then doing this in LiveCode is straightforward, as is handling the returned JSON object. But I mainly work in linux, where the browser component of LiveCode hasn't worked in years, so if you do need to do browser things outside of normal LC scripting I'll leave commenting on that to someone else.

Most of the stacks I create use multiple cards sparingly. I'll create a new card to, say, hide things from the normal user interface but that are essential to the functioning of the stack, for instance behavior buttons acting as superclasses for multiple objects or images that I want to display in the UI occasionally.

...and BTW, congrats on finding LiveCode and pushing through even this far to investigate the possibilities. I've said for years that I'm about four or five times more efficient in LiveCode than I am coding in straight C/C++, even though I usually find that it's easier to rethink an application than to do a conversion/translation from another platform or language. There *is* a learning curve here... I think Jacque estimated it once as about six weeks before things click, and that seems about right. I'm guessing if you get to that point you won't be disappointed. YMMV.

[jacque]

Inheritance in an OOP sense does indeed mean the message path.

Ah. Okay. aetaylorBUSBnWt, listen to Mark, he knows what he's talking about. I'm a one-trick pony.

[FourthWorld]

LiveCode is not an OOP.

C is not C++.

Procedural languages are not object-oriented.

Apples are not oranges.

Car batteries are not macrame.

A door is not a jar.

Lots of advocacy on either side of OOP all over the web, no need to replicate it here (best argument for C over C++ was from a speaker in our local Linux User Group a few years back - if interested I'll see if I can dig up his summary).

As with any learning, if you try to apply a mental model to something unrelated to the model, it can slow learning down. Sometimes a lot.

Really good C programmers can list the ways to get the benefits of C++ without the overhead. Some may disagree, but sometimes there's a good argument there. But even the best benefit of C++ won't be true OOP if it's implemented in C.

LiveCode has some very nice features for inheriting visual properties, and creating classes of GUI objects (see Behavior scripts). But abstract classes simply don't exist in LC, nor do many other OOP concepts. Attempting to find them will exhaust the searcher, and bypass the opportunity to learn a different way of thinking.

LC offers a very good model, with readable high-level scripting where GUI objects are a native part of the core language, all running on nearly any platform. It just isn't OOP. Or macrame. It's its own object-like programming paradigm.

LC isn't the best at everything. But for many things it's quite good. It just isn't OOP. Like a lot of things in life that aren't OOP. When learning any non-OOP language, leaving OOP at the doorstep will speed the learning curve. Later on you may find a few features that are somewhat OOP-like - and if you approach the learning with that open mind, those discoveries will be comforting, while the rest of what you learn less frustrating.

In short, you're right: arrays aren't classes.

[FourthWorld]

Forget everything I just wrote. It turn out that C and C++ are both bad.

https://www.radford.edu/ibarland/Manife ... sBad.shtml

[bwmilby]

I ran into these two articles a while back that may be interesting to you:

http://newsletters.livecode.com/novembe ... etter2.php
http://newsletters.livecode.com/novembe ... etter2.php

It is about using groups to implement classes and inheritance.

[mwieder]

Forget everything I just wrote. It turn out that C and C++ are both bad.

LOL. When I was at Apple we brought in Bjarne Stroustrup to give a talk, the basis of which was "now after several years of this, things I'm sorry I put into C++ (the friend class, for one thing)".

[mwieder]

LC isn't the best at everything. But for many things it's quite good. And it just isn't OOP. Like a lot of things in life that aren't OOP. When learning any non-OOP language, leaving OOP at the doorstep will speed the learning curve. Later on you may find a few features that are somewhat OOP-like - and if you approach the learning with that open mind, those discoveries will be comforting, while the rest of what you learn less frustrating.

What Richard said. I can't improve much on that.