Cleanup/Rename internal and User Defined Functions.

[Xenobiologist]

Hi,

I read about some changes which may break old scripts. If you are going to make such changes think about ...

Delete _ArrayCreate func (it is not necessary anymore)
Rename WinMove --> WinSetPos
It is kind of strange that there is _SoundPlay an SoundPlay.
and so on.

So long,

Mega

[JdeB]

I don't see how I can ever make this fullproof and is very risky. Tidy's function really is to Tidy code and don't want it to change the code at all, just Indent, add/remove whitespace and proper case syntax.
I wouldn't want Tidy to replace _SoundPlay() with Soundplay because that could/will break the script when it uses Handles in stead of filenames.

Jos

[Xenobiologist]

Hi,

I didn't meant to let Tidy do the job. I meant you should thing about doing this changes directly in Autoit. If your are doing not backwards compatible changes, then use this chance to make as much as you can to restructure Autoit.

So long,

Mega

[JdeB]

In my mind the arguments remain the same for AutoIt3 doing that.
It should interpret and run the script, not change it.
Now assume somebody made his/her own UDF and also called it _SoundPlay()... You wouldn't want AutoIt3 to be stubborn and execute SoundPlay().
In general, AutoIt3 Functions that are renamed will be supported for a while but I really cannot see how you could do this without breaking scripts...

Jos

[Xenobiologist]

Hi,

exactly that is the point. I know that some changes will break scripts. So, nevertheless do them (if possible all known ones in one version) and then just document it.

You cannot avoid that. Sometimes changes have to be done to go ahead.

The people have to look into the helpfile (history) whether some changes may affect their scripts.

That is my opinion.

So long,

Mega

[JdeB]

But you haven't commented on the issue when people make their own UDF and call it _SoundPlay()?

[Xenobiologist]

Replying to JdeB:

But you haven't commented on the issue when people make their own UDF and call it _SoundPlay()?

Hi,

where is the problem on that? Decide whether you want to keep SoundPlay or _Soundplay. After that Autoit and Au3Check(Tidy) [I mix them often] only knows that func. Using it - everything works fine. Using the other one which is gone then, an error occurs the same as normal when using an unknown func --> : undefined function.

Creating an UDF called with the name you kept then the local one (UDF) is called like

 _StringBetween()

Func _StringBetween()
	ConsoleWrite("UDF" & @CRLF)
EndFunc   ;==>_StringBetween

Maybe there should appear a warning -> name already defined? Maybe not. (It is kind of overloading a func like you can do in OO languages , Java etc.)

Besides, you need to change:

Tidy AutoIt3 v2.0.23.7   Copyright (c) Jos van der Zande  Januar'''i''' 6, 2008

I stop right here, cause maybe I totally missed your point. :-)

So long,

Mega

[JdeB]

My impression was that you wanted the AutoIt3 program to do something automatically and change your input script.
Now if you mean we should remove obsolete UDF's then you will have to list the UDFs that are obsolete in your oppinion, because we already do this to my knowledge.
The _SoundPlay() UDF isn't obsolete since its part of a set of UDFs and can be used differently than the buildin one.

Jos

[Valik]

Jos, what he's saying is:
Remove _ArrayCreate(), it's not needed since we have $array[3] = [ 1, 2, 3] syntax now.
Rename WinMove() to WinSetPos() since it better fits our naming conventions.
Remove SoundPlay() as a built-in function since _SoundPlay() can do it and a lot more.

He's not asking for anything beyond that. He's asking these things in response to a comment I recently made regarding backwards compatibility.

Of that list, WinMove() -> WinSetPos() sounds reasonable. WinMove() does kind of stick out with it's odd name. But I don't see why we need to just break scripts for no real good reason by removing _ArrayCreate() or SoundPlay().

Xeno, I am in total agreement, otherwise, though, and have said as much. I would really like to make the next version of AutoIt non-backwards compatible with as many fixes for our past mistakes as possible. There are a number of planned changes breaking backwards compatibility anyway that I'd like to do a lot more.

[JdeB]

What I have done thus far in case an UDF also became a build in function is to "only remove the documentation", which also removes the keywords from au3.keywords.properties and au3.api. This would still guaranteed backwards compatibility but will slowly move people to use the internal commands.
_ArrayCreate() is one that fits that profile in my oppinion and should be handled in that way in the new Array.au3 effort thats underway. I am not in agreement that its the same for _SoundPlay() since that allows to use the "handle" set by _SoundOpen(), which is not the case with the build-in function.

Jos

[Xenobiologist]

Hi,

exactly! Do it! :-)

I'll study the helpfile whether I find some more funcs which should be deleted or renamed.

Only one _SoundPlay() function should remain IMO, otherwise it looks kind of weird.

So long,

Mega

[JdeB]

Edited the Title to reflect what the intent is of this request.

So the current list is:

• Remove the Docs for _ArrayCreate() but leave the UDF for backward compatibility. (Agree)
• Add WinSetPos() and rename Docs of WinMove() to WinSetPos(), leaving WinMove as alias for backward compatibility? (agreement on this one ? )

Anything else ?

[Gary]

Removed _ArrayCreate documentation. 3.2.11.0

[Gary]

Being there has not been anything else added in a week I'm closing this ticket.

[TicketCleanup]

Automatic ticket cleanup.

[Zedna]

I know it's a bit late :-)
but what about FileMove()?

Because AutoIt lacks a "FileRename" function, use FileMove to rename a file!

[Xenobiologist]

Hi,

what happened to the idea of adding WinSetPos and FileRename and so on?

Mega

[Valik]

FileRename() is entirely redundant. I don't understand why it's so hard for people to grasp that you move from NameA to NameB even though the directory doesn't change.

I can think of a reason not to add WinSetPos(): SetWindowPos(). SetWindowPos() is a Windows API function that does something completely different than our WinSetPos() would. However, at first glance it would look like it would do the same thing with just a rename to our naming scheme. So sticking with WinMove() is less confusing in that regard.

I'm going to re-open this ticket so I can change the resolution. We didn't complete it and we do not have any intention of completing it.