Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Thoughts for v2.0


  • Please log in to reply
105 replies to this topic
Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

GuiAdd("GuiName", "ControlType", "Options", "Value")

That change in syntax seems to offer little benefit, and seems less appropriate than the traditional syntax (with name preceding command). That said, I think that either way, function syntax is less appropriate and less convenient for the Gui command than the traditional syntax.



just me
  • Members
  • 1496 posts
  • Last active: Nov 03 2015 04:32 PM
  • Joined: 28 May 2011

Standard Library

 

Personally, I don't like the idea. On the one hand I think that built-in functions perform better, but I may be mistaken. On the other hand it smells like AutoIt's UDFs. They have many of them covering almost every problem, but some of them are or were inefficient (I didn't watch the forums for about two years now). However, if you ask for new built-in functionalities the most frequent answer is or was: "Why, we already have an UDF for this?".

 

BTW: Maybe ist would be better to split this thread accordingly to the different parts of v2-thoughts to keep things clear.


Prefer ahkscript.org for the time being.


IsNull
  • Moderators
  • 990 posts
  • Last active: May 15 2014 11:56 AM
  • Joined: 10 May 2007

That change in syntax seems to offer little benefit, and seems less appropriate than the traditional syntax (with name preceding command). That said, I think that either way, function syntax is less appropriate and less convenient for the Gui command than the traditional syntax.

 

The Gui System would profit enormously form a Object-based approach and a proper Event handling system, capable of invoking methods (delegates)

 

myGui := new Gui
myGui.Add(new Label("huhu"))
myGui.Show()

 

 

I think that Object syntax is more easily readable than any Function-based Api. Plus, we would gain all the power of object references.

It seems to be a Win-Win situation for Newbies and more experienced Users.



fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
So here are my opinions:

Derefs: only allow %var and %(expression). In commands the % something expression forcing syntax would be removed as it would be replaced by %(...). Internally command args would be expressions, and the % syntax would be translated to concatenation.

Built-in variables allow direct assignment to A_** variables for settings. Remove A_Tab and A_Space. +1 to A_ChrSize and A_StrEncoding.

Commands: move out rarely-used commands to standard library functions in order to reduce bloat. Commands with output variables should not exist IMO, they should only be called using function syntax.

Error handling: remove ErrorLevel completely. Exceptions are exceptional. Normal uses of failure cases should get their own functions, for example, there would be a separate RegKeyExist() function; OR have explicit "allow for failure" modes, OR allow failure by default in certain cases (example: FileDelete with non-existant files). All of this could be complemented by "on error resume next" type of functionality when an exception is not caught.

Errors in expressions: show a warning on invalid math operations, throw an exception in invalid dynamic function calls, stack underflow and other similar cases.

Objects and classes: throw exception on both allocation failure and invalid method call. base should be a reserved word in class methods. +1 to String, Number and Object, but I would propose adding Integer, Float and Value too (the latter representing non-object values). No opinion on whether class appending should be explicit.

Expressions: +1 to in, contains, is and their proposed behaviour. Make them reserved words (as with new in v2).

WinTitle: Get rid of ExcludeTitle/Text. Add a way to specify raw window titles (so that detecting windows with exact titles such as "ahk_id revealer" is possible). +1 to per-WinTitle mode setting.

Misc: Always declare Args even as an empty array. Split out ComObjActive() into separate functions.

GUI: Replace the current outdated commands with an OOP-based interface that could be even implemented by script. I have an already-working example of what the API could look like.

---

Uncategorized idea: it may be a good idea to expose built-in OOP interfaces through the A_ prefix in order not to collide with user variable names. For example GUI could look like this (modeling on IsNull's example):
g := new A_Gui("Window title")
new A_GuiLabel(g, "Hello world!")
g.Show()
Similarily enough:
m := new A_Menu
m.Add("Test", Func("SomeHandler"))
A_TrayMenu.Add(m)
;...
g.Menu := m
;...

SomeHandler(callerObj, menuObj, menuItem, menuItemPos) ; example parameter list, there may be a better solution
{
    ;...
}
These built-in classes could also be extended from, allowing more complex OOP constructs for those who want them.

EDIT: File access and COM objects could perhaps work in the same way:
obj := new A_ComObject("InternetExplorer.Application") ; same syntax as ComObjCreate()
f := new A_File("somefile.txt") ; same syntax as FileOpen()


IsNull
  • Moderators
  • 990 posts
  • Last active: May 15 2014 11:56 AM
  • Joined: 10 May 2007
@fincs: +1 I agree to your points.
 
I throw in some more ideas, now regarding a standard library / package manager.
I am really into the idea, that a integrated ahk package manager system would be great. However, a packager system as a external system won't be really the way to go.
 
Let me give an example first:

 

#require gdip 1.4

;// just some random GDI+ usage


hbm := CreateDIBSection(Width, Height)
hdc := CreateCompatibleDC()
obm := SelectObject(hdc, hbm)
G := Gdip_GraphicsFromHDC(hdc)
 

 

Now the effect of the #require pre processor directive is as follows, until one point succeeds:
1. Search in the local library folder for a matching library
2. Search in the standard libary for a matching library
3. Search in the the package repositorys for a matching library, and download into the local standard lib
 
The package manager is able to deal with library versions; and so also the Interpreter has to deal with this information, to load the correct library.
 
This way, we can easily deploy ahk scripts in source code form; dependencies are resolved automatically.
 
One can just copy & paste a script from the Forum and it works, without the need for the author to include a hard copy of used 3th party libraries. happy.png
 
 
I think this step also goes with the thoughts of Poly, as he stated that he is planing some sort of autohotkey package manager.
 
Anyway, keypoint would be, that this package resolving is included into the basic autohotkey interpreter.
While this subsystem does not require being  part of Autohotkey (v2) from the beginning, it would be a great project to make AHK even more simple to Newbies.


faqbot
  • Members
  • 997 posts
  • Last active:
  • Joined: 10 Apr 2012
Don't like:
- Moving stuff to Standard Library (how much bloat are we talking about anyway)
- The suggested OOP(?) Gui style, the current setup may not be ideal but easier to grasp for newbies in my opinion, something that shouldn't be forgotten. And it seems it can be done already as shown by fincs.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
@IsNull, very nice idea; however I'm not sure if I'd like to have the package managing integrated into the main interpreter executable (I think it should be separate).

Moving stuff to Standard Library (how much bloat are we talking about anyway)

Current v2 x86 executable is 840KB, and x64 is 1.04 MB. Some commands (such as the shortcut stuff) are very seldom used, do not have any realistic performance requirements that justify their implentation in native code and are better off as standard libraries.

The suggested OOP(?) Gui style, the current setup may not be ideal but easier to grasp for newbies in my opinion, something that shouldn't be forgotten. And it seems it can be done already as shown by fincs.

I disagree. I find the current Gui API very unintuitive; with all its variable name, sub-command, GuiControl(Get), GUI name and g-label mess. Multi-GUI scripts are basically unmaintainable. OOP would make GUI easier to understand by newbies. An example: how is this more readable?
GuiControlGet, ov, somegui:, someEditbox
StringUpper, ov, ov
GuiControl, somegui:, someEditbox, %ov%

; vs

someEditbox.Text := StrUpper(someEditbox.Text)


guest3456
  • Members
  • 1704 posts
  • Last active: Nov 19 2015 11:58 AM
  • Joined: 10 Mar 2011

Derefs: only allow %var and %(expression). In commands the % something expression forcing syntax would be removed as it would be replaced by %(...). Internally command args would be expressions, and the % syntax would be translated to concatenation.

while i wouldn't be opposed to this, because at least only allowing one % would be consistent and there would be no mix and match, i still prefer the %expr% option since it is a natural extension of the v1 syntax. however, the single % syntax is much better for double and triple derefs: %%var as opposed to %(%var%)%

WinTitle: Get rid of ExcludeTitle/Text. Add a way to specify raw window titles (so that detecting windows with exact titles such as "ahk_id revealer" is possible). +1 to per-WinTitle mode setting.

what do you mean by 'raw window titles' ? the ahk_id parameter is for HWNDs. are you saying windows that explcitly have the text "ahk_id"?

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007

what do you mean by 'raw window titles' ? the ahk_id parameter is for HWNDs

Exactly. Currently it is not possible to explicitly refer to a window whose title is literally "ahk_id something".

IsNull
  • Moderators
  • 990 posts
  • Last active: May 15 2014 11:56 AM
  • Joined: 10 May 2007
@fincs: Thinking about bloating the Autohotkey interpreter, you might be right. But it could be solved just by delegating the work to an separate tool/dll. The real point is, that the Autohotkey interpreter has to be aware of this new "just in time" dependency resolving, and not throw an error because the library is not yet downloaded. 
So, one should count on this feature, and the default installation should then handle such scripts correctly. It can be solved by an ahk interpreter which delegates the packager stuff when necessary, or it can even be a special AHK-Loader, which, after the packages have been installed, invokes the default Autohotkey interpreter. It would be a kind of a pipe and filter architecture, where the script source is passed through. 
 
This way, we even could support old AHK Basic scripts with this feature. Just kidding. 
 
 
@faqbot: I am also a bit confused, why the current handling of Guis should be simpler. I already tried to explain somewhere else, that the Object approach is here to make things more understandable to humans; e.g. for us, all the things are objects, and have properties and abilities. Aslong as one just can use Objects, things are very intuitive. So, especially the GUI part is a well candidate and things will get simpler.


faqbot
  • Members
  • 997 posts
  • Last active:
  • Joined: 10 Apr 2012
@fincs, IsNull: I do believe the current Gui is more friendly for newbies even if it is clunky, you are professional programmers and/or programming for a long time so you no longer understand or have forgotten Objects are NOT newbie friendly. Objects never will in *my* opinion, you may think they are prettier, easier, elegant, - a casual scripter will not think so. If AHK moves to more programmers oriented solutions/conventions you will loose a large part of the intended target audience.

IsNull
  • Moderators
  • 990 posts
  • Last active: May 15 2014 11:56 AM
  • Joined: 10 May 2007

@faqbot:

I am very concerned about the simplicity in AHK. I also have hold some AHK (Basic) lessons for Newbies and made some interesting experiences. While its true that I am studding Computer Science at some extend, I have spend also good parts of my time studding usability and user experience themes. Therefore, I am really interested in joining the power of a high-level language and bring it to non Computer Science related people. It is also worth mentioning, that even the big "high level" languages are becoming simpler and more intuitive. (Java/JavaFX Script, C#)

 

Programming object oriented is more complex than just structured. But let me formulate the following statement:

Objects do not have anything to do with Object-oriented programming nor Object-oriented design, which both are complex.

 

Take Visual Basic (not the new .NET stuff) as a good example for this. I learned programming with VB, and while back then, I could not really understand anything about Object Oriented programming, it was very intuitive to use lines like those:

textBox.Text = "woot"
myButton.Enabled = True

 

(Visual) Basic's primary goal, after all, is to be as easy as possible. 

 

In conclusion, do not mix up the therm Object with Object Oriented Programming. We do not talk about interfaces, inheritance and polymorphism. One might be able to use such advanced concepts, but a Newbie will never have to know about them in order to enjoy the intuitive usage of simple objects. 

 

If you show us some clear example, what is less understandable in simple object usage I may be able to get your point better. Just keep in mind, that you probably are not so representative for a "Newbie" either, because you already learned much about AHK and its "structured" concept. 

 

Frankly, it might be quite tricky to define what Newbie friendly is, besides the definition of intuition, which bases upon what a human being is used to. You will see that Objects (not in terms of programming) are this common base of thinking. How to bring this into a programming language is off course another story.



guest3456
  • Members
  • 1704 posts
  • Last active: Nov 19 2015 11:58 AM
  • Joined: 10 Mar 2011
i agree with IsNull

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
+1 to what IsNull said.

jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009

+1 to what IsNull said.

 

... Objects are NOT newbie friendly. Objects never will in *my* opinion ...

 

It's not that your opinion is wrong as I agree completely, but your perspective is skewed. How many objects are used in the simplest of AHK scripts - think about the internal execution at the C++ level. Objects themselves may be complex, but their usage could be simple & intuitive even for a child. Again I point out - were you concerned about the complexities of objects when you wrote:

MsgBox Hello World!

Personally I like Ruby's everything is an object approach, but it's just a matter of perspective.

 

 

Concerning the interpreter & bloating - I personally find the 1 executable approach extremely newbie friendly. When you think AHK, you think the one .exe. It's portable, can be taken with you on a usb drive, can drag & drop scripts on it. I never liked all the "extra" stuff that's required to start programming in another language. However, this just may be me since I like to understand what all is going on when I write & execute a script.

I remember IronAHK was integrating a concept to leave out certain parts of the interpreter code when building an executable if they weren't needed. I like this. If you want to create a small executable, you can. I don't think an extra 1-2mb for the main AHK executable itself is devastating if you can create a 200kb standalone executable for your code.

 

Sorry if this has already been discussed.