Anonymous Maps

[jaberwacky]

So I have an idea which I think will make coding a little easier in that a descriptive variable name need not be thought of in every case. I spend a bit of time in the outer regions thinking of hair brained ideas which are often shot down (rightfully so). However, I think I have a good idea, so I present to you and respectfully request the following:

Func _rect_from_points(Const $a1, Const $a2, Const $b1, Const $b2)      
	With []         
		.Left = ($a1 < $b1) ? $a1 : $b1         
		.Top = ($a2 < $b2) ? $a2 : $b2         
		.Width = ($b1 > $a1) ? ($b1 - .Left) : ($a1 - .Left)         
		.Height = ($b2 > $a2) ? ($b2 - .Top) : ($a2 - .Top)                 
	
		Return . ; or 
		; Return [] or 
		; Return .[] ??     
	EndWith
EndFunc

[anonymous]

This actually contains three proposals:

1. Allow maps as expressions in a "With" statement.

Example:

Local $map[]
$map.a = 1
With $map
    .b = .a
    .a = 2
EndWith

Maps and "Object-type variables" have the same syntax. That extension is only natural.

2. Create a shortcut for the expression in a With statement.

Example:

With $object
    Local $copy = .
    UseObject (.)
    . = Duplicate ($copy)
EndWith

What about ..element?
Saves at most one line, not intuitive, easy to miss, will confuse programmers and tools, strange semantics, might encourage overuse – probably a bad idea, but absolutely possible.
[] is a bad idea, see point 3. .[] is really strange, probably hard to implement and makes you assume that $object is a map, althrough it may be an "Object-type variable".
Maybe with an additional keyword or constant (@WithExpression).

3. Make [] the empty map.

Example:

Local $emptyMap[]
UseEmptyMap ($emptyMap)

$emptyMap = []
Local $emptyMap2 = ([])
UseEmptyMap ($emptyMap)
UseEmptyMap ($emptyMap2)

Note that the parentheses in the third-last line are a necessary syntactic disambiguation. Without them, it would be a broken array initialization (see #2845), or ambiguous. The same is true for 2d array initializations.
Again, this may save at most one line. It will confuse any programmer coming from any language where that is an expression for an empty array (JS, PHP, ...): they will use it thinking that it is an empty array, and will be legitimately surprised when their program breaks.
Definitely a bad idea.
Maybe with braces ({})?

[jaberwacky]

As far as I know AutoIt isn't trying to mimic or make it easy for JS, PHP, etc programmers. I'm sure all languages have their syntax differences that all people new to the language would have to learn. If someone coming to AutoIt from another language tries to use AutoIt the same way they used their previous language, that is an operator error.

[jaberwacky]

As far as I know AutoIt isn't trying to mimic or make it easy for JS, PHP, etc programmers. I'm sure all languages have their syntax differences that all people new to the language would have to learn. If someone coming to AutoIt from another language tries to use AutoIt the same way they used their previous language, that is an operator error.

[anonymous]

Sorry for the double post.

[anonymous]

Replying to jaberwacky:

As far as I know AutoIt isn't trying to mimic or make it easy for JS, PHP, etc programmers. I'm sure all languages have their syntax differences that all people new to the language would have to learn. If someone coming to AutoIt from another language tries to use AutoIt the same way they used their previous language, that is an operator error.

It makes AutoIt inconsistent and is not open for extensions.
Why not @EmptyMap?

[jaberwacky]

Replying to anonymous:

It makes AutoIt inconsistent and is not open for extensions.
Why not @EmptyMap?

I'm not exactly sure what you're saying with proposal 2 and 3.

Are you saying the idea is good but that the execution is bad?

@EmptyMap

Works for me.

[anonymous]

Rewind...

How does this make the language inconsistent? This only applies to maps and not arrays and not objects. Dot access does not imply object object orientation. I'm actually not trying to subtly sneak anything OO related into the language.

[anonymous]

Replying to jaberwacky:

I'm not exactly sure what you're saying with proposal 2 and 3.

I'm saying that you're proposing three different things and that they should be considered separately.

Are you saying the idea is good but that the execution is bad?

I think there were some problems and suggested possible refinements. Personally I support all three proposals.

Replying to anonymous:

How does this make the language inconsistent? This only applies to maps and not arrays and not objects. Dot access does not imply object object orientation. I'm actually not trying to subtly sneak anything OO related into the language.

I didn't even think about objects, they're a lost cause. I think that it's a bad idea to use one syntax for two different things: array and map creation.
I don't like the current way to create a map:
Local $map[]
I'd prefer
Local $map = {}
or
Local $map = Map ()
or
Local $map = NewMap ()
or
Local $map = @EmptyMap
because they make it clear what is happening.

But [] does not. Why should
Local $array = [] (array initialization)
and
Local $map = ([]) (empty map expression)
create different things?

[anonymous]

OK, everything is clear now. Thank you clearing that up. Now that I've reread your posts with my refreshed perspective, I agree with all points.

[jaberwacky]

OK, it occurred to me just now. Should I create three separate trac tickets for these proposals? I still think these three proposals do not cover my original feature request though. I was hoping to set up an anonymous map using With and then refer to the map accordingly. However, the syntax for the empty map did always seem somewhat wrong though.

With {}
    .Key1 = "Key1"
   
    ConsoleWrite(.Key1 & @CRLF)
EndWith

Is this a better syntax?

[anonymous]

With @EmptyMap ;or just EmptyMap(), where EmptyMap=lambda: {Local $map[] ; Return $map}

.key = 12345
Return @TheWithObject
;or @TheWithMap, but not @TheWithExpression, bc that would be expected to(and should?) return
; just the *expression* used in With stmnt (here it would be the @EmptyMap/EmptyMap()),
l and not the *modified* object/map itself!

EndWith