Au++

[Shaggi]

So i begun my next big project. I always liked AutoIt for the simplicity, but it has some obvious lacks and features like object orientation (no pun inteded though). I tried out the AutoIt object UDF which worked fine, however it wanted something that would reflect a normal syntax instead of wobbly adds and a huge library needed. Also, that it isn't based on a entire com-linkage. And, of course, speed.

How should something like that be done? Since autoits syntax doesn't allow something remotely close to class definitions, it has to be done as a preprocessor (remember what Bjarne did to C? Hence the name ) This might be unappealing for some, but it's a part of the project to implement it through scite like aucheck for instance. Since we're doing a preprocessor anyway, im going to implement standard features from the C preprocessor, like #define (not working yet though).

The program is currently in a crude alpha version, but it works pretty well, and is able to convert something like this into well optimized autoit code:

Some might recognize the syntax from C++, which it follows.

Syntax

Class <ClassName>
    <Public or private scope>:
        Local <Vars>
        Function()
        Object <Objects>
EndClass
    
Func <ClassName>::Function()
EndFunc

You should be able to figure it out from the included example, though. Oh yeah, and inside member functions, you refer to the object with "self." (like in Python or "this." like in c++/c#) - this is automatically passed to the function.

Features

• Make object oriented programs and -syntax through classes.
• Supports constructors / deconstructors
• Automatic deconstruction of objects on AutoIt shutdown.
• Works with multidimensional arrays.
• Outputs highly optimized code.

I know the list isn't so impressive yet lol.

I would have wanted to wait a little longer before releasing, but it needs some testers and i need some inputs on the various problems it has:

• Fix a problem with syntax errors if no instances of an class is found
• Fix detection of manual deconstruction (ie. $Object = 0)
• Make syntax generation for objects inside objects
• Fix inheritage
• Allow With...EndWith statements?
• Fix public / private.
• Eval / execute / assign etc. wil probably never work, since they're evaluated at runtime.

If anyone out there's interested in something like this, i will continue developing on it, but i was hoping that someone maybe wanted to join the project, help or contribute some ideas. Most of the problems in the list isn't serious, but i'm having a hard time figuring out how to create objects inside objects... But i figured it would have something to do with multidimensional arrays.

It really also needs testers, it would help a lot of someone would test it out, write some scripts and report back if it worked / had any bugs.

About the program

The program works by analyzing each class, and create a set of functions which takes an instance as the first argument (done automatically). The object keeps track of itself through global arrays, where each element of the array represents an instance of the class. The functions are therefore reusable.

The syntax detection in the program isn't done at all yet, however the structure of the program is built up like i wanted it too. Every element of the parser is split up into several functions, so each bug can be fixed by changing that one function.

What's in the download?

• The program (Au++.au3)
• Some includes (String functions and Preprocessor)
• An example of a rather cool graphic program using more than more instance of several classes to show the usefullnes of classes (IMO)

How to use it?

Firstly, this is mostly intended for developers - but the source should be somewhat explainable. If you just want to experiment, edit the "Class Example.au3" in the folder, and run Au++.au3. It will output a source file called "Textdump.au3" which is the converted script.

~Shaggi

Au++ Preprocessor.zip

Edited April 16, 2011 by Shaggi

[Kip]

Can we still use COM objects without the preprocessor messing up anything that has a $Object.property syntax?

Since we're doing a preprocessor anyway, im going to implement standard features from the C preprocessor, like #define (not working yet though).

Why would you want to add that piece of Bad Coding to Autoit? #define is a bug-magnet. Edited April 16, 2011 by Kip

[Shaggi]

Can we still use COM objects without the preprocessor messing up anything that has a $Object.property syntax?

Yes. It looks for the variable name in the first place, after that it analyzes the syntax.

[Kip]

Yes. It looks for the variable name in the first place, after that it analyzes the syntax.

That's where I was a affraid of. Too bad for you, AutoIt isn't a staticly typed language (if it was, your approach would work just fine)

For example: if I change a small bit of your provided Class Example.au3:

$ChildHe = Gui("Transparent Child")
$Child = $ChildHe
$Child.Width = 400
$Child.Height = 400

It crashes. Edited April 16, 2011 by Kip

[Shaggi]

That's where I was a affraid of. Too bad for you, AutoIt isn't a staticly typed language (if it was, your approach would work just fine)

For example: if I change a small bit of your provided Class Example.au3:

$ChildHe = Gui("Transparent Child")
$Child = $ChildHe
$Child.Width = 400
$Child.Height = 400

It crashes.

That can be fixed pretty easily, but fullblown dynamic checking would be impossible to implement. Since it's a preprocessor, evertything has to be statically typed out. Your example however is a static assignment since it can be determined at pre-compile time.

It keeps a table over the relations between keywords (like the object name), instance and class. A simple check would make your code work.

Why would you want to add that piece of Bad Coding to Autoit? #define is a bug-magnet.

#define is IMO an lifesaver. It makes compability through revisions and different systems a lot easier, plus it allows more readable code instead of a spaghetti of advanced code. Besides, #define holds the unique feature in not using memory space when using it like a constant, and simple function-like macro's wont require a full function. Edited April 16, 2011 by Shaggi

[Kip]

That can be fixed pretty easily, but fullblown dynamic checking would be impossible to implement. Since it's a preprocessor, evertything has to be statically typed out. Your example however is a static assignment since it can be determined at pre-compile time.

It keeps a table over the relations between keywords (like the object name), instance and class. A simple check would make your code work.

Ok, another example:

Thing(  Gui("Title")  ); // class
Thing(  ObjCreate("AnyObject")  ); // COM

Func Thing($Obj) 
$Obj.Width = 400;
EndFunc

I'm going to ignore everything you've said about #define, because that's just your style of coding (a bad style, though). Except this one:

Besides, #define holds the unique feature in not using memory space when using it like a constant, and simple function-like macro's wont require a full function.

Your preprocessor could just replace every variable declared with Const with their corresponding value. That doesn't require the need of an extra keyword. Edited April 16, 2011 by Kip

[Shaggi]

Ok, another example:

Thing(  Gui("Title")  ); // class
Thing(  ObjCreate("AnyObject")  ); // COM

Func Thing($Obj) 
$Obj.Width = 400;
EndFunc

I'm going to ignore everything you've said about #define, because that's just your style of coding (a bad style, though). Except this one:

Your preprocessor could just replace every variable declared with Const with their corresponding value. That doesn't require the need of an extra keyword.

It's a subtle addition that noone demands you to use. AutoIt Wrapper adds 30+ extra directiories like #define at compile time too, remember. Some like defines, some apparantly dont lol - but conditional inclusion cant be done without, for example. But fuck it, it's not what this topic is about.

I do fully understand what you are trying to proove. Firstly, i would like to say it isn't imposibble to fix yours, because the code still tells the exact assignments; it is therefore only a matter of advanced analysement. Here's an example of what wouldn't work, because it can in no way be determined at compile-time:

$Object1 = Gui("lolo")
$Object2 = ObjCreate("omg.lol")

ConsoleWrite(Execute("$Object" & Random(1,2,1) & ".member"))

[Kip]

it is therefore only a matter of advanced analysement.

You just won't learn, do you?

$obj = ObjCreate("a");

for $i = 0 to 100

if Mod($i,4) then
$var = InputBox(...)
if $var > 0 then
$obj = Gui("title");
elseif $var < 0
$obj = ObjCreate("hi");
else
$obj = "Not an object at all";
endif

endif

Thing(  $obj  ); 

next


Func Thing($Obj) 
$Obj.Width = 400;
EndFunc

Edited April 16, 2011 by Kip

[Shaggi]

You just won't learn, do you?

$obj = ObjCreate("a");

for $i = 0 to 100

if Mod($i,4) then
$var = InputBox(...)
if $var > 0 then
$obj = Gui("title");
elseif $var < 0
$obj = ObjCreate("hi");
else
$obj = "Not an object at all";
endif

endif

Thing(  $obj  ); 

next


Func Thing($Obj) 
$Obj.Width = 400;
EndFunc

Nice attitude you're bringing..

Something like this cannot be done, you're right. Didn't you read my other example? There's a difference between this example and your other - this conditionally creates an object - this is determind at runtime. The other doesn't - it can be determined by compile time. It should by the way be the scripters responsibility to not write faulty code like this.

[nooby]

looks like an interesting approach, i'll definitely be taking a look at this when i have time.

You just won't learn, do you?

.. easy there Kip, stop acting like you're so much smarter than everyone.

[JScript]

I always liked AutoIt for the simplicity, but it has some obvious lacks and features like object orientation (no pun inteded though).

(...)

~Shaggi

I'll be honest with you: your project is very good!

But why complicate a language that you yourself said "simple."

With things that even the developers have no interest in implementing!

AutoIT is designed for automation, but we even prove that this language "simple" is capable of much more ...

Well, continue with the project, as I said is very good!

[JScript]

looks like an interesting approach, i'll definitely be taking a look at this when i have time.

.. easy there Kip, stop acting like you're so much smarter than everyone.

I fully agree with you!

[twitchyliquid64]

Why Write a PreProcessor when you can go to the trouble of a full blown autoit += au++ interpreter?

On another note; nice work.

[jvanegmond]

Is inheritance supported? I've been poking around in source code but can't find any mention of it. It would make this a lot more useful.

[Shaggi]

I'll be honest with you: your project is very good!

But why complicate a language that you yourself said "simple."

With things that even the developers have no interest in implementing!

AutoIT is designed for automation, but we even prove that this language "simple" is capable of much more ...

Well, continue with the project, as I said is very good!

Thanks. Why? Because i think it's a cool style of programming that allows much better code and a lot less braining. But you're probably right, AutoIt just isn't suited for this. I was just hoping something like this would be implemented in the core, since it already has syntax checking and that stuff. Sadly, the code is CS so all the people with ideas wont be able to help

Why Write a PreProcessor when you can go to the trouble of a full blown autoit += au++ interpreter?

On another note; nice work.

hihi

Is inheritance supported? I've been poking around in source code but can't find any mention of it. It would make this a lot more useful.

Nah i kinda quitted this project, it was the next step but seeing as people get offensive when you're trying to add something to AutoIt i kinda lost the motivation.

[Sapient]

Nah i kinda quitted this project, it was the next step but seeing as people get offensive when you're trying to add something to AutoIt i kinda lost the motivation.

I for one would like to see AutoIt support object orientation, but of course it should be builtin and not require an extra module.