object.enable() anti-pattern

[Chris Angelico]

On Fri, May 10, 2013 at 1:19 PM, Mark Janssen <dreamingforward at gmail.com> wrote:
>> I think where things went pear shaped is when you made the statement:
>>
>>>> There is no sensible use-case for creating a file OBJECT unless it
>>>> initially wraps an open file pointer.
>>
>> That's a pretty absolute point of view.  Life is rarely so absolute.
>
> In the old days, it was useful to have fine-grained control over the
> file object because you didn't know where it might fail, and the OS
> didn't necessarily give you give good status codes.  So being able to
> step through the entire process was the job of the progammers.

I don't know what you mean by the "old days", but a couple of decades
ago, there were no such things as "file objects". You call a function
to open a file, you get back a number. You explicitly close that by
calling another function and passing it that number. In fact, there is
no way to have a "file object" that doesn't have an open file
associated with it, because it's simply... a number.

> Now, with languages so high like python and hardware so common, it
> almost is never necessary, so he has some point.   A closed file
> pointer is useful from a OS-progamming point-of-view though because
> you generally never want to leave files open where they'd block other
> I/O.

I'm beginning to wonder if you and Dihedral are swapping notes.
Dihedral's been sounding fairly coherent lately.

ChrisA