UML

[goldbasilisk]

Another newcomer's question.
Does anyone have ideas about how to map a "conventional" OO design (aimed at languages like Java) to LiveCode? For example, what do OO Classes and Objects correspond to in LiveCode? LiveCode uses the word Object, but it means something different. Specifically, if I have a design expressed as a UML Class diagram, how would I map it to a LiveCode implementation? I know that UML has many shortcomings, but that's not the point of the question (so answers like "stop using UML" would not be helpful).

Basilisk

[Mark]

Hi,

You really have got to change your way of thinking when coding with LiveCode. I do make diagrammes, but usually these diagrams are for one (small set) of objects (where object is button, field, group, card or stack). Most of the time, it is sufficient for me to make a brief schematic description of the tasks to be performed by the script.

I say: stop using UML. It is mostly a waste of time to make formal diagrams. For LiveCode, it is sufficient to make quick overviews that help you organise your thoughts.

Kind regards,

Mark

[goldbasilisk]

Hi Mark

I think we're on the same page as regards UML, but that wasn't my question. OOP (a la Java) is the dominant programming paradigm, used by many thousands of programmers around the world. Telling them that LiveCode cannot cope with conventional software design is not a great selling point.

I'm sure there must be a way to map conventional OO design to LiveCode (e.g., class => script; method => handler; attribute => custom property; and so on). This might help current OO programmers understand how they could transition to a better world.

Basilisk

[Mark]

Hi,

This is the mistake that many people who come from the OOP world make. Either you will come to understand this and embrace LiveCode's (or rather xTalk's) simplicity or you will stay with OOP. You need to learn to think different(ly).

LiveCode doesn't have classes,methods and attributes. It has messages, which encounter functions and commands in buttons, fields, groups, card and stacks. These objects as we call them have properties. You might like to know that there is also a property called parentscript or behavior. Check it out in the docs.

Kind regards,

Mark