LiveCode Forums.

I have some basic questions for the experts here.

How do you handle data models? In traditional programming you have structs and objects; with functional programming you have lists and a vast array of functions to perform on those lists; Livecode has an associative array and custom properties of an object. How do people do things like stacks, queues, linked lists? How about sets or trees?

I also wonder how most people represent objects-- does everyone really create a button and start setting its properties every time they need a new object X?

For instance, my app will involve the concept of a user and a bunch of data associated with that user. It will communicate with a server and get several user's and their data. An associative array seems less than ideal for many use cases, such as organizing my users into groups. Lots of my app code will operate on the data model itself, which has nothing at all in common with buttons, which are the default objects, if you will. So how do you create a new User, assign it some data, maybe pointers to another object (that user belongs to a team and has XXXX permissions to access stuff, each of which can be changed), etc. You can, I know, create a massive "everything lives inside this one User button" but that totally is not DRY (don't repeat yourself). Plus it means updating a ton of things when all I want to do is make the User do something differently. And how can I have a collection of Users; as far as I can tell you can't really stick a bunch of buttons into a LiveCode array.

And that brings up my next basic question: how does LiveCode handle the composition scenario? Behaviors satisfy the is-a test (this car is a vehicle) but how do people satisfy the has-a test (this car has an engine)? The only thing resembling a pointer is the long id, which as I understand it is rather fragile and varies between stacks and running of the program, so you cannot really save an object relational graph.

Is the only solution to drop down into a SQL db of some sort and let it keep track of the relations between objects?

Hi.

I wonder if the very structure of an xTalk like LC is so unfamiliar to you that its native object model and functionality seems unsuitable to your concerns.

I hope that others more experienced with procedural languages will soon chime in, but I will bet that much, if not all, of what you need can be implemented here, and that it just takes a bit of practice to see that LC can embrace it all, albeit possibly in a manner that many experienced programmers simply have not seen before.

The entire reservation system for KLM runs on it.

Do give it a chance...

Craig Newman

I was hoping someone with more familiarity with other languages would jump in here too but I can answer some generic things.

I think you are confusing the on-screen controls with the concept of "objects" in object-based programming. They are quite different, and LC isn't strictly an object-oriented language even though we call the controls on screen "objects." Buttons and fields are just visual displays, unrelated to the data structures you manipulate in scripts except in very peripheral cases (for example, a field can display the manipulated data.) The data structures you are looking for are supported as variables in your scripts, though it is important to realize that in most cases data is always represented as strings for the purposes of coding (internally in the engine they are typed, but scripts treat everything as strings.)

You can do what you want by creating an array and assigning your users as its keys. Each key can have any number of elements, and elements can also themselves be arrays. This array would be your main data structure, from which you would pull whatever data you need. If you would rather have a numerically indexed array, you can assign integers as the keys and make the user names one of the elements. This array can be read from or written to a custom property of the stack, or to disk, or to a file, or the internet, or recalculated on demand. It's a compact data structure with unlimited expandability. When you want to display some data on screen, you would extract what you need from the variable and display it in an on-screen field.

Your script should not live in any buttons, it will probably need to be accessible from anywhere in the app, so it should go into the stack script or somewhere else in the message hierarchy that is available to all the places where it will be used. For that, you'll need to know about the message hierarchy, which is critical to how LC works. For now, you can stick with the stack script if you want to just get started.

Let us know what else you need to get moving. There's a mental leap required when transitioning to LC from other languages because the paradigm is much different. Once you get that down, the rest should be pretty easy for you since you obviously already have the programming concepts. You just have to flip a little switch in the mental construct first.