Modify

Opened 12 years ago

Closed 11 years ago

#41 closed Feature Request (Rejected)

Cleanup/Rename internal and User Defined Functions.

Reported by: Xenobiologist Owned by:
Milestone: Component: AutoIt
Version: Severity: None
Keywords: Cc:

Description

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

Attachments (0)

Change History (19)

comment:1 Changed 12 years ago by JdeB

  • Resolution set to rejected
  • Status changed from new to closed

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

comment:2 Changed 12 years ago by Xenobiologist

  • Resolution rejected deleted
  • Status changed from closed to reopened

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

comment:3 Changed 12 years ago by 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

comment:4 Changed 12 years ago by 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

comment:5 follow-up: Changed 12 years ago by JdeB

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

comment:6 in reply to: ↑ 5 Changed 12 years ago by 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

comment:7 Changed 12 years ago by 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

comment:8 Changed 12 years ago by 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.

comment:9 Changed 12 years ago by 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

comment:10 Changed 12 years ago by 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

comment:11 Changed 12 years ago by JdeB

  • Summary changed from Tidy Autoit to Cleanup/Rename internal and User Defined Functions.

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 ?

comment:12 Changed 12 years ago by Gary

Removed _ArrayCreate documentation. 3.2.11.0

comment:13 Changed 12 years ago by Gary

  • Resolution set to completed
  • Status changed from reopened to closed

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

comment:14 Changed 12 years ago by Valik

  • Milestone Future Release deleted
  • Version 3.2.10.0 deleted

comment:15 Changed 12 years ago by TicketCleanup

  • Milestone set to Future Release

Automatic ticket cleanup.

comment:16 Changed 11 years ago by Zedna

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

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

comment:17 Changed 11 years ago by Xenobiologist

Hi,

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

Mega

comment:18 Changed 11 years ago by Valik

  • Milestone Future Release deleted
  • Resolution Completed deleted
  • Severity set to None
  • Status changed from closed to reopened

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.

comment:19 Changed 11 years ago by Valik

  • Resolution set to Rejected
  • Status changed from reopened to closed

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.