Equivalent of classes in LiveCode

[aetaylorBUSBnWt]

Hi,

I just checked out Mark's updated OOPEngine from gitHub.
I opened the OOPEngine.livecode file and for the first time, opened the Card Scripts.
I found out why there are newClass and deleteClass scripts.

Below is the openStack handler for that card.

Apparently there was the expectation of storing class script files down in the plugins folder.
Are these supposed to be .livecodescript text files? With the way the code is written, the file name must be the class name, which means no extension on the file name.

Was this a potential mechanism for people to distribute classes?

Seems interesting to have, but if one puts one's classes down there, does the LiveCode "create a standalone application file" process know to collect up those files?

Code: Select all

on openStack
   local tPath, tFiles
   local tFolder
   local tNewObjectID
   local tScript
   
   put the defaultFolder into tFolder
   start using this stack
   put revEnvironmentUserPluginsPath() into tPath
   put "/Classes" after tPath
   if there is a folder tPath then
      set the defaultFolder to tPath
      put the files into tFiles
      push card
      go card "Classes"
      repeat for each line tFile in tFiles
         put newClass(tFile) into tNewObjectID
         put url ("file:" & tPath & "/" & tFile) into tScript
         set the script of control id tNewObjectID to tScript
      end repeat
      pop card
      set the defaultFolder to tFolder
   end if
end openStack

[mwieder]

Oh. Sorry - I meant to get rid of that code.
Yeah, that was an attempt at a repository for class text files, and then I realized that it would work in the IDE but not for standalones.
The need for that openStack handler has been deprecated in favor of Brian's registerClass/registerClasses handlers.

[bwmilby]

The compare on GitHub isn't working like I would expect it to. Here's a current view of the differences between my copy of the main stack script of the OOPEngine and Mark's (created with DeltaWalker). The first difference is the removal of the extra handlers that are commented out (83-148 in Mark's). The second change is in the implementation of newObject (Changes start at 149, 198-263 deleted from Mark's). The private function classExists? is not used, so it could go away (since it is private, the once or twice where that comparison is used it could be swapped out for the function call without much effect).

This weekend I'll get Particles updated. I think it is better leaving the Emitter class as a sub-stack so that the project is more self contained while still demonstrating how to use a stack as a class.

[mwieder]

Thanks. I don't see any substantive differences in the two forms, just stylistic differences.
Obviously mine is better
Good call on the ability now to remove the classExists? function - I only used it in the newClass handler, and now that's been deprecated.

As far as future-proofing, I see I'm only passing a single argument to constructors, and I'm wondering if it's necessary to flesh that out and pass more as necessary.

[aetaylorBUSBnWt]

Looking better to me with every iteration.

Once we have opened Pandora's Box allowing for parameters to a class constructor, yes one has to allow for an unknown number.
Fortunately that code is simple and little impact if there are no extra parameters.

An example of extraction code for the constructor to extract the parameters should be included in the example constructor command.

I like the idea of the Emitter class being a substack to show off options.

[aetaylorBUSBnWt]

Hi,

Has there been any updates since Sept 4?

Another question: I am looking at the processes of using this and trying to figure the best way to implement classes and group them so that they are convenient to use. Since many have absolutely no UI, it seems that a subStack per class makes sense.

Normally I have 1 class per file.
It seems that LiveCode is really structured to only have 1 file open at a time, with all the code and UI contained in that single file.
This does NOT promote use of code in multiple projects.

What is the best way to get everything open at once (similar to an XCode project), yet not have to constantly copy modifications of code out to other files to be available for use in other projects?

If a class has any UI, the situation is more murky to me. In that case the class would likely be a button or similar object. It would not want its own Card or Stack. Independent of the class concept, how does one share the item and code with another project?

Thanks,
Andrew

[bwmilby]

ScriptOnly stacks are the way to go for shared code. Much of the IDE is implemented that way. In your project you will just need to be sure are all referenced in the Stack files tab of the stack properties. Having many files open is not an issue for LC but many projects can be self contained in a single stack.

All changes are in the GitHub repository. No real substantial changes. Mark’s code and mine are both updated to remove some of the excess code. I reordered the switch statement to make it easier to compare versions.

[mwieder]

Yes to script-only stacks as the way to go for sharing classes.
And you can promote them to substacks when creating a standalone app.

[aetaylorBUSBnWt]

Hi,

More learning and finding out about more implied knowledge that does not exist in non-expert Livecoders:
(and no, this is not obvious to a non-Livecoder at all)

When does a scriptonly stack get loaded?
What does it mean to load a scriptonly stack?
When/how does code in other files find out or can find out about the code in a scriptonly stack?
When/do you need to get rid of/destroy/release a scriptonly stack?
Not sure I have addressed it all because I don't know what I don't know.

First problem is the concept of making the code & local variables in a scriptonly stack available to the rest of the code in an application.

1. In your application's main stack, open the stack inspector, select the "Stack Files" tab. Then click the "Add stack files" button on the right.
1a. navigate to and select each of the scriptonly stacks you want to have available.
(This way you don't need to figure out where they are later.)

Now the application knows where to find the scriptonly stacks, but they are NOT actually usable yet!

That requires putting <start using stack "stackName"> statements somewhere for each of the scriptonly stacks.
I have not solved this yet, I have these statements in the script of a button I press before doing anything else.

Next, if you have code that needs to execute to initialize stuff in a scriptonly stack - when/how does that get called?
Well if it is script only stack, what does "start using stack" or "open stack" really mean? Which do you need or both?

"Start using stack" is required, always!
It does whatever stuff is needed so that the rest of livecode knows the scriptOnly stack exists and gives the stack a "long ID".
Then it calls a handler named "libraryStack", if you have one in your scriptOnly stack. There is a "long ID of stack "stackName" at that point. So the "libraryStack" is the earliest point in time that you can do any initialization in your scriptOnly stack.

Once you have done the "start using stack" call, then the rest of the code in the application can access that stack's handlers, but NOT before.

Also, once you have the "start using stack" call, then the scriptonly stack shows up in the Project Browser window. I have seen some scriptOnly stacks show up in the project browser when I open the application ".livecode" file, but never all of the scriptonly stacks that I placed into the main stack's Stack Files tab. (I have no preOpen handlers of any kind in any of the application's objects.)
At present I have no idea why some but not all of the scriptonly stacks show up in the Project browser window.

I have not discovered that "Open stack" is required (yet), remembering that these are scriptonly stacks, so there is nothing ever visible.
So, having preOpenStack or on Open stack handlers is not needed because they won't be called unless you explicitly "open" the stack, which is not the same as "start using stack". AND you can't call "open stack" prior to "start using stack" because the code does not know about the scriptonly stack until you call "start using stack".

I have not faced the "get rid of" / destroy stack moment yet. Still getting started.

I also have no idea how or if this affects things if you were to "promote" a scriptonly stack to a substack at some point.

Have I got at least the parts I addressed, correct?

[mwieder]

Interesting concepts/questions here.

First of all, are you talking about a standalone application here or are you dealing with stacks running in the framework of the IDE?

[aetaylorBUSBnWt]

Hi,

Ah, yes, yet another nuance that I am not aware of (yet)!

I am currently running exclusively in the IDE.

Someday, will need to operate as an application independently across multiple platforms

[mwieder]

OK. I have never found the need to assign stack files for anything I'm working with exclusively in the IDE. Only when I'm ready to package up something for a standalone application.

Here's what I do for a library stack that I want available generically in the IDE (and this applies to script-only stacks and other stacks):

For a .livecode stack:
place the code you want available in a button. In the card script of the stack say

Code: Select all

insert the script of button <buttonName> into back

that way the code will go into the backscripts and be available until you quit the IDE.
If you want to stop using that code then have a handler that says

Code: Select all

remove the script of button <long id of buttonName> from back

place that stack into your user plugins folder and start the IDE

For a script-only text file stack:
there are several options for handlers here.

Code: Select all

on preOpenStack
  if the name of this stack is <nameOfStack> then
    insert the script of this stack into back
  end if
end preOpenStack

and again place the script-only text file into your user plugins folder

[aetaylorBUSBnWt]

Hi,

OK, while I am currently running in the IDE, that is strictly for debugging purposes, not as an end target.
So, preferrably I am setting up the code and UI structures so that they are ready for deployment once development and debugging is done, without needing to rework stuff to run independently.

As I understand preOpenStack, if I do things your way, then the preOpenStack is the main stack and I have to constantly close out the main stack and re-open it anytime I make changes in the initialization process. And I have to do that debugging as the main stack file is being opened by Livecode - not fun to do.

If your code for preOpenStack is for a particular scriptonly stack, then preOpenStack is only called after you make an "open stack" call, which you can't do until you do a "start using stack" call. In all of my code so far, I have no reason to "open" the stack that I have seen.

The reason that I add the scriptonly stacks to the main stack's stack file list is so that I don't have to be aware of where the scriptonly stack's file is located on disk, I just need to know its name.

or am I missing the point?

[mwieder]

The reason I suggested putting the stacks into the user plugins folder is that the IDE loads them on launch so you don't have to do any extra fiddling around with 'start using' or remembering where the library stacks are.

[aetaylorBUSBnWt]

Is the user plugins folder a reasonable place to put scriptonly stacks while they are under development and needing active debugging and modification?

While the IDE loads the scriptonly stacks on launch, wouldn't that mean that everytime I make a change to the initialization of a scriptonly stack (the libraryStack handler), then I need to quit Livecode and restart it?