CML "Inlcudes"

[bph]

Can I "Include" a file (not import a class)?

Once I get a method working, I'd like to just park it off in an included file so that I don't have to scroll through it or risk accidentally typo-ing in it while working on other parts of the macro.

{$I File.txt} for you old Turbo Pascal fans.

[Dean Roddey]

You can't physically include one file in another. The Import section is where you import other CML classes to use. It works with your own other classes just as it does with the built in runtime classes.

You don't want to get into having a class per file or anything, and you shouldn't separate out code just to be separating it out. But if your class is too large and you have some code that is purely just operating on passed in parameters, it's not unusual to create a helper class (just create it in the same namespace scope) and move that code there and import it into the main class.

[bph]

Originally Posted by Dean Roddey

You can't physically include one file in another. The Import section is where you import other CML classes to use. It works with your own other classes just as it does with the built in runtime classes.

You don't want to get into having a class per file or anything, and you shouldn't separate out code just to be separating it out. But if your class is too large and you have some code that is purely just operating on passed in parameters, it's not unusual to create a helper class (just create it in the same namespace scope) and move that code there and import it into the main class.

What do you mean "create it in the same namespace scope"?

Let's say I have a method DoStuff() that I want to use in several of my classes.

If I copy and paste it into all of my classes, each one can just call

DoStuff()

But if I make it into a helper class, each one has to:

IMPORT DoClass

Members=
DoClass DoMember


and then each time its' used:

DoMember.DoStuff()

Which is okay, i suppose, just takes more getting used to a helper function being part of an object class.

(Remember: Not a C guy. :) )

[Dean Roddey]

The name space is the /User/Whatever/ scope. If you are moving code out just to keep the main class less cluttered, then then you'd probably just create another class in the same scope. If you are genuinely creating general purpose stuff, then you might want to put it in a more common area like /User/MyHelpers/ or some such thing.

If you created a class /User/MyHelpers/FooBar, then you'd import it into some other class using its class path:

Imports=
    User.MyHelpers.Foobar;
EndImports;

Then you can create FooBar objects and use them. As I said, you don't want to get into creating a single class per method or anything like that. You want to think in objects. But, it's always possible that you'll end up with some kind of utilties type of class that just provides a collection of methods that just act on the parameters passed (i.e. they don't really share any class members.)

[bph]

Originally Posted by Dean Roddey

The name space is the /User/Whatever/ scope. If you are moving code out just to keep the main class less cluttered, then then you'd probably just create another class in the same scope. If you are genuinely creating general purpose stuff, then you might want to put it in a more common area like /User/MyHelpers/ or some such thing.

If you created a class /User/MyHelpers/FooBar, then you'd import it into some other class using its class path:

Imports=
    User.MyHelpers.Foobar;
EndImports;

Then you can create FooBar objects and use them. As I said, you don't want to get into creating a single class per method or anything like that. You want to think in objects. But, it's always possible that you'll end up with some kind of utilties type of class that just provides a collection of methods that just act on the parameters passed (i.e. they don't really share any class members.)

But, I'm confused by what you mean by "same".

Imports=
    MEng.System.Runtime.MemBuf;
    MEng.System.Runtime.CommCfg;
    MEng.System.Runtime.CommPort;
    MEng.System.Runtime.ConsoleOutStream;
    MEng.System.CQC.Runtime.CQCFldDef;
    MEng.System.Runtime.StringTokenizer;
    MEng.User.CQC.Drivers.Enviracom.FieldInfo;
    MEng.User.CQC.Drivers.Enviracom.EnviracomWorkMethods;
    MEng.User.CQC.Drivers.Enviracom.MyLittleHelpers;
EndImports;

Works exactly the same as:

Imports=
    MEng.System.Runtime.MemBuf;
    MEng.System.Runtime.CommCfg;
    MEng.System.Runtime.CommPort;
    MEng.System.Runtime.ConsoleOutStream;
    MEng.System.CQC.Runtime.CQCFldDef;
    MEng.System.Runtime.StringTokenizer;
    MEng.User.CQC.Drivers.Enviracom.FieldInfo;
    MEng.User.CQC.Drivers.Enviracom.EnviracomWorkMethods;
    MEng.User.CQC.MyLittleHelpers;
EndImports;

Doesn't it?

And, I am correct that I have to import it, instantiate an object from the class, and call the methods of that obects? I can't just import a class and then call a method as if it were a command or built-in feature. In other words, there is no procedure library, save being a method of an object from an imported class, right?

[Dean Roddey]

I don't understand what you are asking with the two examples above. If you are doing a driver (not a regular macro), then yes you would put the helper classes into the same scope as the driver. I was assuming just a general macro in my example above, but whatever the class path of the helper is, just import that (and I forgot the MEng. part in my example above BTW.)

But, if it's a driver, you wouldn't want the MyLittleHelpers to be where you show it in the example above. If it's for use by the driver, put it in the same scope as the driver itself so that they are all together.

There are only objects in CML. It's an OO language, not a procedural language, so there are no free floating procedures to call. All code is associated with classes. However, as I said above, in some cases you can do a class which is purely just a set of utilities, which has no members because the methods aren't really acting like a regular class but are just processing input parameters and returning values in output parameters.

[Dean Roddey]

In cases where you have a set of drivers that deal with a common protocol, you might do something like:

...\CQC\Drivers\Acme\Probes
...\CQC\Drivers\Acme\Probes\Common
...\CQC\Drivers\Acme\Probes\Model1
...\CQC\Drivers\Acme\Probes\Model2

That kind of thing. I.e. you create a scope for Acme products, and then there's a family of probes that are different enough that they need separate classes, but they share a lot of code. So you create a Probes\Common scope and put some common classes there, and then create separate Model1, Model2, etc... scopes for the separate specific devices.

But if you are creating methods that are truely general purpose so that you'd need it in many drivers and it's not specific to any protocol or driver, then it's something that perhaps should be added to the CML runtime, where it can be done in the most efficient way and be available to all.

[bph]

Originally Posted by Dean Roddey

If it's for use by the driver, put it in the same scope as the driver itself so that they are all together.

For convenience?
For ability to make a driver pack?
For functionality?

I'm asking a "why" question. :)
(So, feel free to answer "Because some guy at CQSL said so.")

[bph]

Originally Posted by Dean Roddey

But if you are creating methods that are truely general purpose so that you'd need it in many drivers and it's not specific to any protocol or driver, then it's something that perhaps should be added to the CML runtime, where it can be done in the most efficient way and be available to all.

You mean, convince you that my code is good enough to ship with CQC? Sure. Ya. Right. :)

[Dean Roddey]

For convenience? For ability to make a driver pack? For functionality?

To prevent the polution of the CML namespace and avoid clashes mostly

You mean, convince you that my code is good enough to ship with CQC? Sure. Ya. Right. :)

Not your code actually. I'm just saying that if you are finding the need for something all the time, then let me know because I can provide an implementation of that functionality in the runtime perhaps if it's widely enough needed.


Keep in mind that if this stuff is just for your own use, you can put the classes wherever you want. But if it's for a driver that'll go into the release, I'd prefer not to have the driver depend on CML classes that are spread around and might clash with other folks creating similar helper classes.

And very commonly used code would be better imlemented in C++ and provided as part of the CML runtime (with just a simple CML wrapper around it) than distributed as actual CML classes.