Jump to content

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

AutoHotkey_L v1.0.90 and Roadmap


  • Please log in to reply
48 replies to this topic
jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009

I would like to see the ability to completely define an object & all it's members in one block.

I don't see what the fuss is about. If you just lump the function definitions together, what's the difference?

Not fussing, just suggesting it would be nice to have the ability (not requirement). Might be easier for those who are used to a class-syntax to adjust. For community reference, here's a few examples from other Prototype-based languages:
; Lua
obj = {name="Test Object: "}
function obj.speak (text)
	print(obj.name .. text)
end
obj.speak("Hello World")

; REBOL
obj: make object! [
	name: "Test Object: "
	speak: func[text] [
		alert rejoin[Self/name text]
	]
]
obj/speak "Hello World"

; JavaScript
function obj() {
	this.name = "Test Object: ";
	this.speak = function(text) {
		Shell = new ActiveXObject("WScript.Shell");
		Shell.Popup(this.name+text);
	}
}
obj = new obj;
obj.speak("Hello World");

... something else I have thought about but haven't really planned: function references. If a function reference can be assigned to a variable and called naturally as var(), that would solve any name-spacing issues for functions-in-functions.

+1

[regarding my example] ... I'm concerned that users would expect to be able to access local variables of the outer function from within the inner function, as in languages like JavaScript. I don't think closures are feasible with the current architecture, but on the other hand I wouldn't want to allow functions-in-functions now (merely for "tidy" code) then later be forced to break compatibility if closures become possible.

Yes - the less ignorant I become, the more I realize how correct you are. (just realized the above Lua example could be rewritten like my syntax proposal)

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006
I don't see whats the fuss either since Lexikos already explained that it will be just as in Lua above (or very similar).
Posted Image

JoeSchmoe
  • Members
  • 304 posts
  • Last active: Feb 28 2013 05:39 PM
  • Joined: 17 Feb 2008

v1.0.features.bugfixes

Glad to see it. From what I've heard, it sounds like this will help people assess which version they want to use in production environments.

I have also reviewed my ever-changing TODO list and turned it into a roadmap of sorts. Feel free to comment on anything in that document

There were three things that I saw in your roadmap that really excited me.

The first was just the document itself. It's good to see a leader with a clear vision putting a lot of thought into design and consulting with the community.

The second was the idea of supporting JSON sugar for object creation. There may inevitably need to be differences between AHK_L and IronAHK, but anything which brings them closer is great for the community, IMHO.

The third was that I was really thrilled to see that you are planning to build off of the preexisting version AHK 2 roadmap. It's time for AHK to move beyond some of the legacy quirks it has, and I think that using that document as a reference could help you and Polyethene coordinate your changes so that the changeover is as easy as possible on the community.

This is a minor extra point, but I really love the idea of named arguments. I think that newbies will find them very intuitive, and I know that I'd find them very helpful for functions that have many optional parameters.

Frankie
  • Members
  • 2930 posts
  • Last active: Feb 05 2015 02:49 PM
  • Joined: 02 Nov 2008
I haven't seen this brought up before (if it has feel free to just link) but why can't you use = to assign an array item?
Array := Object()
Array[1] = This is text ;Doesn't seem to do anything
Msgbox % Array[1] ;Shows nothing...
Array[1] := "This is text" ;Works
Msgbox % Array[1]
I don't think its a bug, so I posted it here.
Also, if when using "=" you put a period at the end of the text it gives an error. Could you explain this?

Thanks,
Frankie
aboutscriptappsscripts
Request Video Tutorials Here or View Current Tutorials on YouTube
Any code ⇈ above ⇈ requires AutoHotkey_L to run

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
Var=Text assignments are just that. Only expressions are capable of array/object access. If Array[1] = This is text worked it would be mixing an expression with traditional syntax, but in actuality it is equivalent to Array[1] == This . is . text, except that it isn't case sensitive. Similarly, the = in Func() = Var is also a comparison.

Also, if when using "=" you put a period at the end of the text it gives an error. Could you explain this?

If you mean like Array[1] = This is text., it's a syntax error (because that isn't text).

Frankie
  • Members
  • 2930 posts
  • Last active: Feb 05 2015 02:49 PM
  • Joined: 02 Nov 2008
Thank you, that makes sense.
aboutscriptappsscripts
Request Video Tutorials Here or View Current Tutorials on YouTube
Any code ⇈ above ⇈ requires AutoHotkey_L to run

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
I've updated the roadmap with my current progress, including a few items that weren't there before. I've changed VT_UNKNOWN, VT_ARRAY and any others that aren't either specifically handled or coerced to strings to be returned in a wrapper object. ComObjType(comObj) returns the variant type code. When I implemented it, I figured it was a good opportunity to make another change that similarly breaks compatibility (hopefully for the better): free VT_UNKNOWN or VT_ARRAY values automatically, where appropriate. Basic built-in support for VT_ARRAY (see the roadmap) looked simple, so I got side-tracked and implemented that first.

For VT_ARRAY I suspect the built-in support will be sufficient, so automatically freeing the array seems necessary. For VT_UNKNOWN I'm a little unsure, since the script will need to extract the IUnknown* pointer from the wrapper object before actually being able to do anything with it. At least if something returns VT_UNKNOWN and the script doesn't handle it, the pointer can be released automatically.

Frankie
  • Members
  • 2930 posts
  • Last active: Feb 05 2015 02:49 PM
  • Joined: 02 Nov 2008
Am I remembering wrong, or was returning objects from some built-in commands/functions removed from the roadmap? Thats one of the main features I was looking forward to.
aboutscriptappsscripts
Request Video Tutorials Here or View Current Tutorials on YouTube
Any code ⇈ above ⇈ requires AutoHotkey_L to run

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
I haven't removed anything from the roadmap. I split the "v1.0.90 - v1.1.00" section in two; maybe that confused you. SplitStr() and RegExMatch improvements are still under "v1.1.x".

sumon
  • Moderators
  • 1317 posts
  • Last active: Dec 05 2016 10:14 PM
  • Joined: 18 May 2010

Thanks for the info and roadmap!

Also, I like Jethrow's idea of not having to declare arrays. For backwards compatibility they should still be allowed to be declared (at least until v2).

Another note: It would be nice if you included a copy of the 32 bit compiler in the 64 bit install. I have a 64 bit computer and downloaded the 32 for that reason.


Good request. I do not know the advantages of 64 bit (other than in some cases, speed, I guess), but compiling in 64 bit is a big no-no. Compatibility should be total for executables.

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
x64 binaries are needed on x64 machines because of registry and file system redirection. Adding both bin files to a release might help a bit, but anyone who wants to distribute both versions is probably smart enough to download the other one, too.

Frankie
  • Members
  • 2930 posts
  • Last active: Feb 05 2015 02:49 PM
  • Joined: 02 Nov 2008

anyone who wants to distribute both versions is probably smart enough to download the other one, too.

The current download for AutoHotkey_L is only an installer, as in overwrite whatever is there. You would have to rename the bin file / installer before installing and it would be annoying to have to download it more that twice (twice is too much) if you messed up.

So save time and headaches and include both.
aboutscriptappsscripts
Request Video Tutorials Here or View Current Tutorials on YouTube
Any code ⇈ above ⇈ requires AutoHotkey_L to run

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
If you look a bit further down the page, you will see that there are archives.

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

Support super-global variables, perhaps by using the "global" keyword outside of any function. Super-global variables would be automatically accessible in assume-local functions, without additional declarations.


just curious, what is the purpose of these super globals? i dont understand why someone would need to have a super global that is accessable in an assume local function. why couldnt they just declare the global var like so?

g_myvar := "hello global world"

myfunc()

return



myfunc()
{
   global g_myvar       ;// assume local, declare the global needed
   msgbox, %g_myvar%
}


fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
Convenience. If there are variables that are needed in many functions, it is easier to define it as global variable for all functions.