Obj.Method, Params - Command syntax for objects Topic is solved

[fincs]

[Update by Lexikos: Command syntax was added for methods in v2.0-a049, and changed in v2.0-a079 to require expressions for all parameters (just allowing parentheses to be omitted).]

[Note from Lexikos: This and the next few posts were split from Assorted & Unsorted AutoHotkey v2 Wish List to make further discussion easier.]

IMO, one of the reasons people are reluctant to use objects (and thus to have core functionality redesigned to use objects) is because they are forced to use expression syntax, which involves more syntactical noise. In v2, functions can be called with traditional command syntax, alleviating this problem. However there is still no way to use command syntax with objects. Therefore I propose the following syntax:

Code: Select all

obj.Method, Param1, Param2, ... ; CALL operation.
obj.Method:, OutputVar, Param1, Param2, ... ; CALL operation, storing the return value in OutputVar.
obj.Get, OutputVar, Index1, Index2, ... ; GET operation.
obj.Set, Index1, Index2, ..., Value ; SET operation.

EDIT: No longer using ':' to introduce object syntax.
Example code:

Code: Select all

; Use a File object
FileOpen, File, MyFile.txt, w
File.Write Hello world!`n
File.Set Pos, 0
File.Read: Line
MsgBox %Line%

; Use a Gui object: http://ahkscript.org/boards/viewtopic.php?f=37&t=2998
GuiCreate, Gui, Progress Example,, MyGui_
Gui.Set BgColor, White
Gui.AddPic, x0 y0 h350 w450, %A_WinDir%\system32\ntimage.gif
Gui.AddButton, Default xp+20 yp+250, Start the Bar Moving
Gui.AddProgress: MyProgress, w416
Gui.AddText: MyText, wp
Gui.Show

MyGui_ButtonStartTheBarMoving()
{
  global
  Loop Files, %A_WinDir%\*.*
  {
    if A_Index > 100
      break
    MyProgress.Set Value, %A_Index%
    MyText.Set Value, %A_LoopFileName%
    Sleep 50
  }
  MyText.Set Value, Bar finished.
}

[lexikos]

foo.bar, baz is already reserved (treated as an unrecognized action) for this purpose.

[fincs]

foo.bar, baz is already reserved (treated as an unrecognized action) for this purpose.

Awesome, I did not know that; this was obviously the preferred option but I doubted whether it conflicted with anything or not. I've edited the post above to match this.

[just me]

foo.bar, baz is already reserved (treated as an unrecognized action) for this purpose.

Awesome, I did not know that; this was obviously the preferred option but I doubted whether it conflicted with anything or not. I've edited the post above to match this.

I've been always wondering whether all humans derive from a single source. Now I'm sure we do'nt.

[lexikos]

I've split the above posts into their own thread to make further discussion easier. They came from Assorted & Unsorted AutoHotkey v2 Wish List.

Very nice. However I still think there should be a way to set/get properties; as well as request the use of an OutputVar for the return value when calling methods. For the former, obj.Get OutputVar, Fields... and obj.Set Fields..., Value could be supported; and for the latter I suggested using a : suffix in the method name in the forum thread (however there may be a more elegant solution).

I don't. Command syntax isn't suited for that sort of thing. With the suffix, it's either inconsistent with commands, or we change commands as well and end up further away from the original language. I don't want to add any syntax that feels *new* (strange or unique).

Get either needs the new syntax for specifying an OutputVar (like you suggested), or needs to be treated differently from other methods by the pre-parser. It either wouldn't actually call a method, or any method with that name would get special treatment by the pre-parser, in either case possibly causing confusion and just not seeming right. An alternative might be different syntax for getting/setting, but that's even less appealing than the : suffix.

In general I think there's much less benefit to using command syntax for get/set than for functions or methods. The main advantage of command syntax is that you can omit quotation marks and parentheses. Expression syntax is already much more familiar for things like obj.property or obj[index] and command syntax would actually be more verbose. Maybe it would be useful for Set when assigning a string with variable substitution, but I purposefully omitted that for normal assignments, so why allow it for objects?

obj.Method:, OutputVar looks weird and somehow wrong; obj.Method: OutputVar is marginally better. Personally, I think obj.Method :OutputVar is easier to grasp, but I'm still not inclined to implement either.

P.S. I prefer not to carry out this sort of discussion in the comments of a commit. That would more be the place to bring up issues with the commit itself, or the code it changes.

[lexikos]

I think part of my issue with your proposed Get/Set is that the target object feels like it should be a parameter, grouped with the property, not part of the command name.

If we introduce Get/Set command syntax for objects, it seems incongruous to not do so for variables. Something like this might work (but I'm not convinced it should be implemented):

Code: Select all

Get OutputVar, InputVar             ; OutputVar := InputVar
Get OutputVar, ObjectVar.Property   ; OutputVar := ObjectVar.Property
Set OutputVar, TextValue            ; OutputVar := "TextValue"
Set ObjectVar.Property, TextValue   ; ObjectVar.Property := "TextValue"

I meant to mention earlier (but went off on a tangent and forgot) the other "main" benefit of command syntax: some new users/non-programmers find it easier to use. This syntax (above) seems more straightforward to me than the proposed syntax. However, it's still more typing and no more clarity than a normal assignment/expression.

[guest3456]

If we introduce Get/Set command syntax for objects, it seems incongruous to not do so for variables. Something like this might work (but I'm not convinced it should be implemented)
...
This syntax (above) seems more straightforward to me than the proposed syntax. However, it's still more typing and no more clarity than a normal assignment/expression.

I much perfer the Get/Set commands, but also not convinced yet of the necessity.

I guess another case in favor of it is that the literal = is gone in v2, so newbies will have to learn expression syntax with the := assignment, whereas Get/Set commands allow them to delay that.

[lexikos]

Newbies will already have to learn expression syntax for any scripts with even basic conditional logic, because IF requires an expression.

[just me]

My comment about "Command syntax for objects" posted here:

I don't! IMO, it's just another feature to discourage "new to ahk" programmers.

There is a fine line between "noob friendly" and "new to ahk friendly". I tend to side with "noob friendly".
Source

The command syntax is the "noob friendly" side of AHK, but they shouldn't try to use objects as long as they are "noobs".

What do you think, how my workmates reacted when I was asked "How did you do it?" and answered "I did it with AutoHotkey."?
"A u t o w h a t ? ? ?"! And none of them took more than a short look at the documentation.

That's one of my reasons to side with "new to ahk friendly". Once we've got the interest of a programmer, he'll most likely stay a while longer than most of the "noobs".

And none of them took more than a short look at the documentation.

Additional information: Two of them went to AutoIt after that short look.

[guest3456]

My comment about "Command syntax for objects" posted here:

What do you think, how my workmates reacted when I was asked "How did you do it?" and answered "I did it with AutoHotkey."?
"A u t o w h a t ? ? ?"! And none of them took more than a short look at the documentation.

That's one of my reasons to side with "new to ahk friendly". Once we've got the interest of a programmer, he'll most likely stay a while longer than most of the "noobs".

Additional information: Two of them went to AutoIt after that short look.

All of this can be handled with the copy on the homepage as well as clearer documentation. You would be surprised about the power of words and the impression it leaves on its audience.

You are blaming the language for your co-worker not sticking with AHK. Maybe thats true, maybe its not. A case can just as easily be made that he left because of what he read during his 'short look' at the docs. Could the copywriting on the homepage/docs have convinced him to give the language a shot? I'm certain of it.

You can simply have one of the first doc pages explain the difference, so when your coworker stumbles upon it, he may stay instead of leave:

Functions vs Commands

AutoHotkey2 allows all of the AHK v1 commands to be called as functions. This will be the familiar syntax for most programmers. Consider this example code:

Code: Select all

OutputVarTitle := WinGetActiveTitle()
MsgBox("Press OK and the text 'Hello World' will be sent to this window: " . OutputVarTitle)
Send("Hello World")

This syntax should be straightforward and clear for most computer programmers.

The original AutoHotkey v1 syntax was designed to be simple, so that casual computer users could write quick scripts without devoting a huge amount of time into learning a programming language. This eventually became limiting to power users. However, AutoHotkey2 retains this capability, and even expands upon it by allowing user-created functions to also be called with the command syntax, if they so choose.

The command syntax consists of writing the command name, followed by an optional comma, and then followed by the parameter list according to the docs. All of the parameters are simply literal text (but expressions [link] can be used as well). For example:

Code: Select all

WinGetActiveTitle, OutputVarTitle
MsgBox, Press OK and the text 'Hello World' will be sent to this window: %OutputVarTitle%
Send, Hello World

The choice to use function or command syntax is left up to the user. AutoHotkey2 encourages the more powerful function/expression syntax, and doesn't aim to be backward compatible with AHK v1. Nonetheless, conveniences in the language remain for both newbie and existing users.

I wrote that in 10 minutes.

I don't even know about the truth or accuracy of any of it. Surely spending more time could clarify and make it better, especially with contributions from others. You could reverse the order that I used, and describe the command syntax first, and then the function syntax. Maybe that would change the impression given (but would probably highlight commands over funcs). Maybe don't use "OutputVarTitle" and instead use "title_var". Etc. And this is only one page. Come to a consensus about what impression you want to give, what users you want to target, and then craft all of the pages to match that.

[Coco]

+1 for the "Hypothetical Doc Page". It's all about branding...