Code reuse, object orientation

[GTGeek88]

Am I correct in thinking that there's really no object orientation in LiveCode? It's more like Visual Basic was prior to dot NOT - it looks like you're dealing with objects, but there's no inheritance, polymorphism, or encapsulation. So, for a simple example, if you have a bunch of buttons strewn across an app and you want to increase the font size one point, instead of being able to change the font size of the button class used to make the buttons and then having it change on all the buttons in the app via inheritance, you have to walk the entire app and make the change in each button, right?

Just a quick note to RunRev lurkers, I ran into a problem posting this. It said I didn't have permission to post URLs or domain references (or some such message). I discovered that the problem was that I was referring to Microsoft's flagship dev environment as ".N E T" (remove the spaces - had to do that or I can't post). I removed the dot, but still it gave me the same message (the only thing remaining was " N E T" (again, remove the spaces), so then I called it "NOT" (which a lot of people call it, anyway). Only then could I post. I think the logic that evaluates the posting for this particular rule validation needs some tweaking.

[sturgis]

There is a -kind- of inheritance.. If you set the font size at the stack level, any objects that don't have their font size specifically set will inherit the change. If you set the card to a different size, since it is 'between' the stack and objects on the card then the objects that aren't specifically set will inherit from the card. If you have multiple cards and have the font size set for the stack, and some cards have a different size set, the cards without the set will reflect the stack setting, the cards with setting will override the stacks.

Then add in groups. Drop a bunch of buttons on a card. Group them. Set the font of the group and all objects in the group should inherit the font size from the group. (as mentioned before, unless the object is set specifically. )

If you want to adjust the buttons themselves with a script you can do something like this from the message box.(multiline)

repeat with i = 1 to the number of buttons of the current card
set the textsize of button i to 24 -- set it to 24
end repeat

To get them back to where they will inherit again, set the textsize to empty


you could "set the textsize of button i to the textsize of button i + 1" but since the buttons start with an empty text size this would set the textsize to 1.

As for the way the url refusal works, its actually not that big a deal because in a few more posts you'll be able to use urls.

[dunbarx]

There is also the ability to use templates (see the "templateButton" and its kin). Though this is working backward from what you mentioned, it is a powerful tool, and at least touches on some of your concerns.

There are other facets of the program, such as behaviors, which mimic OOP to a certain extent. But you are not the first to state that LC is not a true OOP environment.

The xTalk paradigm is, it is true, set in its certain ways, in that properties are generally managed at the object level, as opposed to the object class level. But the paradigm has its own compelling virtues: power, flexibility, accessibility, readability, and I dare say pleasure to use. In these it is unsurpassed. It just takes a little getting used to, and then. like a great book, it is hard to put down.

Craig Newman

[bn]

Just to add to Sturgis's excellent explanation about the inheritance of certain properties of objects: if the property of an object is not set explicitly and you will have to query the e.g. effective textSize. Look at effective in the dictionary.
This can be confusing if you want to know the e.g. textSize of a button/field etc and it returns empty. That is because it is an inherited property. The effective textSize will give you the currrently applied textSize.

Kind regards
Bernd

[GTGeek88]

Good information from all the responders. Thank you. I do like what I'm seeing, so far. There are good alternatives, but LiveCode seems to be in the top tier, from what I know at present. I must confess to not being all that enthralled with the syntax direction they have chosen. I come from Visual FoxPro (the XBase world). The language syntax of VFP is - to me - a nice middle ground between the cryptic nature of C and its offspring and the overly verbose nature of something like Cobol.

The syntax of most languages is limiting, but that's a good thing. I think it helps you learn it faster. But when you start making it more English-like, then I'd say it makes things harder in a way. There are multiple ways to say the same thing in English and so there would be multiple ways to phrase it in an English-like programming language: Set the height of the form to 400, Store 400 to the height of the form, The form height is 400. I'm not saying any of those are valid syntax for LiveCode, but hopefully you get my meaning. There is probably only one valid syntax, but my mind, familiar with English, throws out all these options to say/accomplish what I want to accomplish, which can be problematic, I'd think.

In VFP, it's like so:

thisform.height = 400

You're just setting a property. You refer to the form itself and the height property and set the value to 400. And changing the caption on a label is:

thisform.lblName.Caption = "First Name"

Readable, yet quicker to learn because of the limitations of the syntax.

But, that's water under the bridge and probably pointless rambling given that the decision has been made. Readability is great and you can make VFP and other languages very readable, but the most important thing about learning a new language is its clarity and conciseness and the quality of the training resources. Its faithfulness to a particular language - English, in this case - is less important, IMHO.

One other thing about VFP - it has the Command Window where you can execute commands and see the results. You can run small (actually they could be large) programs in it and it's a great tool for learning and testing during development. I love that LiveCode has something that seems very similar. It's a great tool to give developers!

But, again, I'm liking what I see overall and, at the very least, will enjoy exploring LiveCode. At the very most, I'll enjoy putting it to use to build apps for clients.

[Klaus]

Hi GTGeek88,

well, this one (DOT syntax) has been discussed often in the past and the majority of the LC useres did NOT want it!

Set the height of the form to 400, Store 400 to the height of the form, The form height is 400. I'm not saying any of those are valid syntax for LiveCode, but hopefully you get my meaning. There is probably only one valid syntax, but my mind, familiar with English, throws out all these options to say/accomplish what I want to accomplish, which can be problematic, I'd think.

Hm, as a non native english speaker the second one does not make any sense to me!?

You said: "You're just setting a property", yep but which of your 3 examples might do that?

Set the height of the_form to 400
## Well this IS in fact a VALID Livecode command and seems natural to me

Store 400 to the height of the_form
##???? Sorry, no capisce

The_form height is 400
## just a statement, no command or something

Anyway, welcome to the forum!


Best

Klaus

[dave_probertGA6e24]

Klaus,

Store 400 to the height of the form = put 400 into the_height of group "the_form" - probably closest equivalent

Personally I'd love to see the syntax have an alternate version along the lines of:

set theVar = 100 ## Basic-like

or even the standard:
theVar = 100 ## C/C++/PHP/Javascript/ sooooo many others.

Marks' GLX pre-processor can handle it, but it (as he says) breaks things a bit. But if RunRev included an alternate system that was internally recognised then I'm sure there would be a large influx of other language users coming across to Livecode. But, alas, I fear that is not going to happen for a long while

Livecode is a "Love"/"Get annoyed at" type of language - though I mainly get annoyed at the IDE !! Once you get the hang of the syntax the hard part is figuring out what it can't do !! (Excluding 3D stuff and so forth )

Welcome to the forums GTGeek

Cheers,
Dave

[mwieder]

GTGeek88-

The syntax of most languages is limiting, but that's a good thing. I think it helps you learn it faster. But when you start making it more English-like, then I'd say it makes things harder in a way.

Right on all counts. Learning any new programming language is probably easier if you're not carrying a lot of baggage from other environments. There's less to unlearn. But then the background gained from other environments is invaluable in getting a foothold in the new one. You just can't win.

There's nothing to stop you from using dot syntax in your own code to make things more (to you) readable. I do this all the time to group functions thematically. But in LiveCode it's just a semantic constuct and doesn't have a meaning to the compiler.

Code: Select all

put XML.EndTag("address") after tRecord

I'd love to have real OOP in LiveCode someday, but it has to be implemented by the rev team at the engine level. As others have posted, we're already part way there with message inheritance, and behavior objects get us closer. But you can't do things like implement linked-list objects or do other things with OOP in code. Someday. But the language is rich enough that there's always a way to do what you need to do, even if you have to rethink it.

[GTGeek88]

well, this one (DOT syntax) has been discussed often in the past and the majority of the LC useres did NOT want it!

Interesting that it has even been discussed. I wouldn't necessarily have guessed it. If many users are non-programmers picking up iOS programming because the language is very English-like, then I'd expect that response. A desire for something a little closer to other languages would probably come from the more experienced programmers. That'd be my guess, at least.

Hm, as a non native english speaker the second one does not make any sense to me!?

I believe you were referring to my non-real, used-as-an-example syntax where I said "Store 400 to the height of the form"? If so, it was just used to try to convey a point. That syntax is like VFP syntax, where you can say STORE 15 TO VARIABLE1, VARIABLE2, VARIABLE3 and get three variables set up with the value of 15. My point was only that when the programming language starts trying to be exactly like a human language, you get all the problems associated with the syntax and grammer of a human language (English in this case). As for non-English speakers, all I can say is that I'm glad I'm a native English speaker. As an American, we are spoiled in that respect (and probably some others, too).

Livecode is a "Love"/"Get annoyed at" type of language

Ha, what programming language doesn't qualify for that type of relationship?!

[GTGeek88]

Right on all counts. Learning any new programming language is probably easier if you're not carrying a lot of baggage from other environments. There's less to unlearn. But then the background gained from other environments is invaluable in getting a foothold in the new one. You just can't win.

Well, I'd say knowing another language is a net gain, though there can be things to "unlearn", as you say. Going from an OO language to a non-OO language does feel like something of a step backwards. However, there may be enough good things in LC to make it worthwhile.

Thanks, everyone, for your replies.

[Klaus]

Livecode is a "Love"/"Get annoyed at" type of language

Nope, that was Dave

[GTGeek88]

Oops, sorry, I stand corrected.

[FourthWorld]

set theVar = 100

Almost the same amount of typing as in LiveCode:
put 100 into theVar

...but with the added benefit of knowing that you're not setting the value of an unspecified variable to "false" (theVar=100).

How many millions of person-hours are lost each year to bugs stemming from the difference between "=" and "==" in languages which use "=" as an assignment operator?

With LiveCode, "=" is an evaluation operator, and assignment is done with either "put" or "set". Maybe not ideal, and I don't know if any language is ideal, but at least it avoids the ambiguities inherent in using "=" for assignment.

[mwieder]

How many millions of person-hours are lost each year to bugs stemming from the difference between "=" and "==" in languages which use "=" as an assignment operator?

I learned that lesson long ago from one of my mentors.

Code: Select all

if (100 == theVar)

gets you out of the kind of trouble that

Code: Select all

if (theVar = 100)

gets you into.