modulo operator?

[TheMna]

So is there one in autoit? In most languages it's %, tho that gives me an error in autoit.

[monoceres]

So is there one in autoit? In most languages it's %, tho that gives me an error in autoit.

In autoit, to perform a modular operation you call the Mod() function muttley

It actually annoys me too though...

[weaponx]

In autoit, to perform a modular operation you call the Mod() function muttley

It actually annoys me too though...

Yea...It would be nice to have some more shorthand syntax. Not going to happen though.

In PHP I use the pre and post increment operators all the time. The ability to add an element to an array like this is splendid too:

$array[] = "New element"

[PsaltyDS]

Yea...It would be nice to have some more shorthand syntax. Not going to happen though.

In PHP I use the pre and post increment operators all the time. The ability to add an element to an array like this is splendid too:

$array[] = "New element"

Amazing the things you can miss over time. I had never heard of _Iif() before following that link and reading Valik's reply, but it has been in the Misc.au3 UDF since February, 2005.

The things I don't know are still so much more numerous than those I do...

muttley

[weaponx]

Amazing the things you can miss over time. I had never heard of _Iif() before following that link and reading Valik's reply, but it has been in the Misc.au3 UDF since February, 2005.

The things I don't know are still so much more numerous than those I do...

muttley

I still prefer the ternary operator. It seems like the devs are really avoiding changes to the core syntax. New operators aren't "necessary", but I think they make the language more refined. Also some people think anything that can be done via UDF is "trivial" and doesn't need to be native but as I have demonstrated, non-native functions are a major hit to speed.

The problem here is that we lack OOP and must rely on arrays for all native data storage, which would be fine if we had ANY native functions to work with arrays. There is no reason not to have these natively.

- implode / explode

- filter / walk / map

- pop / push

- pad

- search

- reverse

- sort

- shuffle

- merge

[Paulie]

The problem here is that we lack OOP and must rely on arrays for all native data storage, which would be fine if we had ANY native functions to work with arrays. There is no reason not to have these natively.

- implode / explode

- filter / walk / map

- pop / push

- pad

- search

- reverse

- sort

- shuffle

- merge

I personally am not very upset at the lack of OOP. OOP languages often have ugly syntax. However, It is true that all data must be stored through arrays. and I definitely agree that it is sort of odd, with how major of a role that arrays play in the language, that there are no native functions to interact with them. Meaning we have to include files that contain supposedly slower UDFs.

However, I'm sure the Devs have their reasons to avoid making every possible UDF under the sun into native code. One reason that come to mind (and i may be wrong, in fact i probably am) is that when code is compiled, the entire interpreter is included in the stub .exe. therefore, adding more native functions would increase the file size of EVERY compiled .exe. But tbh, if the performance boost to array management is as great as weaponx suggests, maybe it would be worth the increase?

Just thinking...

Edited July 17, 2008 by Paulie

[PsaltyDS]

I still prefer the ternary operator. It seems like the devs are really avoiding changes to the core syntax. New operators aren't "necessary", but I think they make the language more refined. Also some people think anything that can be done via UDF is "trivial" and doesn't need to be native but as I have demonstrated, non-native functions are a major hit to speed.

The problem here is that we lack OOP and must rely on arrays for all native data storage, which would be fine if we had ANY native functions to work with arrays. There is no reason not to have these natively.

- implode / explode

- filter / walk / map

- pop / push

- pad

- search

- reverse

- sort

- shuffle

- merge

I see what you mean, but if blazing speed and OOP is the goal, then AutoIt is obviously not the right language to use. Might it ruin AutoIt to try to make it into something else? It seems like trying to make AutoIt less like VBScript and more like VB.NET, or more useful for professional programmers and much more difficult and opaque to novices just upgrading from batch files.

That concern really only applies to the OOP idea, though. Optimized native versions of some of the Array UDF functions and new functionality there would be nice without harming the ease of use in AutoIt.

P.S. Sorry for hijacking the thread with an off-topic comment... muttley

[weaponx]

I don't think every UDF should be native but these are very important.

EDIT: I am not concerned as much with AutoIt being OOP, associative arrays would be magnificent. Right now if I want to create a button I could do something like this:

$button = GuiCtrlCreateButton("Click",50,100,20,60)

$array = ControlGetPos("","",$button)

;$array[0] = X position

;$array[1] = Y position

;$array[2] = Width

;$array[3] = Height

Rather than:

$button._x

$button._y

$button._w

$button._h

And I am okay with that...but lets say I want to create a game. I will use a monster object.

;[0]: Name

;[1]: X (Int)

;[2]: Y (Int)

;[3]: W (Int)

;[4]: H (Int)

;[5]: Direction (Bool)

;[6]: Active (Bool)

Dim $monster[7]

It would be much simpler to do:

$monster['X'] = 5

$monster['Y'] = 20

etc...

Edited July 17, 2008 by weaponx

[Paulie]

I don't think every UDF should be native but these are very important.

I agree with you. My point is that it would be understandable for the Devs to be hesitant to make these kinds of changes, as what is/isn't important is sort of up to an individual's discretion.

But don't get me wrong, I completely support the request for native array funcs. muttley

[weaponx]

I agree with you. My point is that it would be understandable for the Devs to be hesitant to make these kinds of changes, as what is/isn't important is sort of up to an individual's discretion.

But don't get me wrong, I completely support the request for native array funcs. muttley

I think a strong case has to be made. Maybe I will write all of the desired functions in C++ and do a comparison to the AutoIt speed. Of course we couldn't compare apples to oranges so we would have to subtract the overhead from AutoIt which could be found by calling the exact same (native) function in both C++ and Autoit and finding the percentage difference.

Edited July 17, 2008 by weaponx

[SkinnyWhiteGuy]

Associative Arrays have been discussed, many times (with even a Dev providing a script example of it working). So far, that hasn't been a priority to be added.

As far as OOP goes, I tried to show a solution to that, not exactly OOP, but it was pretty close nonetheless. I posted it here.

[Paulie]

Associative Arrays have been discussed, many times (with even a Dev providing a script example of it working). So far, that hasn't been a priority to be added.

Associative arrays is not what is being asked for.

We are looking to get native array management functions. Arrays play a huge role in the language, and it seems logical that a language that relies so heavily on arrays should at least be able to Add/Remove elements from them without having to include a 54kb of UDFs.

EDIT: it would be nice to get input on this from a developer's point of view. In all honesty, I don't know enough about the inner workings of autoit to weigh the pros and cons, but if my extrapolated interpretation of possible cons is correct, i think the pros outweigh the cons. *Waits to be proved wrong*

Edited July 17, 2008 by Paulie

[weaponx]

I listed all of the functions I would like to see that work with non-associative arrays:

- implode / explode

- filter / walk / map

- pop / push

- pad

- search

- reverse

- sort

- shuffle

- merge

The resulting speed increase from these would be a fraction of the Array UDF calls. Every other function out there that uses the Array UDF or array iteration would benefit.

[PsaltyDS]

...but lets say I want to create a game. I will use a monster object.

;[0]: Name

;[1]: X (Int)

;[2]: Y (Int)

;[3]: W (Int)

;[4]: H (Int)

;[5]: Direction (Bool)

;[6]: Active (Bool)

Dim $monster[7]

It would be much simpler to do:

$monster['X'] = 5

$monster['Y'] = 20

etc...

Perhaps...

Global Enum $M_Name, $M_X, $M_Y, $M_W, $M_H, $M_Dir, $M_Actv
Global $monster[$M_Actv + 1]

$monster[$M_X] = 5
$monster[$M_Y] = 20

I know that doesn't answer all your concerns, but I had to give it a shot!

muttley

[weaponx]

Perhaps...

Global Enum $M_Name, $M_X, $M_Y, $M_W, $M_H, $M_Dir, $M_Actv
 Global $monster[$M_Actv + 1]
 
 $monster[$M_X] = 5
 $monster[$M_Y] = 20

I know that doesn't answer all your concerns, but I had to give it a shot!

muttley

Perhaps I chose a bad example. One might say "well its an automation scripting language, not a game engine". Ignore the associative array stuff for now, the bigger hurdle is the crap that an UDF should not have to do.

[James]

Well if people are trying to convert scripts from, let's say VB.net and you have:

Control._X

You have to go the long way round and get the control position (ControlGetPos()) and then create an array (as mentioned above) to handle the data.

[weaponx]

Well if people are trying to convert scripts from, let's say VB.net and you have:

Control._X

You have to go the long way round and get the control position (ControlGetPos()) and then create an array (as mentioned above) to handle the data.

Well now you are getting outside the realm of non-OOP scripting languages.

[James]

So you want AutoIt to be OOP?

[weaponx]

So you want AutoIt to be OOP?

That would be nice but not the major point we were discussing, native array functions. These are a realistic request whereas asking for OOP would ellicit an angry response.

[James]

Right. But like I said, we have to do everything in arrays and have many people. I'm going to leave this topic muttley