Sign in to follow this  
Followers 0
GEOSoft

Just for discussion

67 posts in this topic

#1 ·  Posted (edited)

I've just been going over the AutoIt history and got to thinking (yes, thats what you could smell) about the current state of AutoIt

Version 1 lasted about 8 months

Version 2 was with us for just under 3½ years

Version 3 has been around for almost 4 years now (from first stable release)

When I look in feature requests and I see comments by the devs similar to "had we done such in such this way then it might be possible". Or "I wish I had never introduced that" and the ever popular " We should have used method x instead of method y to begin with". Then I see "Yes (maybe) we can do that in the future" with the person knowing full well that the changes are going to be a major code breaker.

Now we jump ahead to the Bugs forum and get "In order to fix that we are going to have to change the way we do something else".

Some of the comments in the almost dead .NET thread and the current Array/ByRef thread are what really got me to taking a major look through the forums.

This has all brought me to the big questions. Is AutoIt3 perhaps getting a bit long in the tooth? Is it time to start thinking about the next generation of AutoIt and what directions it should take? Is that maybe the proper time to drop support for the older OSs?

Remember I'm just throwing this up for discussion and I'm not settled as to one direction or the other but it might be time to just do the bug fixes and stop adding more features. The new features could be added to AutoIt4 instead. I can feel the devs shivering now but look at it this way, you can write it without the previous mistakes. Of course that will also allow you to make a whole new set of mistakes but that's progress for you.

Just some things for you to waste your weekend thinking about and I don't intend to get into any major battles about it. What ever you people decide is fine with me ( by necessity ).

Edited by GEOSoft

George

Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.

Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.***

The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number.

Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else.

"Old age and treachery will always overcome youth and skill!"

Share this post


Link to post
Share on other sites



To me this makes sense! Not that my view is as big as other peoples but this still is a big point Geo is putting across. Think about it, if you start from almost scratch then you will be able to add things such as:

* Multi-threading

* Object-Oriented syntax

* Modularized compilation/variable sized compiled files

* FileInstall() accepting variables for the source

* New Opt()/AutoItSetOption() flags

Well that will certainly make people happy and make AutoIt a bigger success let alone known more. Obviously you wont make it for other platforms due to how AutoIt works however Multi-threading even Object-Oriented syntax would make AutoIt 10x better.

So, that was my attempt at backing Geos idea :)

Share this post


Link to post
Share on other sites

* Multi-threading

* Object-Oriented syntax

* Modularized compilation/variable sized compiled files

* FileInstall() accepting variables for the source

* New Opt()/AutoItSetOption() flags

LOL james you added EXACLY what Valik said in the thread "Not for discussion features"!!!

FileInstall will never accept variables as it's been executed during COMPILATION, NOT while the program is running.

if you want OO, there are a lot of languages with OOP... Making Autoit one, means that it must be completely rewritten.

Share this post


Link to post
Share on other sites

if you want OO, there are a lot of languages with OOP... Making Autoit one, means that it must be completely rewritten.

Thats exactly what the thread is about though. Is it time for that change? Probably not but it might be time to start thinking forward to that point. I certainly would not expect any of what James mentioned to be added to AutoIt3 and some of the requests would probably not be resonable even in a new version. Like I said, I just threw it out for discussion. Hopefully it will also give the dev team some insight into what direction people would like to see it grow although I think they have a good handle on that anyway.

George

Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.

Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.***

The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number.

Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else.

"Old age and treachery will always overcome youth and skill!"

Share this post


Link to post
Share on other sites

@Gif, yes I know I copied it because they are the most asked for, generally.

@Geo, if you don't expect it then what would be the point of doing this? What could you think of that would make AutoIt move in the ranks to Multi-threading?

Obviously, I would have no idea where to start if I was to make AutoIt so before you flame be saying that I should have a try, I have no idea and wouldn't attempt it. I am so so so grateful to all developers to make AutoIt to where it is now and you can't knock them for it but is it time to start thinking of progressing more?

Share this post


Link to post
Share on other sites

In my eyes, we shouldn't worry about script breaking changes any longer. I can't really explain why, but it would solve the current problems at least for a few years.

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

In my eyes, we shouldn't worry about script breaking changes any longer. I can't really explain why, but it would solve the current problems at least for a few years.

I care less about breaking scripts than I did in the past. Hence the recent GUIConstants.au3 change which is going to piss a lot of people off.

To address each point:

* Multi-threading

Multi-threading is seldom needed. Most of the people who "need" it don't really, they just think they do.

* Object-Oriented syntax

I would be more interested in a syntax like Lua that allows pseudo-object oriented programming but it's not really that important.

* Modularized compilation/variable sized compiled files

This isn't possible as long as we compile C++ to machine code for our binaries. Scripts could be trimmed down, yes, but not the binaries themselves.

* FileInstall() accepting variables for the source

FileInstall is a compile time feature with a runtime component. In the future, this logical distinction between the halves of FileInstall() will be made more apparent, which will stop the requests and also render them rather pointless. In other words, FileInstall() is going to be re-written in the future.

* New Opt()/AutoItSetOption() flags

This feature will not exist in an AutoIt 4 if I'm a developer.

There's nothing wrong with the core of AutoIt 3 now, except that it's too big and there's too much to work on. But that wouldn't change with a new core. It's been proven time and time again that things we never thought would be in the language have found there way there. Things I never thought we'd see, like Unicode support, have been added in. Unicode is much like multi-threading, it's a major pain (Jon will tell you this) to retro-fit to a program.

As time goes on, things are being rewritten, anyway. Soon the whole Stdio redirection and a large chunk of Run() will be re-written and expanded with bugs fixed (soon as in some is done and hopefully the rest will be done this weekend). Jon is wont to do the same thing, rewriting large parts of AutoIt while leaving the public-facing interface largely unchanged. As I've already mentioned, FileInstall() is on the list of things to be rewritten (in a non-backwards compatible manner).

AutoIt 3 is still evolving, both internally and publicly. It's not time to think about an AutoIt 4 yet.

Edited by Valik
Typo

Share this post


Link to post
Share on other sites

#8 ·  Posted (edited)

This feature will not exist in an AutoIt 4 if I'm a developer.

Valik please can you tell me what's so wrong with Opt()?

I know there is internal big CASE statement for this but

I also think Opt() is very usefull for some global AutoIt options.

How would you handle these usefull options without Opt()?

I can imagine another usefull options in the future if Opt() will not be on "Not ToDo list".

BTW: Thanks for interesting informations from AutoIt developers cooking.

EDIT: typos

Edited by Zedna

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

To me this makes sense! Not that my view is as big as other peoples but this still is a big point Geo is putting across. Think about it, if you start from almost scratch then you will be able to add things such as:

* Multi-threading

* Object-Oriented syntax

* Modularized compilation/variable sized compiled files

* FileInstall() accepting variables for the source

* New Opt()/AutoItSetOption() flags

Well that will certainly make people happy and make AutoIt a bigger success let alone known more. Obviously you wont make it for other platforms due to how AutoIt works however Multi-threading even Object-Oriented syntax would make AutoIt 10x better.

Did you mean ten times better or ten times bigger? Let's see... (Keep in mind this is ALL speculative and for the as-yet unstarted AutoItV4.)

  • Multi-threading - Could happen in V4. We would have to carefully define what the requirements are for executing a UDF in a separate thread. Hmm, what about interface functions?
  • Object-Oriented syntax - I see a lot of work here in building a whole new variable system to handle objects as well as arrays, primitive types, etc. I like this idea, but this will probably one of the major amounts of work if/when we go for it.
  • Modularized compilation/variable sized compiled files - This will require major rework in the way we write the interpreter. We would probably make sure that plug-ins are well defined and then put most of the current built-in functions and a lot of the UDF library into plug-in modules (PIM). During compilation, we only include the modules we would use. The GUI and RegExp stuff could come out and save a lot of memory each. But, if we are going to support Execute, we would have to include all the PIM's anyway. This would also mean that the command line options of any compiled script to run another uncompiled script would be lost.
  • FileInstall() accepting variables for the source - Not going to happen. Addressed in another post in this thread.
  • New Opt()/AutoItSetOption() flags - My plans actually call for removing these functions and most of the need for these. If we need system-wide flags, I would want them each with their own function to set it. I would expect that each PIM would have its set of flags that would be set within that PIM's code instead of system-wide.

Keep in mind that just because a developer has waded into this discussion, does not mean that anything is actually going to happen or even in the ways I outline. This is just my personal opinion that can (1) change and (2) be out-voted by the other developers before we start any work on V4.

Edited by Nutster

David Nuttall
Nuttall Computer Consulting

An Aquarius born during the Age of Aquarius

AutoIt allows me to re-invent the wheel so much faster.

I'm off to write a wizard, a wonderful wizard of odd...

Share this post


Link to post
Share on other sites

This feature will not exist in an AutoIt 4 if I'm a developer.

Valik please can you tell me what's so wrong with Opt()?

I know there is internal big CASE statement for this but

I also think Opt() is very usefull for some global AutoIt options.

How would you handle these usefull options without Opt()?

I can imagine another usefull options in the future if Opt() will not be on "Not ToDo list".

BTW: Thanks for interesting informations from AutoIt developers cooking.

EDIT: typos

All those options should be at the function level. Or at worst, they should be a function using the same naming convention as the functions they modify. For example, instead of "Opt("MouseCoordMode", n)" each Mouse function should either take the coordinate mode as a parameter or we should provide a "MouseSetCoordMode(n)" function. Many of the options could be removed as well. RunErrorsFatal comes to mind as being absolutely stupid and should be removed as well as the fatal error if a program isn't found. There are a handful of others which don't really offer much. MustDeclareVars would be a better fit as a pre-processor statement. The OnAutoIt functions should be replaced by a proper hook system which allows multiple hooks to be chained or the option to set them should be removed in favor of looking for only the specifically named functions (I'm not really sure why the Opt() portion was ever added, it makes no sense to me).

Share this post


Link to post
Share on other sites

All those options should be at the function level. Or at worst, they should be a function using the same naming convention as the functions they modify. For example, instead of "Opt("MouseCoordMode", n)" each Mouse function should either take the coordinate mode as a parameter or we should provide a "MouseSetCoordMode(n)" function. Many of the options could be removed as well. RunErrorsFatal comes to mind as being absolutely stupid and should be removed as well as the fatal error if a program isn't found. There are a handful of others which don't really offer much. MustDeclareVars would be a better fit as a pre-processor statement. The OnAutoIt functions should be replaced by a proper hook system which allows multiple hooks to be chained or the option to set them should be removed in favor of looking for only the specifically named functions (I'm not really sure why the Opt() portion was ever added, it makes no sense to me).

Aah OK. I understand now. I think it's really good idea.

Share this post


Link to post
Share on other sites

Object oriented syntax

What would the limitations of "syntax only" be? Could I do:

$myButton = GUICtrlCreateButton ( "text", left, top [, width [, height [, style [, exStyle]]]] )

$myButton._X = 50

$myButton._Y = 50

Arrays

I would like to see more indulgent array functions like in php, without having to include a UDF. Mostly due to lack of structures or classes, we have to rely heavily on arrays.

http://www.php.net/manual/en/ref.array.php

- array_fill, array_walk, extract, compact

-Native associative arrays

-Native array creation like _ArrayCreate so I can easily pass an array to a function without defining it first

-Native multidimensional sort, search, explode (StringSplit), implode (_ArrayToString)

Functions

Would repeating paramaters be possible for user defined functions? (Like DllCall)

Func myFunc(param1, type1, param2, type2, param n, type, n)

Forum

I think with all of the new additions to AutoIt, the General Support forum area should be split into more sub-sections.

-IE Automation

-GDI+

-Gaming?

-Networking, TCP/IP

Overall I would just like to see more UDF's converted to native C++.

Share this post


Link to post
Share on other sites

I think with all of the new additions to AutoIt, the General Support forum area should be split into more sub-sections.

<...>

-Gaming?

You do not want this.

Share this post


Link to post
Share on other sites

#14 ·  Posted (edited)

You do not want this.

Agreed whole heartily. I still cringe at the memory of the last time this was tried. I have a hunch it's on Jons list of things "I should never have done" as well. The kind of feedback that's been provided so far is why I started the thread. It's for discussion of the pros and cons of running with "patch" type changes to AutoIt or just rewriting the core. I knew up front by the way that Opt() would be on Valiks "Won't do" list. This is one of the things that will probably always be in Ver 3 but would never end up in ver 4. A much better way is the method outlined by him in the post above in Post #7. If I remember correctly AutoItSetOption() was only put in as a stop-gap measure anyway then it got too big to eliminate. Edited by GEOSoft

George

Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.

Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.***

The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number.

Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else.

"Old age and treachery will always overcome youth and skill!"

Share this post


Link to post
Share on other sites

Nutser, developers in a topic just mean a bigger insight the the factors to which we are talking about. Your are probably right, I have heard developers saying that AutoIt is huge and that is very understandable.

RunErrorsFatal is stupid, I never use it.

Share this post


Link to post
Share on other sites

RunErrorsFatal is stupid, I never use it.

This sentence is counter-intuitive. What's stupid about RunErrorsFatal is that it defaults to being True, errors in run are fatal, script ending errors. You should actually always be using RunErrorsFatal because the default behavior is what's really stupid.

Share this post


Link to post
Share on other sites

Nutser, developers in a topic just mean a bigger insight the the factors to which we are talking about. Your are probably right, I have heard developers saying that AutoIt is huge and that is very understandable.

RunErrorsFatal is stupid, I never use it.

I always use it because the default is stupid...

Lar.


f_mrcleansmalm_77ce002.jpgAutoIt has helped make me wealthy

Share this post


Link to post
Share on other sites

This sentence is counter-intuitive. What's stupid about RunErrorsFatal is that it defaults to being True, errors in run are fatal, script ending errors. You should actually always be using RunErrorsFatal because the default behavior is what's really stupid.

Yeah, it is stupid. I think it was a carry over from v2. VBScript bombs out too by default at the slighest error which is equally annoying.

Share this post


Link to post
Share on other sites

You do not want this.

Were you pointing out the gaming part only or the idea of having more sub-forums?

I am wholeheartedly against game botting but not a day goes by that I don't see 4 requests for aimbots, WoW hacks, Diablo 2 hacks, Runescape hacks, etc...these kids don't want help writing a script, they come in with zero posts asking for something finished.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0