[Idea:] Add baseX{...} syntax

[V2User]

Among far more than 80% of object literals, we will probably give it base property everytime we write the literal {}. They will almost certainly look like this: {base:x,...}. Therefore, as base: is occurred so frequently when object lieral occur, why not just omit base: just for a small simplification of the codes? How about this idea below?
g1:=gui(),t:=g1{prpt1:'cc'}. It would equal to g1:=gui(),t:={base:g1,prpt1:'cc'}.
For example, these three lines below would be equal to each other.

Code: Select all

;These three lines will be equal to each other.
m:=Map('key1',3,'key2',5,'key3',7)            ;it is the current code.
m:=Map{key1:3,key2:5,key3:7}()  ;it's actually shorter than the current
m:={base:Map,key1:3,key2:5,key3:7}()
;By the way, it is not exactly right, as a key string starting with any number can not completely be suppported by object literal. I use Map just for a example.

Another important reason to encourage this new syntax is that the old syntax is actually "not right". Because {base:GUI} is originally based on GUI, but {base:GUI} in reality doesn't have the base "property" which is only owned by Any instead. So, object literal had better not contain base as if a property. It's easy to mistake. It never owns base at the beginning. base is just something special which just produces inconsistency with other else normal properties within an object literal. A special syntax handle to a special base like baseX{prptX:...} will look much better in my opinion.

image.png (35.35 KiB) Viewed 1485 times

As we see, Even zero-plusplus, which is the famous ahk debug plugin in VSCode, does show every AHK object just exactly like this for a long time.
It would not break the existing codes. More interestingly, the three of them: a(),a[],a{}, would keep consistency with each other. Perhaps this would occur in V2.x if you could consider the Grammar Pond.

[swagfag]

Among far more than 80% of object literals, we will probably give it base property everytime we write the literal {}

source: i made it up lmao

yeah, lets not introduce nonsense syntax into the language with no apparent purpose other than to satisfy ur attempts to emulate kwargs

[SandyClams]

I was curious, so I messed around with this for a second.

first of all, m := { base: Map, key1: 3, key2: 5, key3: 7 }() doesn't even do anything; it just throws an error. I'm assuming the reason is because the static Call method on the Map class object requires a class as its this argument, while calling the object literal only forwards that literal itself as the this argument. The best I can do is m := ({ base: Map, key1: 3, key2: 5, key3: 7 }.Call)(Map), which does work, but which imo is definitely not the option of greatest convenience, and which doesn't even assign to the object.

beyond that, you know that's not even how Map keys work, right? So even if we did use this syntax, and it worked, it wouldn't do the same thing as calling the class object; it would just assign members to the object literal.

[V2User]

I was curious, so I messed around with this for a second.

first of all, m := { base: Map, key1: 3, key2: 5, key3: 7 }() doesn't even do anything; it just throws an error. I'm assuming the reason is because the static Call method on the Map class object requires a class as its this argument, while calling the object literal only forwards that literal itself as the this argument. The best I can do is m := ({ base: Map, key1: 3, key2: 5, key3: 7 }.Call)(Map), which does work, but which imo is definitely not the option of greatest convenience, and which doesn't even assign to the object.

beyond that, you know that's not even how Map keys work, right? So even if we did use this syntax, and it worked, it wouldn't do the same thing as calling the class object; it would just assign members to the object literal.

@SandyClams
A Map2 extends from Map with static call() defined to override the default Map.call() can perfectly solve it:

Code: Select all

class Map2 extends Map{
	static call(){
		OutputDebug(this.key1 '`n')
		return (super.Call)(%super.Prototype.__class%)
	}
}
m:={base:Map2,key1:5,key2:7}()

By the way, it is not right at the beginning. Because a key string starting with any number can not be suppported. I use Map just for a example.

[V2User]

Among far more than 80% of object literals, we will probably give it base property everytime we write the literal {}

source: i made it up lmao

yeah, lets not introduce nonsense syntax into the language with no apparent purpose other than to satisfy ur attempts to emulate kwargs

@swagfag
I really made up "80%". But there are really a significant part of object literals which contains base:, at least in my own view.

other than to satisfy ur attempts to emulate kwargs

It's not exactly right. {...} is not kwargs and is more powerful than kwarg. I use keywordpara just for a inappropriate example.
Despite that many of my suggestions are trivial and not that important, I just want the language to become truly better.

[lexikos]

Therefore, as base: is occurred so frequently, ...

This is what I would call a false premise. Since you seem keen to invent your own paradigm, or something like that, why don't you write a transpiler and implement your own syntax?

x{} is reserved for other, more general purposes.