What do you mean? Would you prefer to restrict which functions/commands the command syntax can be used with, as in v1?just me wrote:(though I don't like the idea of 'using functions as commands')
![Confused :?](./images/smilies/icon_e_confused.gif)
What do you mean? Would you prefer to restrict which functions/commands the command syntax can be used with, as in v1?just me wrote:(though I don't like the idea of 'using functions as commands')
definitely not thislexikos wrote:Would you prefer to restrict which functions/commands the command syntax can be used with, as in v1?It's pretty much arbitrary in v1 (or for historical reasons).
No, you didn't just say that. You also said that. You gave two seemingly opposite opinions, which is the cause of my confusion:just me wrote:I just said "I don't like it".
Code: Select all
OutputVar := ControlGet(Cmd [, Value, Control, WinTitle, WinText, ExcludeTitle, ExcludeText])
the translation is not a proposal, its already done. have you used v2?sinkfaze wrote: How would you propose to retire that command and replace it with a function? A literal translation of the command?
its not a bad idea to return an object, but now you're forcing users to understand how to use objects as well. i think thats a larger ask than simply asking users to understand how to use functions, which in many cases is already required given that AHK v1 mixed Commands and Functionssinkfaze wrote: Should the function be designed so that the user is limited to what they can grab on the frontend (one attribute at a time), or should it be designed to grab all possible attributes (saved to an object, for example) and let the user filter down to what they want on the backend?
Ideas and opinions that I haven't already considered are exactly what I want.sinkfaze wrote:Forgive my ignorance, particularly if this is not how you meant an answer to the questions, but I think that we should look at this a different way.
By replacing it with several functions, the same as I've done for WinGet. My initial idea was to merge it somehow with GuiControlGet (that is, have one set of functions covering both); I mentioned it under Commands with sub-commands:Take the ControlGet command. How would you propose to retire that command and replace it with a function?
However, since then I've used fincs' GUI system a bit and come to the opinion that it is much more manageable than the current system. (Merely turning sub-commands into functions doesn't make much difference.) The code duplication can be fixed without changing the interface. Aside from that, I never solved that point about usability.I wrote:Rather than creating 50+ functions out of the Gui/Control/Get sub-commands, I'd like to merge the functionality of the Gui and non-Gui commands. This may help improve consistency and reduce code and documentation size. However, I'm not sure how to do it without reducing the usability of the command set with the script's own GUIs (e.g. the GuiControl commands support control names and implicitly operate on the default Gui).
That sounds like more work than converting ControlGet etc. to functions, even if you don't consider the need to show both ways on each page.Or should there just be better documentation to let the user decide for themselves what they want and how they want it?
I've had similar thoughts while looking at interfacing AutoHotkey's functionality with Lua, Python, JavaScript and .NET. Some of the commands are designed in ways that most suit the command syntax - the Gui command being the most extreme example (I think). More to the point, I'd been thinking that virtually all of the commands which accept WinTitle parameters would be better off as methods of a "Window" or "Control" object, at least for these other languages. Perhaps that would be true for AutoHotkey v2 if it has no command syntax.Given how the language has evolved to this point (particularly with the introduction of objects/arrays), is this the most optimal method of representing that command as a function?
It's not necessary to retrieve everything at once; you can return an object which implements dynamic properties.sinkfaze wrote:if there is no significant time loss to retrieve all available information about an item it may prove more satisfactory to return all data in objects in the future rather than a single piece in a variable.
Source: Command Object function library NEW [Replace functions]
In a future release, all functions will be implemented the same way, and the "command syntax" (if present) may translate to exactly the same "byte-code" as the equivalent expression. In that case, there will be no performance difference.As commands and functions are still internally distinct in the current v2 alpha, defining a function with the same name as a command overrides the command only for the function() style of calling; i.e. the command style still calls the original command. This should be changed.
Source: v2-thoughts
An answer can be found in v2-changes or by calling the function with the current v2 alpha.hobboy wrote:If command syntax was to disappear, would the function output the important result rather than place it in errorlevel, or would the output be blank?
IfEqual is irrelevant - it's already been removed in v2-alpha. That was one of the very first changes.boiler wrote:I cannot see how anyone thinks it is more intuitive for someone learning the language to use IfEqual, lcolor, %color%.
I already said command syntax is easier for non programmers to grasp.guest3456 wrote:Tank, so are you suggesting keeping Command syntax but requiring all parameters to be expressions? If so, then whats the point of keeping commands at all?
The way it is expressed defines what can be done.tank wrote:Im not suggesting changing what a command can accept only how it is expressed.
Nonnnik wrote:Either
Msgbox ThisisSomeVar
or
Msgbox "This is a String"
since
Msgbox "This is a string" ThisisSomeVar
is already expression syntax.
Which would essentially remove all capabilities of dynamic coding without Expression syntax?tank wrote:Nonnnik wrote:Either
Msgbox ThisisSomeVar
or
Msgbox "This is a String"
since
Msgbox "This is a string" ThisisSomeVar
is already expression syntax.
"this is a string" is just a string not an expression
under my suggestion.% "this is a string" is still expression syntax and unless the command expects a var for a param it must still require expression syntax
msgbox % myvar
Code: Select all
Msgbox Some Text %SomeVar%
Yes this mix has proven over and over to confuse peoplennnik wrote:Which would essentially remove all capabilities of dynamic coding without Expression syntax?
Return to “AutoHotkey Development”
Users browsing this forum: No registered users and 25 guests