Object Method Designation

[WaltBrown]

I would like to have a "dot" mechanism for addressing objects and functions. I frequently have similar named objects and subroutines in multi-stack applications. Because of the difficulty with tracking whatever is the "default" stack during complex operations, I would like to have the following:

1. Be able to address objects, and call functions using a "dot" mechanism - "sStackName.fFieldName", "sStackName.wFunctionCall", etc, that bypasses the "defaultStack" assumption.

2. Enable reserved common alias names for objects, such as "me.fFieldName" and "me.wFunctionCall", or "target.pPropertyName" or "target.wFunctionCall". Allow "default.wFunctionCall" as well to stand in for "wFunctionCall" dependent on "defaultStack".

3. Resolve variables as object names, as in tMyLibraryChoice = "sLibraryThree", then tMyLibraryChoice.wFunctionCall.

4. Enable it for properties as well, as in tMyField.imageSource, or tSomeStack.uRIP["name"], as an alternative to "the imageSource of field tMyField of card tCardNumber of stack tSomeStack".

5. An additional interesting aspect might be to use the unique ID of each object as an alias as well, resulting in constructs like "get the revUniqueID.behavior", at a minimum greatly reducing the amount of code and typing required.

Thanks, Walt

[Klaus]

This has been discussed many times in the past and the majority of the users did NOT want the DOT syntax.
We all like the "plain english" thing as it is!

[FourthWorld]

Hello Walter -

I've gone to bat for you a few times, advocating that RunRev consider ways to implement OPTIONAL dot notation to ease the learning curve when coming from most other modern scripting languages. Director's Lingo did a fine job of supporting both xTalk-like syntax and dot notation well, and I wouldn't mind seeing it in LiveCode too. But as Klaus noted, there's an interest in maintaining the essential flavor of the language that has thus far kept dot notation at bay (though it'll be interesting to see how they handle the syntax challenges when the language gets true OOP extensions, but that's way down the road).

So instead, let's see what we can do to help your "unlearning curve": do you have examples of specific tasks you'd like to accomplish that you're not clear on how to approach with LiveCode?

I'm sure we can help you get oriented to the syntax you need once we understand your goal.

[WaltBrown]

Hi Klaus. Yes I agree with the "plain English", but I also want to type less code. Also, I already have certain software paradigms integrated in my own "plain English" neurology (neuropathy?). . And English does evolve over time (but yes, not many of us say "grep keys pockets" either).

Thanks Richard. My thinking is this. I would like to address objects without necessarily knowing what or where the object is. LC already does a great deal of automatic "translation", for example in using numbers as character strings or numeric values, which is effectively object overloading, and aliasing as in "defaultFolder". I would like to have overloaded variables that hold object identifiers, without having to go through the "button 'X' of card 'Y' of stack 'Z' rigamarole

So in various places in my code base might I have:

Code: Select all

      put "myStack" into tUtilityStack 
      put "someObject" into tUtilityObject
      put "someFunction" into tUtilityFunction

Then, somewhere else, I would be able to call:

Code: Select all

      put tUtilityStack.tUtilityObject.tUtilityFunction into tLocalVariable

without knowing what was actually in tUtilityStack, tUtilityFunction, or tUtilityObject, and more importantly, not knowing or caring if tUtilityObject is a card, button, field, backscript, etc. If it were empty, it would just fall to the stack itself. Currently I could do something like:

Code: Select all

     put "stack MyStack" into tStack
     put "makeRedCircle" into tFunction

But I can't do an object, and parse it later. Plus if it was empty, I would have to have alternative constructs:
tFunction of tObject of tStack, would parse as "makeRedCircle of of stack MyStack", which would of course fail.

Am I being clear? Sorry, I need to run, more later.
Walt

[ooper]

I'd like to see the discussions that Klaus is talking about. I sure wasn't part of it

I for one vote for it.

Personal preference or unlearning aside, I believe OPTIONALLY adding dots (or a similar mechanism) is significant in at least two key areas:

Name resolution: Once you add plugins, front and back scripts and other runtime execution paths, LiveCode has a serious naming problem with handler/function/custom properties names. Yes, you can prefix names, but this GREATLY reduces readability, which directly diminishes RevTalk's advantages of "program with English" motto.

Tooling: Dots to separate language elements improves the way we can predict and automate code generation, such as autocomplete and introspecting code. RevTalk's needs this especially because it is very verbose.

/Carl

[WaltBrown]

Looking at the "drag and move" thread, a similar mechanism is used in a couple other scripting languages, in one case LSL, for selecting structure elements. Here are a few examples I came up with. I understand many of these can be done using existing syntax, but I think this is more understandable in certain cases:

Code: Select all

put target.location.x into tAcross
put item 1 of the location of the target into tAcross
-- This adds the identification of what item 1 is to the code

put me.rectangle.left into tLeftEdge
put tWhichObject.rectangle.tWhichEdge into tSomeEdge

put clickStack.unknownCard.unknownButton.backColor.r into tThatMuchRedWhereTheUserClicked

put myTemplateStack.myButtonsCard.mySearchButton.behavior into me.thisCard.newSearchButton.script
put myTemplateStack.myButtonsCard.mySearchButton.customProperties into target.customProperties
if target.type = "button" then put target.label into tThisWord

repeat tAnObject.height times
   add 1 to tSomeOtherObject.location.y
end repeat

[FourthWorld]

I'd like to see the discussions that Klaus is talking about. I sure wasn't part of it

I for one vote for it.

The discussion was in the improve-rev list, an NDA'd list which was available to Enterprise users in the past and is now part of the Developer Program. Since it's under NDA I can't provide a URL for it, but in brief the general feeling from most folks except myself was that dot notation would stray too far from the essential flavor of the language, introducing readability issues (I'll agree that many elements of dot notation are ambiguous) without providing benefits that can't already be accomplished with existing syntax.

You're welcome to post a request for it, but don't hold your breath for an implementation:
http://quality.runrev.com/qacenter/

Personal preference or unlearning aside, I believe OPTIONALLY adding dots (or a similar mechanism) is significant in at least two key areas:

Name resolution: Once you add plugins, front and back scripts and other runtime execution paths, LiveCode has a serious naming problem with handler/function/custom properties names. Yes, you can prefix names, but this GREATLY reduces readability, which directly diminishes RevTalk's advantages of "program with English" motto.

I believe it's been mentioned publicly that there is a plan in place to introduce name spaces to the language to obviate this shortcoming. I don't know which version this is planned for. It's a non-trivial change, so I wouldn't expect it in v5.

In the meantime, using prefix designations only impairs readability from the standpoint of narrative writing, but code is far more often skimmed than read so prefixes act as identifiers to make elements stand out from other code in a way that can be very useful, which is why Charles Simonyi (former lead engineeer at Microsoft) evangelized what has since become known as "Hungarian notation" in his honor.

I tend to use a coding style I call "Hungarian-lite", documented here:
http://www.fourthworld.com/embassy/arti ... style.html

With prefixes for not only library calls, but also for params, globals, script-locals, etc., I can tell at a glance where a call resides or where a value was set, without having to go look it up.

Even in OOP languages like JavaScript I still enjoy the benefits of Hungarian notation for the skimmability benefits it provides.

Tooling: Dots to separate language elements improves the way we can predict and automate code generation, such as autocomplete and introspecting code. RevTalk's needs this especially because it is very verbose.

Let's explore this. If you have examples in mind, let's see if we can come up with compact ways of expressing them in LiveCode.

[FourthWorld]

Looking at the "drag and move" thread, a similar mechanism is used in a couple other scripting languages, in one case LSL, for selecting structure elements. Here are a few examples I came up with. I understand many of these can be done using existing syntax, but I think this is more understandable in certain cases:

Code: Select all

put target.location.x into tAcross
put item 1 of the location of the target into tAcross
-- This adds the identification of what item 1 is to the code

put me.rectangle.left into tLeftEdge
put tWhichObject.rectangle.tWhichEdge into tSomeEdge

put clickStack.unknownCard.unknownButton.backColor.r into tThatMuchRedWhereTheUserClicked

put myTemplateStack.myButtonsCard.mySearchButton.behavior into me.thisCard.newSearchButton.script
put myTemplateStack.myButtonsCard.mySearchButton.customProperties into target.customProperties
if target.type = "button" then put target.label into tThisWord

repeat tAnObject.height times
   add 1 to tSomeOtherObject.location.y
end repeat

That's more understandable to you because you're already well versed in dot notation.

I don't mind it myself; I enjoy being able to use it in JavaScript, and I recognize that most folks who will be learning LiveCode in the future will probably have some background in a language that provides dot notation so it would benefit learnability for the largest growth segment.

But that said, there is an ambiguity that dot notation introduces which is not easily resolved by anyone completely new to programming.

For example, in this statement:

Code: Select all

put myTemplateStack.myButtonsCard.mySearchButton.behavior into me.thisCard.newSearchButton.script

Which of those elements are variables and which are literal property names?

The statement is only readable if you know in advance which elements are which. Anyone seeing the statement by itself who hasn't memorized the built-in property names will not be able to tell which is which.

Again, I'm okay with this because in my own personal view the benefits for aiding newcomers who have some familiarity with other modern scripting languages far outweighs such concerns. But I do recognize that such concerns exist, and from the discussion we had on the improve-rev list it seem you and I are in a minority of the existing user base.

[FourthWorld]

Good stuff - let's see what we can do with this to get your scripting going with what we have to work with today:

Currently I could do something like:

Code: Select all

     put "stack MyStack" into tStack
     put "makeRedCircle" into tFunction

But I can't do an object, and parse it later. Plus if it was empty, I would have to have alternative constructs:
tFunction of tObject of tStack, would parse as "makeRedCircle of of stack MyStack", which would of course fail.

I think maybe the function you're looking for is "the long ID", which will return an absolute reference to any object.

Since stack ID numbers are irrelevant for most scripting and best avoided anyway, asking for "the long ID" of a stack will give you something like this:

stack "/Folder/MyStack.rev"

…or if it's a substack it'll read:

stack "MySubstack" of stack "/Folder/MyStack.rev"

So like the long IDs of other objects, asking for "the long ID" of a stack gives you an absolute and unique reference to the object that can be used anywhere to address it.

For example, when making tools I often have a frontScript which updates the tool based on the current selection with something like this:

Code: Select all

on selectedObjectChanged
  put the selectedObjects into tObjs -- now contains a return-delimited
  -- list of the long IDs of the selected objects
  dispatch "UpdateUI" to stack "MyInspector" with tObjs
end selectedObjectChanged

Neither the frontScript nor the Inspector need to know what's in tObjs; as absolute references, they're resolved easily to do things like this in the Inspector:

Code: Select all

on UpdateUI pObjs
  repeat for each line tObj in pObjs
   put the name of tObj &cr after tList
end repeat
delete last char of tList -- trailing CR
put tList into fld "SelObjects"

Dynamic function pointers (such as 'put "makeRedCircle" into tFunction') are a different matter, but can still be used by employing the "do" command, similar to JavaScript's "eval" to let you execute arbitrary strings as code, e.g.:

Code: Select all

put "makeRedCircle()" into tFunction
do "get "& tFunction

…or:

Code: Select all

put "makeRedCircle" into tFunction
do "get "& tFunction&"()"

In practice I can't say I've needed dynamic function pointers very often. In fact, the only times I've needed anything close is when I'm making my own "5GL" in LiveCode's 4GL, but in such rare cases there are so many other challenges it never strikes me as odd to use "do".

[FourthWorld]

FWIW, I just posted a request to the RQCC for dot notation:
http://quality.runrev.com/qacenter/show_bug.cgi?id=9052

You're welcome to add your votes there, but note that the longevity of that database is currently uncertain: RunRev uses a different tracking system internally and the overhead cost of maintaining the public-facing DB may not be cost-effective so the RQCC may not be around forever. Enjoy it while it's here.

[ooper]

Richard (fourthworld),

I believe it's been mentioned publicly that there is a plan in place to introduce name spaces to the language to obviate this shortcoming...

Excellent.
I DO think the dots WOULD diminish the revTalk language somewhat as well. I'm most concerned about the name spacing issue and I would welcome an elegant solution.

I practiced Hunguarian way back in the 80's when C was strong --btw, my roots were in HyperTalk->C->C++->Java (in that order) professionally with many side trips in between. I strongly believe the Internet Browser was the wrong fix to a problem that Bill Atkinson should have tackled. While Hungarian is considered unacceptable practice in OO circles, you are right that it is a good workaround for LiveCode --as it was/is for C and Pascal. And you have done a great job in coming up with a standard for this community

Let's explore this. If you have examples in mind, let's see if we can come up with compact ways of expressing them in LiveCode.

The best example I can give you is the productivity gains in writing code using auto-complete in Eclipse. The environment knows that when I type a dot, I may be looking for instance variables or methods in the inheritance path. There is of course, a whole lot more around coding tools in Eclipse.

In LiveCode, I can think of a couple of options:

• Use dots for the purpose of tooling only; the tool does NOT output the dots. That would keep the language clean.
  
  The LiveCode IDE editor keeps track of the last word that was typed and pops up handlers/functions/properties/objects from Send, Dispatch, the, To and Of.

[WaltBrown]

Thank you very much Richard. I agree with all the comments about not complicating the language syntax. Your other tips are very helpful as well.

FWIW, in my old life I supported a very complex set of firmware, drivers, libraries,interpreters, and APIs for a wide range of multimedia and communications hardware components that had to play nicely together in large distributed soft real time telecom achitectures. Our primary development toolset had reasonably straightforward sets of language elements, various named objects for things like codecs, sessions, frames, sensors, execution queues, state machines, special processes, etc. So if I said something (in arbitrary pseudo code, it was actually in C) like "on newSessionRequest from inboundGateway attach newAutoCallDirector", that code would work on an analog phone line, a SIP message port, an ATM frame parser, a Windows IO completion port, a Unix device, a voice recognition resource, etc, etc, anything that could get an inbound session request. Our code under the hood determined what to do next, so the system developer didn't have to.

But there were always times an issue had to be diagnosed more deeply than the "normal" API tools could dive. So we had header files for structures that effectively turned all the named elements into structure pointers (loosely like the first versions of the Mac OS, with access to the parameter block interface definitions and function pointer redirectors for the firmware OS primitives below the various managers). Then I could get at things like internal driver queues, firmware settings, event priorities, intermediate buffers, system buses, etc. (Having 192 ports or more of real time comms hardware trying to communicate across a 16 bit ISA bus, or even a PA-RISC machine, could sometimes be challenging).

All this just to explain where my thinking comes from. I think it is important to keep the syntax "pure", but sometimes additional options are useful and can avoid some complex workarounds. Is it necessary in LC? I don't know, this was more in the area of "wouldn't it be handy if..." based on my own skillset.

And thanks again. I browse the forum quite a bit when drilling in and your comments have always been extremely useful.
Walt

[bmatichuk]

dot notation is a shorthand for the english words "that has" or "with sub-component".

The english notation of the renrev language is specific to general reading left to right.

Ex:

line 1 of card 1 of stack x

But dot notation is general to specific left to right.

classname.function


You could introduce the key words "with" to allow a general to specific left to right syntax

ex:

put 5 into stack x with card 1 with line 1


Which could be abbreviated to

put 5 into stack x.card 1.line 1

this might be ambiguous though, so you might need some other way to indicate blanks or to group things

put 5 into (stack x).(card 1).line 1

or you could have

put 5 into stack\x.card\1.line\1

to remove the ambiguity and reduce the number of brackets.


The runrev language is not a typed language and so using variables to refer to object is not easy.

So if you have

put "card 1" into x

put 5 into x


Do you mean

put 5 into card 1

or do you mean

put 5 into the variable x

This could be handled with an interpretation character like `

so

put 5 into `x


would mean "look at the contents of x and interpret that as the place to add something to.