object.enable() anti-pattern

[Steven D'Aprano]

On Thu, 09 May 2013 02:38:36 +0000, Dan Sommers wrote:

> Think of spinning off a thread:  initialize it synchronously, and then
> let it execute asynchronously.  We tend towards that pattern even when
> we know that execution will be synchronous, because we also that it
> could be asynchronous one day.

Whether it is synchronous or asynchronous is irrelevant.

I can see use-cases for separating "make it go" from initialisation. It 
all depends on what you might want to do to the object before making it 
go. If the answer is "Nothing", then there is no reason not to have the 
constructor make it go. If the answer is, "Well, sometimes we need to do 
things to the object before making it go", then it makes sense to 
separate the two:

blob = MyBlob(arg1, arg2, agr3)
blob.poke("with a stick")
blob.append(data)
blob.foo = "spam"
blob.make_it_go()


I'm not talking about this case. I'm talking about the case where there's 
nothing you can do with the blob before making it go.


> Yes, we could wrap that up in a neat
> bundle, but explicit is better than implicit.

"And that is why we always write code like this:

n = int(int(len(something)) + int(1))

just to be sure that the result is explicitly an int and not just 
implicitly an int. Suppose some Javascript programmer was reading the 
code, and they thought that 1 was a floating point value. That would be 
bad!"


-- 
Steven