object.enable() anti-pattern

[Wayne Werner]

On Mon, 13 May 2013, Greg Ewing wrote:

> Wayne Werner wrote:
>> On Fri, 10 May 2013, Gregory Ewing wrote:
>>
>>>   f = open("myfile.dat")
>>>   f.close()
>>>   data = f.read()
>> 
>> To clarify - you don't want a class that has functions that need to be 
>> called in a certain order with *valid input* in order to not crash.
>> 
>> Exactly what does happen - a ValueError is raised because you're(*) passing 
>> self into the file.read() function, and that input is invalid
>
> The same argument can be applied to:
>
>   foo = Foo()
>   foo.do_something()
>   foo.enable() # should have done this first
>
> You're passing an invalid input to Foo.do_something,
> namely a Foo that hasn't been enabled yet.

That is the crux of the argument - as designer of the class *you* need to 
ensure that when your constructor is done, your class is in a stable 
state. And that every other state transition (with valid input) results in 
your class then being in a stable state.


If anything, the stronger argument is that `file.close()` is not a well 
designed function because it leaves your object in an unstable state.

Which I would be inclined to agree with, but I couldn't give you the 
answer for what makes it better. Because the answer is the best one you 
can get in computer science: It depends.


The reason that it depends, is because it depends on what you want to do. 
Do you want a program that seems purely functional? Do you want a program 
that's easy to maintain? Do you want a program that more accurately models 
the "real world"?

Personally, I think the file object API in Python is about as good as it 
can get - but that's because it's working with "physical" things (i.e. 
files - bits on a platter, or flash/SSD drive...) which necessarily have a 
temporal nature. And it's much less badness to blow up on a call to `read` 
than it is to remove the `read` function and die with a NameError when the 
underlying file is in a closed state.


At least in my opinion ;)
-W