Code: Select all
Foo(X)
{
MsgBox % "This should not execute."
}
Func("Foo").Bind("").Call
I had cause to write code like this. I have already found a workaround. It should still be fixed.
Code: Select all
Foo(X)
{
MsgBox % "This should not execute."
}
Func("Foo").Bind("").Call
I discovered this problem while writing a library to do exactly what you are trying to do. It currently contains a workaround for this problem.
My justification for considering this a defect are:nnnik wrote: ↑02 Jan 2019, 05:13I fail to see how this is a bug - after all the documentation does not state that this doesn't happen - or what happens if you get the call element in a boundfunc.
I agree with you though that this is a good suggestion.
But I still don't see how it will help you identifying boundfuncs.
it executes get if implemented.reading the Call property on a user-defined type that does or does not have one does not cause anything to execute
At least it isn't desirable, as far as I am concerned.it is undesirable
I am quite certain that there is an explanation in both v1's and v2's implementation for this behavior. That does not mean the behavior as implemented is as it should be. Source code is not a holy text that must be unquestioningly obeyed and never changed.Helgef wrote: ↑03 Jan 2019, 04:01it executes get if implemented.reading the Call property on a user-defined type that does or does not have one does not cause anything to execute
Looking at the (v2) implementation, I see that BoundFunc handles invoking call the same way regardless if it is set, get or call, so you can even do bf.call[x], bf.call := x or bf[x] := y, which will pass x,y as parameters to the function. Until BoundFuncs has any documented properties, I don't see any reason to handle set and get.
At least it isn't desirable, as far as I am concerned.it is undesirable
Cheers.
[Shambles], obviously the source code is responsible for any behaviour, in no way did I try to justify the behaviour with it being caused by source code. I meant only to highlight the extent of the behaviour. I have suggested to change BoundFuncs to not handle getting and setting, for the alpha branch #127. Anything else than calling Call on a BoundFunc would cause an exception.I am quite certain that there is an explanation in both v1's and v2's implementation for this behavior. That does not mean the behavior as implemented is as it should be. Source code is not a holy text that must be unquestioningly obeyed and never changed.
If that is for v2 (which I am told reports errors), then that is great (and as it should be)! If that is for v1, please reconsider.Helgef wrote: ↑03 Jan 2019, 09:56[Shambles], obviously the source code is responsible for any behaviour, in no way did I try to justify the behaviour with it being caused by source code. I meant only to highlight the extent of the behaviour. I have suggested to change BoundFuncs to not handle getting and setting, for the alpha branch #127. Anything else than calling Call on a BoundFunc would cause an exception.I am quite certain that there is an explanation in both v1's and v2's implementation for this behavior. That does not mean the behavior as implemented is as it should be. Source code is not a holy text that must be unquestioningly obeyed and never changed.
Cheers.
I am aware of no place, including in any other programming language, where reading a property causes its contents to execute. That is probably because it is obviously a foolish, dangerous idea.nnnik wrote: ↑03 Jan 2019, 08:34I wouldnt say its inconsistent - there are a few other places where Get or Set can be used on Object Methods within AHKs build in Objects.
I'm sure that there is some documentation on this regarding compatability with vba or some other language.
Its a historical thing - so Im not convinced we can change it in v1.
I see your links, but I am not sure how to observe this behavior myself. I do not want to perform dangerous operations on a file object, so tell me how to make an enumerator misbehave by reading properties. I have never encountered this problem myself. I am pretty familiar with enumerators, having written a complex one here. I assume the misbehavior I mentioned only occurs on built-in enumerators though.nnnik wrote: ↑03 Jan 2019, 11:30https://www.autohotkey.com/docs/objects ... tm#Example
https://www.autohotkey.com/docs/objects/File.htm#Seek
Are the cases I still remember. A while back I spend a lot of time trying to make call the only possible usage in this case.
At one point however I lost the overview and motivation.
This syntax is in use and we cannot change it for v1.
Code: Select all
enum := obj._NewEnum()
While enum[k, v]
Brackets [] may be used in place of parentheses () if N is specified.
Code: Select all
RegExMatch("11", "O)^(.*)$", match)
Msgbox % match.pos[1]
Msgbox % match.len[1]
Msgbox % match.Value[1]
Okay, fine, so a minority of built-in objects allow weird syntax. Limit the weird syntax to those situations. You already do this. As I have repeatedly pointed out, the normal behavior in v1 is for failed reads to return empty strings and failed writes to do nothing, except on external COM objects where they throw exceptions. Fixing BoundFunc objects to not be hazardous will not break anyone's code. There is no documentation suggesting people call BoundFuncs (and only BoundFuncs, not Funcs or user-defined function objects) by reading their Call property.nnnik wrote: ↑03 Jan 2019, 13:44What I was refering to was specifically this piece of code in the documentation:Another example is the match Object:Code: Select all
enum := obj._NewEnum() While enum[k, v]
https://www.autohotkey.com/docs/command ... atchObjectBrackets [] may be used in place of parentheses () if N is specified.Im unable to remember the specific way to trigger related behavior in FileObjects.Code: Select all
RegExMatch("11", "O)^(.*)$", match) Msgbox % match.pos[1] Msgbox % match.len[1] Msgbox % match.Value[1]
It might be that Im mixing up Set and Get with Set, Get and Call.
And its not important enough for me to look into it really.
Do I ever wish that were true! If it was true, the addition of BoundFunc objects a year or two ago would not have destroyed two of my libraries by having an interface inconsistent with Func objects.
A bad reason, I am sure. Most cases where AutoHotkey deviates from normal programming language design are very, very bad.
Thank you! I had forgotten that the universe does not revolve around me!
Yes, something important like fixing defects that could, in plausible situations, cause data loss.
I do not believe anyone is relying on reading Call on (only) BoundFuncs causing them to execute. I demand uncontrived, unmanufactured evidence to the contrary to believe that fixing this defect will break anyone's code.nnnik wrote: ↑03 Jan 2019, 13:44So when you one-sidedly decided that getting .call should do nothing, therefore relying on undocumented behavior you made the wrong assumption and ended up with broken code.
Now after this has happened you want the language to fit your needs and add new documented behavior that guarantees the things you expect, breaking everyone elses code in the process?
You are the one insisting on preserving a dangerous defect. I am the one who found it, reported it, explained how to trigger it reliably, explained why the code that triggers it was useful, and specified how it should be fixed. I am not the one being unreasonable here.
Ah, I am so glad you asked!
Not only is it surprising and not intuitive, it is downright wrong!
I am sure that will be of great help, just as soon as it becomes the primary version. Not that I want it to be rushed. v2 does not go nearly far enough fixing AutoHotkey's problems. Maybe it will in 10 more years. Until then, people like me will have to use undocumented behavior to cope in v1, unless an alternative is provided.
I already built a type thing. It works, despite this defect. This defect cost me over an hour trying to figure out why some test code was behaving as it was.nnnik wrote: ↑03 Jan 2019, 13:44@Offtopic:
Since you are building a type thing you might be interested in this:
https://p.ahkscript.org/?p=d1147e77
Users browsing this forum: lexikos and 27 guests