One class per file?

[Aaron "Castironpi" Brady]

On Oct 3, 1:51 pm, Bruno Desthuilliers
<bdesth.quelquech... at free.quelquepart.fr> wrote:
> greg a écrit :
>
> > Bruno Desthuilliers wrote:
>
> >> OTHO, 'one class per file' is a standard idiom in Java and IIRC in C++
> >> (which both have namespaces one way or another)
>
> > In Java you don't get a choice, because the compiler
> > assumes a class can be found in the correspondingly
> > named file.
>
> For public classes only.
>
>
>
> > While C++ has namespaces, they don't have any defined
> > relationship to source files, so they don't help you
> > find which file something is defined in.
>
> Nope. But IIRC, one-class-per-file helps saving on compile/link time. A
> problem we don't have with dynamic languages !-)

I think that one goes in the 'handcuffs' category.  You are free to
adopt the idiom if you want, aren't required to.  (Though doesn't the
freedom handcuff later users of your code?)

Besides, it's not always clear what method in an inheritance tree is
getting called, so 'one class per file' doesn't guarantee you can find
an operation.

With 'exec( "class %s:\n..." )' statements and 'def f(): / class X: /
return X' statements, you don't even know all your classes at
startup.  And not to mention 'namedtuple's certainly make the idiom
impractical in at least corner cases.

(But, when you need code and can't find discipline, maybe 'inside-the-
box' restrictions can bring your goal closer, no?)