[Wish:] Again, wish the usage of "function definition expressions" to be eliminated

Discuss the future of the AutoHotkey language
lexikos
Posts: 9592
Joined: 30 Sep 2013, 04:07
Contact:

Re: [Wish:] Again, wish the usage of "function definition expressions" to be eliminated

10 Sep 2023, 03:32

@bonobo
Function definition expressions containing blocks currently aren't working. :oops:
bonobo
Posts: 75
Joined: 03 Sep 2023, 20:13

Re: [Wish:] Again, wish the usage of "function definition expressions" to be eliminated

10 Sep 2023, 03:51

lexikos wrote:
10 Sep 2023, 03:32
@bonobo
Function definition expressions containing blocks currently aren't working. :oops:
I see, thanks. I realized after posting it that not just "switch" blocks, but "if" blocks also inside function definition expressions will throw.

But the fact that basic control flow constructs are now possible inside anon functions already makes them more than powerful enough in my books.
bonobo
Posts: 75
Joined: 03 Sep 2023, 20:13

Re: [Wish:] Again, wish the usage of "function definition expressions" to be eliminated

18 Sep 2023, 10:09

In alpha 5 (viewtopic.php?p=539495#p539495), this code now works perfectly (thanks!):

Code: Select all

Array.Prototype.DefineProp("Find", {Call: (Arr, FindCondition){
	if HasMethod(FindCondition)
	{
		for i, e in Arr
			if FindCondition(e)
				return i
		return 0
	}
	else
	{
		for i, e in Arr
			if e==FindCondition
				return i
		return 0
	}
}})

MsgBox(([1,2,3]).Find(3)) ; 3

But (this probably falls under the 'and created more issues' comment) the following code fails to load at all with no error thrown. I've indicated the 2 lines changed by a comment (; <<<<) at the end

Code: Select all

Array.Prototype.DefineProp("Find", {Call: (Arr, FindCondition){
	if HasMethod(FindCondition)
	{
		for i, e in Arr
			if FindCondition(e)
				return i
		return 0
	}
	else
	{
		FindConditionFunc := (x) => x==FindCondition ; <<<<
		for i, e in Arr
			if FindConditionFunc(e) ; <<<<
				return i
		return 0
	}
}})

MsgBox(([1,2,3]).Find(3))

bonobo
Posts: 75
Joined: 03 Sep 2023, 20:13

Re: [Wish:] Again, wish the usage of "function definition expressions" to be eliminated

27 Sep 2023, 23:25

it occurs to me the immediately invoked function expression can be used to simulate block scope

In JS this code outputs first 2, then 1, to the console

Code: Select all

let v = 1 
{
	let v = 2
	console.log(v)
}
console.log(v)
in AHK this code displays first 2, then 1 via msgbox

Code: Select all

i := 1
((i?){
	i := 2
	Msgbox(i)
})()
Msgbox(i)
And if you have a function like this, but you don't want v1, v2 etc to have function scope

Code: Select all

func(){
if (condition) {
   v1 := 1
   v2 := 2
   ;  ...
}
; ....
}
you can wrap them inside a immediately invoked function expression

Code: Select all

func(){
if (condition) {
   (){
      v1 := 1
      v2 := 2
      ;  ...
   }()
}
; ....
}
Emily77
Posts: 1
Joined: 10 Oct 2023, 03:48
Contact:

Re: [Wish:] Again, wish the usage of "function definition expressions" to be eliminated

01 Nov 2023, 08:50

cumulonimbus wrote:
04 Sep 2023, 18:37
There are a lot of people who object to this way of defining things, but there are also a lot of people who like it, and what you think is "symbolic hell" may be a paradise of simplicity in the eyes of others.
It's true
That definitions can be quite subjective. What might seem like "symbolic hell" to one person could indeed be a source of clarity and simplicity for another.
User avatar
V2User
Posts: 195
Joined: 30 Apr 2021, 04:04

Re: [Wish:] Again, wish the usage of "function definition expressions" to be eliminated

03 Nov 2023, 22:49

Last reminder, unlocking limit should always be careful. It is not something of that you think it may be better and then do it. Once unlocked, it can never come back.
User avatar
RaptorX
Posts: 386
Joined: 06 Dec 2014, 14:27
Contact:

Re: [Wish:] Again, wish the usage of "function definition expressions" to be eliminated

24 Nov 2023, 17:25

lexikos wrote:
10 Sep 2023, 02:50
And you are missing the point. Imposing arbitrary restrictions will not force anyone to write readable code. Each author is free to write the code in whatever way he finds best, within the constraints of the language. I have no reason to take your opinion of what is readable as law. If an author wants to write unreadable code, he is free to do that as well, within the constraints of the language.
I wholeheartedly agree with this statement. As much as this feature irks me, I think each developer must write the code as they want. :roll: It is their responsibility to write code that is easy to maintain by them or any other unfortunate soul that will be tasked in the future. Nothing stops them from creating single letter variables and other things that I personally consider bad practice. But thats the beauty of it. Everyone does what makes sense to them.

What I think a lot of people are not realizing is that Autohotkey is maturing as a language. A lot of us are transitioning from simple one off scripts to more serious programming and Lexikos is doing an amazing job at bringing Autohotkey to a place that will make it easier for us to do advanced stuff if we so wish.

I guess the one thing we dont have entirely clear is whether Autohotkey is aiming to become a serious programming language as opposed to a simple scripting language to ease automation of certain tasks.

In my opinion one of the main points Autohotkey had as a proposition was how easy it was to create hotkeys/hotstrings and automating certain tasks (hence the name). Lately I feel that is more and more developer friendly (which I totally love) but I think the learning curve will be greater for new people starting out.

When the forums are filled with cryptic examples using this type of syntax many will just simply give up.

Is not a bad thing though. Is just that Autohotkey is changing. I do think the community will be changing as well, hopefully for the better. :roll:
Projects:
AHK-ToolKit

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 81 guests