Help me pick an API design (OO vs functional)

[Dave Angel]

On 03/26/2013 08:04 AM, Michael Herrmann wrote:
> On Tuesday, March 26, 2013 11:26:30 AM UTC+1, Dave Angel wrote:
>> ...
>> Seems to me that the official interface should all be methods.  However,
>> you could have a new object which always represents the "focus" window.
>>    Then the USER could define trivial functions:
>>
>> def write(*args):
>>       focused.write(*args)
>
> It's an interesting idea. But why not give this write(...) to them in the first place?

Just to be clear, I was avoiding the problem of having two ways of 
accessing each function, since most of us prefer the methods, and you 
have some users who prefer simple functions.

> Am I the only one who appreciates the simplicity of
>
>          start("Notepad")
>          write("Hello World!")
>          press(CTRL + 's')
>          write("test.txt", into="File name")
>          click("Save")
>          press(ALT + F4)
>
> over
>
>          notepad = start("Notepad")
>          notepad.write("Hello World!")
>          notepad.press(CTRL + 's')
>          notepad.write("test.txt", into="File name")
>          notepad.click("Save")
>          notepad.press(ALT + F4)?
>
>> Somewhere in this thread you mention that save() creates a new window,
>> so a method-oriented approach would require that the user get that
>> window object, and call its methods rather than the original window's.
>> I say that's a very good thing, since the things you send may very well
>> have very different meanings to the save dialog than they do in the
>> original one.
>
> save() is not a function, but I assume you mean the action that opens the "Save" dialogue (I think that'd be `press(CTRL + 's')`). You are right that it's nice for it to be explicit. However, in 95% of cases, the window you want the next action to be performed in is the window that is currently active. I appreciate the explicitness, but to force it on the user for only 5% of cases seems a bit much.
>
>> Another concern I'd have is what happens if the user changes focus with
>> his mouse?  Does that change the meaning you had for focus() in the
>> above exchange?  Do you want your press() method to apply to a different
>> window when the user changes to that window?
>
> No. Internally, we remember which window is the currently active window. If you just run a script without user-intervention, this will be the respective foreground window. If some other window is in the foreground - which most typically happens when the user is interactively entering commands one after the other, so the foreground window is the console window, we do switch to the window that's supposed to be the active one. It may sound like black magic, but it works very well in practice, and really is not too ambiguous. When you read a script like
>
> 	start("Notepad")
> 	write("Hello World")
> 	press(CTRL + 's')
> 	write("test.txt", into="File name")
> 	click("Save")
> 	click("Close")
>
> I hold that you intuitively know what's going on, without even thinking about window switching.
>

Until the program you're scripting makes some minor change in its 
interface, or has something conditional on an attribute not intuitively 
obvious.

Also, it seems that in this thread, we are using "window" both to refer 
to a particular application instance (like Notepad1 and Notepad2), and 
to refer to windows within a single application.

Anyway, if you're only automating a few specific apps, you're not likely 
to run into the problems that methods were intended to address.  After 
all, Notepad's bugs haven't seemed to change for a couple of decades, so 
why should they fix anything now?

Having a selected window be an implied object for those global functions 
yields at least the same problems as any writable global. 
Multithreading, unexpected side effects from certain functions, 
callbacks, etc.

As long as you know the program is going to be simple, pile on the 
globals.  But as soon as it advances, each of them is a trap to fall into.

-- 
DaveA