An object oriented language for Empty4

[roger-write]

I've updated oq on the first page with v0.95, as well as all the example files. Changes to oq.exe:

- I no longer allow it to delete all the files in target. I felt this was too dangerous for newbies. Don't want someone accidentally deleting a bunch of files.

- You now specify a Project name in the build file. This will be the name of the created .mq4 and .ex4 file (instead of Classes.mq4).

- Changed Combine to a Y|N option

- Got rid of Query since it's no longer needed (not deleting target files anymore)

- Fixed a couple of things, including one more nasty thing with static inheritance. Should work ok now.

Thanks to Steve for allowing me to post .oq files directly instead of having to zip them.

[roger-write]

Attached you will find an oq file that contains a primarily static class called Err. It allows you to use Err:Init() to direct error messages to either the standard terminal window, or to a file you name, or to both at the same time. Then you use Err:Msg to write an error message. Nothing too clever. But I want to show how you can install your own custom error handler using static inheritance.

So let's say you have a large code base and whenever it encounters an error, it calls Err:Msg. But you're creating a custom EA and would like to change the behavior of what Err:Msg does. But the key is, you don't want to have to go through all the code changing all the calls to Err:Msg (which ultimately leads to a sw maintenance nightmare).

Here's what you can do:

Code: Select all

class MyErr
{
    static void Msg(string method, string description) : Err
    {
        <code to do your own error handling>
    }
}

With the above installed in your project, whenever Err:Msg is called, your function will now get called INSTEAD of the old function. You've effectively just installed your own error handler. Now, if you still want the old behavior to happen in addition to something you want to do, just call the parent with the '$' as follows:

Code: Select all

class MyErr
{
    static void Msg(string method, string description) : Err
    {
        Err:Msg$(method, description);  //  Do the old behavior
        <code to do your own error handling>
    }
}

Note that you do static inheritance a little different than you do instance inheritance. That is, instead of specifying the parent class after class MyErr : Err you specify the parent class after the static method definition instead. If anyone is really interested why that is, I can explain why I chose to do it this way.

So that's an example of inheritance on a static method for the purpose of overriding the existing functionality.

Error.oq

[roger-write]

The other case I could think of for static method inheritance is for extending existing behavior, rather than simply overriding it. I've already used this in my own code to great effect. Here's the example:

In the framework I'm working on, I have resource values. Various modules use certain resource values. Think of them a little like the input values that Empty4 provide, but much more comprehensive with categories, etc. I wanted to be able to validate these resources when the EA first runs to make sure it has what it needs (rather than waiting until it tries to open a trade or something and finding out it doesn't have what it needs). Using standard mql you would do something like this:

Code: Select all

int init()
{
    <validate resources for module 1>
    <validate resources for module 2>
    .
    .
    .
    <validate resources for module N>

    <do whatever else you need to do>
}

The problem with the above is that whenever you create a new module you have to remember to go back to init and add the validation code there. Or what if you build a custom EA and want to only use certain modules, for example. Then you have to keep hacking up init to make sure it validates the resources you need for specific modules. Using oq with static inheritance there is a much better way to handle this. Consider the following:

Code: Select all

int init()
{
    bool success;
    Resource:Validate(success);
    if( !success )
        { Err:Msg("init", "Invalid resource found"); return(0); }

    <do whatever else needs to be done>
}

The above code in init never changes, no matter how many modules requiring resources is added to the project, or removed or changed. Down in the Resource class you have the following:

Code: Select all

class Resource
{
    static extend void Validate(bool& success)
    {
        success = true;
    }
}

Note that this function probably would do very little if anything, other than being a placeholder. Pay particular attention to the keyword 'extend' which comes right after the word 'static'. This tells oq that when a method inherits from this method, it will extend the behavior instead of overriding it. Now, whenever you create a module that requires resources to validate, do the following:

Code: Select all

class MyModule
{
    static void Validate(bool& success) : Resource
    {
        if( !success ) return;
        <do your resource validation - set success to false if fails>
    }
}

What happens now is that because you specified 'extend', whenever Resource:Validate is called, the original function will be called FIRST. Then ANY OTHER modules that have inherited from Resource:Validate will get called as well.

The net effect is that you've done no hacking whatsoever in any other module other than the module you are directly working in, and everything just magically works.

Let me know if further clarification is needed.

[mjws00]

Roger,

This is a very cool and ambitious project. I'm certainly watching with interest. Just thought it might be nice to know there are more interested folks. I like my OOP. Haven't gone deep enough to try this variation you've created yet. But it certainly has potential.

Mike

[roger-write]

Thanks for the encouragement. I realize change doesn't come easy, but I'm working on this project regardless and it helps to clarify my thoughts by writing out the details.

[SteveHopwood]

Roger, you appear to be plowing something of a lonely furrow here.

I have lost a couple of brushes with OOP over the years, getting lost in a morass of classes, inheritance and gawps know what else. Maybe I am too dim to take it all on board *ignores confirmatory bellow of, "Yep, fella. Got it in 99" from offstage*; maybe it was all too badly explained; maybe I just wasn't ready for it.

Whatever. What I am trying to explain here is why I have not contributed here. I may try to come to grips with it one day. For now, I am simply too busy.

As a hack coder who holds Proper Programmers in awe, I am vastly impressed by what you are attempting to do here. I have done the very least I can do, which is to make this thread a 'sticky' so it cannot drift off into oblivion once you have finished posting. Hey, who knows? Maybe in a couple of weeks time you might be discussing abstruse points with the Brains Trust here. I hope so.

If there is anything else I can do to help, you only have to ask.

[banzak]

Hi Roger,
this sounds very interesting and i will give it a try to convert my existing ea. If you need some help with your manual, I will help you.

Regards,
Banzak

[roger-write]

Thanks for the comments Steve and banzak. I personally won't have time to start on the manual for a bit, but I suspect some of what I've already posted here could be recycled into the basis of a manual.

The other thing I'm thinking is that oq may not fully catch on until there is something developed in it that people want and need. Then there will be no choice but to download it and use it to Buld the project.

For me OOP has been a journey that started back in the early 90's when the company I worked for brought in a guy to teach the engineers what it was all about. It sounded cool, but it took me awhile and several projects to appreciate how elegant well-designed OO code can be. But I remember at first it felt like I was trying to code while standing on my head. Instead of just blasting out miles of code from your fingertips, I had to actually think more carefully about how to structure things. And in some ways, I think that is at least part of the point.

[banzak]

Thanks for the comments Steve and banzak. I personally won't have time to start on the manual for a bit, but I suspect some of what I've already posted here could be recycled into the basis of a manual.

The other thing I'm thinking is that oq may not fully catch on until there is something developed in it that people want and need. Then there will be no choice but to download it and use it to Buld the project.

For me OOP has been a journey that started back in the early 90's when the company I worked for brought in a guy to teach the engineers what it was all about. It sounded cool, but it took me awhile and several projects to appreciate how elegant well-designed OO code can be. But I remember at first it felt like I was trying to code while standing on my head. Instead of just blasting out miles of code from your fingertips, I had to actually think more carefully about how to structure things. And in some ways, I think that is at least part of the point.

Hi Roger,
so I will start to collect all your posts here an start a manual, I will send you the draft when I'm finished.

Another question: How is the performance eg. in backtests, cause with my latest ea a backtest take me with 90% tick-data about 4 hours for a year.

Regards,
Banzak

[roger-write]

One of the goals I had going into this project was to be able to dynamically add or extend functionality to an existing library (I even named the framework I'm creating using oq: Joinable & Extenable Trading System - JETS - and, no it has nothing to do with the sports team just an easy way to remember it). And to do this with little or no additional coding to the rest of the library.

There was one piece missing, and I believe I worked it out last night. Normally in OOP you create a subclass object by calling the subclass constructor. For example, in the example Data.oq module posted at the beginning of this thread, to create a Double object, you call Double:New, but then you can refer to the object using the Data interface. And oq does this just fine. Notice that Data does not have a constructor. If you tried to create one, you'd scratch your head and say what am I creating? It's like asking God to create a felidae without specifying what kind of cat? You want a house cat or a tiger? Big difference if you have to live with the results.

But there is a case to be made for being able to call the superclass constructor and have it morph into what you want. In the normal case listed above, you have to add some code somewhere that specifically calls the subclass constructor. But what if you didn't have to, assuming the signatures (or argument list) are identical? What if you could call a superclass constructor with only the kind of thing you want and have it morph and return the kind of object you want?

Consider the following: Let's say you have a high level class called Trader. The Trader gives you some general methods like Refresh, but a subclass of Trader can be designed to manage a series of trades in any way you want it to. Maybe you want a Trader that opens a full size trade and then scales out as you come into profit, or whatever ( ScaleOutTrader). Think of an EA where as one of the input parameters you actually give the name of the kind of Trader you want it to use. The EA code looks up the name and finds a kind value which gets passed to the superclass constructor, Trader:New(kind, heterogeneous_list) and it returns an object ID to a ScaleOutTrader. The EA code deals with the object as a Trader and doesn't care what kind it really is. Basic OOP stuff.

But the implications are, I can then at some later point develop a new kind of Trader, lets call him ScaleInTrader, install it into my project and never touch another piece of code in the project and it will just work. Soon I'll post the way you create a morphable superclass constructor with oq, along with yet another update to make this happen.