include / require

[mwieder]

Since server scripts can use the "include" command to include other scripts, is there any reason to restrict that to server engines?
I want to, for example, define my stack constants *once* and include them in object scripts when necessary rather than having to declare them all over again.

<start pie-in-the-sky rant>
Going farther than that, how about both "include" and "require", where

"include" would insert the included script inline, and
"require" would make the script available as a local library, acting the way a behavior script does, but without the global effects of "start using".
This would allow mix-ins without the need to add a mechanism for multiple behaviors at the same level.
<end pie-in-the-sky rant>

[monte]

What should happen on require if the object isn't available?

There's a reasonable argument I think for constant inheritance which might resolve some of the issue here.. what happens to the message path with require... do all child objects have the script in their path just like a behavior or is it a private library? I like the idea of a private library because it allows you to create an abstraction layer without exposing the underlying layers to the message path... However, I've been jumped on before for attempting to interfere with the message path so I hesitate to suggest it...

[mwieder]

Well, I think of behaviors as private libraries anyway.

What should happen on require if the object isn't available?

Hmmm... good question... I'll check with my ruby expert and see what happens there.

[monte]

Behaviors aren't private libraries.. they are public to all the children... I'm talking about something akin to a private handler but the ability to introduce a whole script in that way...

[LCMark]

Since server scripts can use the "include" command to include other scripts, is there any reason to restrict that to server engines?

Yes - those commands are there in the server engine because they are suited to that environment and style of programming - the server engine was designed to work very much like PHP but with LiveCode syntax. Just because that works there does not mean they work in an editing environment like the IDE.

I want to, for example, define my stack constants *once* and include them in object scripts when necessary rather than having to declare them all over again.

Ah, the global constant chestnut

To me, incorporating the ability to include files here there and everywhere, or reference scripts as files here there and everywhere goes against the grain of what LiveCode is (as an IDE/App-Editing system, rather than a server script processing system). I'd rather that a more LiveCode-esque solution (yes, I realize I'm not defining that at all really - but I have a very strong 'gut sense' about what it is) were found to the issues that being able to use files in the ways proposed solve.

A big part of my motivation here is that we need to move towards a model where an app is described as a whole to the engine (including all resources and such it uses - nothing hidden away, or awkward to work out). One of the reasons for this is that it means 'whole app analysis' in whatever context is desired is possible and straightforward - whether this be tools in the IDE that identify problems, or the standalone building part which would then have complete information to produce much more efficient binaries at the backend (or, at the very least, know what needs to be included in the app so that you don't have to add lots of things manually to the 'Copy Files' pane and such).

Apart from 'gut sense', one argument why 'pure' files are not the way to go is that they are too low-level: the IDE will still need to manage and track them and this job is made harder (and not necessarily 100% possible) if they are hidden away in commands and such inside scripts. If it has to go to all this trouble, then this means it is going to have maintain internal structures to do so, so why not make those internal structures the concepts that you use - rather than files directly.

So, before jumping to the answer (files solve everything), let's list the problems (and perhaps some examples) that are currently faced by developing apps that you can see the file suggestion solving and then step through them, work out which are the same problem and which are different and then be a bit more 'pie-in-the-sky' about potential solutions.

[monte]

I think there's two concepts here that might be better discussed separately... include/require could be implemented with an object reference...

The only reason I can think of to use include is to share variable and constant declarations... perhaps there's other ways to do that... maybe a property of a behavior object?

The only reason I can think of to use require is to have a private library that is not exposed to the message path of all the child controls... Otherwise we may as well use a behavior and extending behaviors to mix in gives is just one way to do the job rather than two...

As for the text file scripts I was just thinking out loud that if we are talking about faceless objects that have no metadata other than scripts then they could just be file references... There's other ways to achieve a similar thing... all objects could get a scriptFileName property for example which could work like the image filename where you can either reference or embed. Whether there's any advantage to doing that I don't know... from a vcs perspective exporting the scripts is the least complicated part of the whole thing...

[LCMark]

Again - step back - ignore any implementation details and articulate the actual problems that you are wanting to solve.

From this thread (and in the other thread this topic came from) so far there seem to be several:

• global constants
• 'private' libraries - this needs a little more definition
• splitting up scripts into more manageable units - inferred this from the topic on the other thread about leveraging files and being able to 'include' stuff in scripts
• script re-use across objects - again, kind of inferred this from the topic on the other thread with relation to a script being loaded from a file

This is just my interpretation of what has been said - it could be that you guys mean something entirely different in each case... Which is why it's important to present use-cases, examples and analyse it from a top-down perspective. That way you can be sure features that are designed actually solve actual problems that need to be solved and do so in a synergistic way with everything else.

[monte]

I think the constants is an obvious one... I'm not convinced global is a good idea... I'd prefer inheritance. I don't really find this a big problem... but it's annoying when it pops up and you realise you're introducing a maintenance headache... Ideally constants could be set in the project metadata....

Private libraries is the other one... this is about creating layers of abstraction and keeping the message path clean... I don't think @mwieder had it in mind though and I think I've come up with a better implementation idea.. Think behavior where the handlers are only accessible to the child... The new idea I had was to have a protected type of handler for behaviors which allows those handlers to be called only from the child control (not the whole behavior tree either) just like private handlers can only be called from the same control...

Imagine the scenario of a db access library and a library that uses it manage a specific data model... The rest of the app doesn't need to have the db access library in it's message path...

[mwieder]

I don't think @mwieder had it in mind

I was thinking more of shadow libraries in the way behaviors are placed in the message path. Since we can use behaviors for essentially the same purpose, I don't think this one is necessary.

What would be the advantage of a private library?
If all the routines are private, why not just put them inline?
And if you need to use them in multiple objects, why not use a behavior?

[mwieder]

@runrevmark- here's a use case where some kind of "include" feature would be useful:

Some time back on the revinterop listserv we were exploring Ken Ray's suggestion of creating a stdlib library of common handlers that we use all the time.
What would be really useful would be the ability to break this down into components instead of a single library script:

Code: Select all

stdlib:
  include stack "libMath"
  include stack "libGeometry"
  include stack "libStrings"
  etc.

This would allow different developers to take ownership of working on different parts of the standard library, allow new libraries to be added as needed, and provide easy maintenance in a single umbrella file.

[monte]

And if you need to use them in multiple objects, why not use a behavior?

Well I am suggesting using a behavior now... Just adding a handler variant that uses the protected keyword to describe that it can be called from itself and an object that has it as a behaviour... This enables behaviors to create layers of abstraction rather than one big blob of handlers all in the message path of the children...

[mwieder]

@Monte- since behaviors are already self-contained and have to be linked explicitly, I don't see how the message path gets polluted.
I'm failing to come up with a problem that needs solving.
Is this another case of you trying to implement a "don't pass" flag?
Do you have a use-case in mind?

[monte]

@Monte- since behaviors are already self-contained and have to be linked explicitly, I don't see how the message path gets polluted.

The children have the behavior's handlers in their path

I'm failing to come up with a problem that needs solving.

Abstraction

Is this another case of you trying to implement a "don't pass" flag?

hehe.. could be It's not the same thing and there is a precedent for limited scope handlers with private... You use private when you don't want to pollute the message path with code that should only be called by the object... you could use protected to avoid polluting the message path of objects that don't have their behavior set to the object.

Do you have a use-case in mind?

Yes... when we have a behavior hierarchy and this we can create layers of abstraction with clearly defined apis... see my use case with the db access library and data model.

[DarScott]

I wonder what the concern with 'start using' is.

Is it because it is a command and not a declaration?

Is it because it does not allow different libraries to use different versions of sub-libraries easily?

[mwieder]

The children have the behavior's handlers in their path

Ah... I think I'm getting what you're driving at here...
So a protected script in a behavior chain would *only* have scope in the next behavior, not down the line.

Code: Select all

--in parent
protected behavior "GrandParent"
on doAParentThing
  doAGrandParentThing
   ...

--in protected grandparent
on doAGrandParentThing
  ...

--in target
doAParentThing
doAGrandParentThing -- throws an error
  ...

see my use case with the db access library and data model.

OK - do you have a link for that?