include / require

[monte]

... scroll up: 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...

More like this:

Code: Select all

--in parent
  doAGrandParentThing
   ...

--in protected grandparent
protected command doAGrandParentThing
  ...

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

[mwieder]

More like this:

Aha! I thought you were talking about protecting the whole script somehow.
So "protected" would work like it does in java.

[monte]

So "protected" would work like it does in java.

Yes if you ignore the package concept which I don't think we have an equivalent of...

[mwieder]

No problem
I can ignore packages in my sleep.
With both hands tied behind my back.

[DarScott]

Perhaps functions and properties would work better than global constants. If folks are concerned about performance, then maybe these can be a place of focus for that.

[DarScott]

I'm looking for what advantage adding to the language for require has over simply using start using.

It might be nice to be able to create several kinds or levels of blocking commands beyond that kind in the libURL GET or some engine commands. One level of virtual blocking would allow callbacks and event messages to the object that does the blocking but all others are stalled and GUI events are not not handled (whatever that means). A variation on this would be to also allow callbacks and messages to the object, and to all objects in the require list, recursively. Presumably, that would allow all required libraries to be able to do that is asked of them. Of course, some other method might be used to effect this level of blocking, if it is desired, but a tree readily available to the engine might be handy. Of course, maybe some discussion might indicate this is not important. Perhaps this needs some pondering in the expectations of blocking.

(Similarly, it would be nice to have an option for a more relaxed blocking in externals like that of GET, but I put wrappers around externals, so that is less of an issue.)

And, as I mentioned, it might be nice for different libraries to require different versions of the same library. Maybe there are better ways to address this problem.

So, I can see that there might be advantages to adding to the language, but for the most part, I don't get the motivation.

I wonder if require exposes compiling on the fly to the meaning of the language. It might not be transparent.

[mwieder]

I'm looking for what advantage adding to the language for require has over simply using start using.

My motivation was to allow local private library access to an object; "start using" places the library in the message path for *all* objects.
But I think we can achieve the same sort of thing with behaviors, so I'm not pushing this.

I'd still like to see "include" available universally, though.

[edgore]

For me the advantage is just portability. This is just from a developer perspective, not someone that understands the complexity of all the engine stuff.

Right now the only really effective way to code and debug for server is to work in the desktop IDE, then copy and paste the scripts out of the IDE and into .lc text files for use on the server. This results in a lot of extra work doing things one way for the desktop environment, and then another way for the server environment and then commenting stuff in and out as you test and edit between them.

Include/require is just one of these. I am not sure how you solve this issue other than either making the server specific commands available in all environments or creating an IDE for writing and debugging directly against the server engine/environment.