I have tried to put some more thoughts into the topic, specifically I wanted to come up with reasons to scrap it, so I don't regret saying
I want to keep it. I'm still undecided but have questions, comments, opinions and things to note. In no particular order,
Code examples
I took a function from the
gdip lib by
tic, and
converted it to the new syntax, so we can look at a
real example, as opposed to just
msgbox or
x y,z examples. This function does many calls without retrieving the return values, I put all versions in one code box, I suggest you put them in your editor in different tabs and alternate between them.
Code: Select all
; 1. Original
Gdip_FillRoundedRectangle(pGraphics, pBrush, x, y, w, h, r)
{
Region := Gdip_GetClipRegion(pGraphics)
Gdip_SetClipRect(pGraphics, x-r, y-r, 2*r, 2*r, 4)
Gdip_SetClipRect(pGraphics, x+w-r, y-r, 2*r, 2*r, 4)
Gdip_SetClipRect(pGraphics, x-r, y+h-r, 2*r, 2*r, 4)
Gdip_SetClipRect(pGraphics, x+w-r, y+h-r, 2*r, 2*r, 4)
E := Gdip_FillRectangle(pGraphics, pBrush, x, y, w, h)
Gdip_SetClipRegion(pGraphics, Region, 0)
Gdip_SetClipRect(pGraphics, x-(2*r), y+r, w+(4*r), h-(2*r), 4)
Gdip_SetClipRect(pGraphics, x+r, y-(2*r), w-(2*r), h+(4*r), 4)
Gdip_FillEllipse(pGraphics, pBrush, x, y, 2*r, 2*r)
Gdip_FillEllipse(pGraphics, pBrush, x+w-(2*r), y, 2*r, 2*r)
Gdip_FillEllipse(pGraphics, pBrush, x, y+h-(2*r), 2*r, 2*r)
Gdip_FillEllipse(pGraphics, pBrush, x+w-(2*r), y+h-(2*r), 2*r, 2*r)
Gdip_SetClipRegion(pGraphics, Region, 0)
Gdip_DeleteRegion(Region)
return E
}
; 2. Original but extra spaces after opening ( and before closing )
Gdip_FillRoundedRectangle( pGraphics, pBrush, x, y, w, h, r )
{
Region := Gdip_GetClipRegion( pGraphics )
Gdip_SetClipRect( pGraphics, x-r, y-r, 2*r, 2*r, 4 )
Gdip_SetClipRect( pGraphics, x+w-r, y-r, 2*r, 2*r, 4 )
Gdip_SetClipRect( pGraphics, x-r, y+h-r, 2*r, 2*r, 4 )
Gdip_SetClipRect( pGraphics, x+w-r, y+h-r, 2*r, 2*r, 4 )
E := Gdip_FillRectangle( pGraphics, pBrush, x, y, w, h )
Gdip_SetClipRegion( pGraphics, Region, 0 )
Gdip_SetClipRect( pGraphics, x-(2*r), y+r, w+(4*r), h-(2*r), 4 )
Gdip_SetClipRect( pGraphics, x+r, y-(2*r), w-(2*r), h+(4*r), 4 )
Gdip_FillEllipse( pGraphics, pBrush, x, y, 2*r, 2*r )
Gdip_FillEllipse( pGraphics, pBrush, x+w-(2*r), y, 2*r, 2*r )
Gdip_FillEllipse( pGraphics, pBrush, x, y+h-(2*r), 2*r, 2*r )
Gdip_FillEllipse( pGraphics, pBrush, x+w-(2*r), y+h-(2*r), 2*r, 2*r )
Gdip_SetClipRegion( pGraphics, Region, 0 )
Gdip_DeleteRegion( Region )
return E
}
; 3. No (), added one space only
Gdip_FillRoundedRectangle(pGraphics, pBrush, x, y, w, h, r)
{
Region := Gdip_GetClipRegion(pGraphics)
Gdip_SetClipRect pGraphics, x-r, y-r, 2*r, 2*r, 4
Gdip_SetClipRect pGraphics, x+w-r, y-r, 2*r, 2*r, 4
Gdip_SetClipRect pGraphics, x-r, y+h-r, 2*r, 2*r, 4
Gdip_SetClipRect pGraphics, x+w-r, y+h-r, 2*r, 2*r, 4
E := Gdip_FillRectangle(pGraphics, pBrush, x, y, w, h)
Gdip_SetClipRegion pGraphics, Region, 0
Gdip_SetClipRect pGraphics, x-(2*r), y+r, w+(4*r), h-(2*r), 4
Gdip_SetClipRect pGraphics, x+r, y-(2*r), w-(2*r), h+(4*r), 4
Gdip_FillEllipse pGraphics, pBrush, x, y, 2*r, 2*r
Gdip_FillEllipse pGraphics, pBrush, x+w-(2*r), y, 2*r, 2*r
Gdip_FillEllipse pGraphics, pBrush, x, y+h-(2*r), 2*r, 2*r
Gdip_FillEllipse pGraphics, pBrush, x+w-(2*r), y+h-(2*r), 2*r, 2*r
Gdip_SetClipRegion pGraphics, Region, 0
Gdip_DeleteRegion Region
return E
}
; 4. No (), added one tab
Gdip_FillRoundedRectangle(pGraphics, pBrush, x, y, w, h, r)
{
Region := Gdip_GetClipRegion(pGraphics)
Gdip_SetClipRect pGraphics, x-r, y-r, 2*r, 2*r, 4
Gdip_SetClipRect pGraphics, x+w-r, y-r, 2*r, 2*r, 4
Gdip_SetClipRect pGraphics, x-r, y+h-r, 2*r, 2*r, 4
Gdip_SetClipRect pGraphics, x+w-r, y+h-r, 2*r, 2*r, 4
E := Gdip_FillRectangle(pGraphics, pBrush, x, y, w, h)
Gdip_SetClipRegion pGraphics, Region, 0
Gdip_SetClipRect pGraphics, x-(2*r), y+r, w+(4*r), h-(2*r), 4
Gdip_SetClipRect pGraphics, x+r, y-(2*r), w-(2*r), h+(4*r), 4
Gdip_FillEllipse pGraphics, pBrush, x, y, 2*r, 2*r
Gdip_FillEllipse pGraphics, pBrush, x+w-(2*r), y, 2*r, 2*r
Gdip_FillEllipse pGraphics, pBrush, x, y+h-(2*r), 2*r, 2*r
Gdip_FillEllipse pGraphics, pBrush, x+w-(2*r), y+h-(2*r), 2*r, 2*r
Gdip_SetClipRegion pGraphics, Region, 0
Gdip_DeleteRegion Region
return E
}
Number
3 is not very nice in my opinion, number
4 is much better, I prefer number
2. What do you (all) think? I wonder if those who voted to keep, would use it like this? I wouldn't. In the next example, the functions are well known, which helps I think, and uses zero to one parameter,
Code: Select all
; "Original"
run("notepad")
winWaitActive("ahk_class Notepad")
send("hello")
sleep(1000)
winClose()
exitapp()
; No (), one space added
run "notepad"
winWaitActive "ahk_class Notepad"
send "hello"
sleep 1000
winClose
exitapp
Omitting the parentheses works well here I think.
One-line hotkeys
Currently,
makes the hotkey call
func, even though
func isn't at the beginning of a line, at least not in the scripter's text editor, I guess it is internally interpreted as
I consider this mostly nice, eg,
a::send "text", but
a::b is a remapping, and
a::b c is a function call. So there are some special cases, depending on the function name, and if passing parameters or not, to consider and document.
Omitting the first parameter
I really do not like the call without parantheses when the first parameter is omitted,
Code: Select all
f x,y
; omitting x
f ,y
f ,y
f(,y)
msgbox msg,title
; omitting msg
msgbox ,title
msgbox(,title)
I wonder if anyone likes this? In this context,
f(,y) looks
beautiful .
Variadic* calls
Note, currently, variadic calls doesn't work, they should I guess, so either it is not yet implemented or maybe I missed a note about it in
one of the pages. There are two errors,
too few parameters, and
missing operand,
Code: Select all
f p* ; missing operand
g [x,y]* ; too few parameters
f(a){
}
g(a,b){
}
Just as we could allow
x ? y : z, I wonder, given that variadic calls are suposed to work, should we allow
Code: Select all
f p*, (expr)
; equivalent to
f(p*), (expr)
it could look a bit odd.
Object notation
I really do not like the notation for method calls, there is already some awkwardness in that parentheses can be used with properties, eg,
Code: Select all
obj.xyz ; Property get or method call?
obj.xyz w ; same question.
No conclusions
User communication
lexikos wrote:The fact you have highlighted is of very little relevance.
I do not think a fact about the discussed topic is of very little relevance, even if it doesn't qualify as a stong argument, either for or against. Your addition about throwing an error highlights that the mistake sometimes is easy to spot, sometimes not.
The problem "arises" when the program does not behave as expected
Anyone might eventually experience bugs in their code due to putting a space before the parentheses
The novelty I tried to highlight is the case when the outcome of the
old mistake is a function call, consequently, when you get unexpected results, the problem is more likely to appear to be related to the inners of the function, rather than at the place where it was called, making it more difficult to find. I consider it worth noting.
I was not talking of the act of interpreting, but the meaning being assigned.
That make sense, I should have figured, I apologise.
@
juan, hello.
the specific case of the function calls without parentheses is trivial and easily understandable, even for beginners
[...] if a line begins with a function call, the parentheses can be omitted
[...] That's all.
Your specific example with the
msgbox is easy to understand and readable, I agree. But from the perspective of a novice, something like this,
which isn't equivalent to
might not be
trivial and easily understandable, I would probably have a hard time getting used to that too. I do not think the sweet taste of AHK is greatly affected by the presence or absence of this syntax.
Cheers.