Why NOT only one class per file?

[Steven Howe]

Now we're at the '_/How many Angels can dance on the head of a pin/_' 
question (like anything with wings would waste time dancing. Ever seen 
eagles mate (not the football players)? Dance it's not, but it looks 
like /sex on a roller coaster only better/! Get me a pair of wings!).  
Religious war over please! They get me long winded (as you'll note if 
you keep reading).  So, back to the original questions, now long forgotten.

The questions (there were three) were:
(1) Why does Java require each class be in a separate file?
(2) Why Python has no such rule?
And
(3) Is there a reason I should do one or the other (I assume that means 
either, (3)(a) one class per file, regardless of language and/or (3)(b) 
Java or Python).

-------------------------------------------------- <evangelist flag off> 
--------------------------------------------------
Answers:
Question (1):

    There appear to be four answers to this question.
    (a) Don't know (most answers, but with some religious dogma
    attached. JAVA bad; PYTHON good and I worship PHP. Move the adj.
    around  to suit your tastes).

    (b) KISS principle. /Keep It Simple, Stupid/. This is probably the
    right answer. Back then SUN, or as some of us remember '/Stanford
    University Network/' employed some sharp people (I must admit, my
    main reason for disliking SUN and CISCO was where they started. I
    was from UC Berkeley. It should have been UCBUN, or Uncle Buns; but
    that's just wouldn't sell. See how well BSD or 'bastard' sells).

    (c) Early Java development technology not up to n+1 classes in a
    single file. Reasonable from an old programmer's point of view.
    Those old IPC workstation didn't have that much memory. Small
    compiling jobs and executable loads would have been preferred if not
    required. I remember my first IPC had 4 Megabytes of RAM (boy did I
    have to beg for that box!) My Compaq 386/20 MHz computer, running
    MSDOS 3.1 only had 1 Meg and a Hercules graphics card (16 colors. I
    must have been good that year). I must have been a star, as most
    other's new hires were using '*/Bleeding Edge/*' computers (and if
    you don't know the reference, your just too young; think Gateway or
    Dell's cheap, hobbled products). File and more importantly, virus
    transfers where by /SneakerNet/. You young people have it too good;
    just one message via Exchange and you can infect a million computers
    in a thousand countries in moments. We had to work at it before we
    could take a day off as IT reloaded our computers. Thank God or Bill
    Gates, that companies keep buying a broken product.

    (d) Last. It was developed for vending machines (as someone pointed
    out, it started life as 'OAK'). Small memory foot print and a
    limited feature set were no brainers. '/We Taka the coins in, We
    dropa the Twinky out'. /The net's early domination by Unix variants
    and the Macintosh made Java's '/jack of all trades'/ a good
    solution. It was the main reason Microsoft tried (and failed) to
    '/Embrace and Extend'/ Java (Novell watch your ass; Microsoft wants
    to embrace and extend up your backside. SUN, just like a good
    Catholic girl said NO! (Or not in public! as the IBM/SCO trial seems
    to show)).

    So, pick an answers. It's God's fault/feature (sorry, I forget SUN
    != Microsoft), a programming dogma, hardware related or just old
    fashion growing pains. Probably some of each is the truth.


Question (2):

    Python is a later generation language then Java. Without a SUN,
    Digital or Microsoft to push it, it had to serve it's users better.
    Design limitations, due to hardware (see HP and Korn shell) weren't
    a consideration. The main issue I could see, when I was first
    introduced to the Python language, was the reduction of overhead and
    limited ways of doing the same task (1/ Perl ^ n in my experience).
    The need to prettify code so other could read it, or more
    importantly, so other's couldn't read it (for job security), wasn't
    there. Python really is easy to learn, like Pascal was suppose to be.

    Python, like Java was OO from the word go (ok gcc for you purists),
    but was not syntactically  a descendant of C++, so non-C++
    programmers didn't need to pay homage to AT&T (and God's only son,
    Bell Labs, from whence the Holy Ghost, Unix was created, destroyed
    and reborn as BSD. Is there a movie with Mell Gibson there?
    Remember, I said it first!).

    Freedom of vendors often means best of breed wins (i.e. most useful
    feature are includes). Freedom of vendors also means it hard to get
    into your shop (no one ever got fired for buying IBM after all).

That takes care of why, I hope. _No doubt_ there's a few opinions left 
to be expressed. Who knows, they might stay on topic as well or better 
them I.

Question (3):

    (3)(a) Is there a reason I should practice the 'One Class per File'
    rule?
    Answer is *yes,* when it makes your programming task easier and
    *no,* when it makes your programming task harder (And yes, I could
    be a damn good congressman too!).

    For development, I think the n+1 class is the right choice. It lets
    you start easy with a prototype class, one with little more then
    placeholders and then using inheritances, build up the functionality
    (you can see my Object Oriented Life started with C++, not a silver
    or ruby spoon. I still have the first edition of "**The C++
    Programming Language"** by Bjarne Stroustrup; an almost unreadable
    book (six or eight beers make it easier, if not clearer; after
    twelve you don't care). Don't ask to buy it. It's going into my
    casket when I'm creamated, along with the first edition of '*The C
    Programming Language*' by Kernighan and Ritchie and my second best
    porn collection; might be tight in that casket, but what a FIRE!).
    Using this method, program growth history is preserved. Some would
    say that's the job of version control. But you can see where sandbox
    development records got IBM and version controls blind usage in
    Mircosoft's attempt at (5+ years) Vista. Somethings should be
    forgotten, sooner rather than later.

    For a developed, deployable product and JIT compilers, n+1 classes
    with dead overridden inheritances, are wasted cycles, wasted space
    and wasted download bandwidth. It just doesn't make sense. /Clean em
    up, move'em out/. That's what version control is for.

    (3)(b) Python or Java. Emmm, Dumb question (some question are,
    despite the feel good gurus your boss will bring in when he wants to
    cut your salary, double your workload or both while cutting you
    coffee rations). The answer depends on your boss's preference. Learn
    both and hope you can convience him the one you're best at, is the
    right choice (good luck; boss's are generally a generation or two
    behind and you. After all, you where hired because of your fresh
    knowledge and viewpoint.  We don't want that going to another
    company. When you feel this is situation is all wrong, read the
    novel Catch-22 and join th club). And please don't remind him that
    you'll be there to support the language he doesn't know. That's a
    ticket backwards and a new resume (yours).

-------------------------------------------------- <evangelist flag on> 
--------------------------------------------------

Now for some fun. I have a wicked (so I'm told) and rude sense of humor. 
Humor me, or you, if you please ...

You'll notice I didn't evangelize or denigrate Python, Jython, Java, PHP 
or C++ (/OK, C++ just a little; after all, I am a fallen CatholiC++/. 
/And a few jabs at Microsoft. The devil should always be mentioned, 
especially when he's hard to avoid/).
So now here's the the motto or jingle of the dying and upstart languages 
languages:

    Perl: "Badges? We don't need any stinky badges!"
    FORTRAN: "GOTO 40"
    and
    FORTRAN-90: "GOTO 40-ish, please!"
    Basic: "Directory? What's a directory?"
    <shudder>Pascal</shudder> (need I say more?)
    and
    COBOL on or off Ng: "Your in the wrong column, again!"
     

And the upstarts language mottos:

    Ruby: I don't care if the slippers are suppose to be sliver; I'm
    paying for Technicolor dammit; those slippers will be RUBY!
    C-Sharp: Bitter on the tongue and leaves a bad after taste. Could I
    have a Java light instead?
    or C-Sharp's first cousin by bastardy with open source virgins (in
    time they'll realize that pains in their behinds should have been
    expected) ...
    Mono: much like the disease, ready to infect anything it touches.
    You should avoid it as fast as you can run.
    And ... Not to forget the forgetable ...
    PHP or for neophytes Perl Hypertext Protocol, also referred to as
    '2nd Wind' or 'Last Gasp' can't be bad for you!

Did I miss anything? No? Then I have no /Smalltalk/ left, so you should 
go /Forth/ and program. But remember JAVA & SCRIPT can grow infinitely, 
especially when taken to the exp( GOOGLE ) plexed.

sph

--------------------------------------
       P.S. Python RULES!
---------------------------------------
      P.S.S. Still waiting for GWT via Python Google; I hate stepping 
backwards; can't tell what I'm stepping in, but
     GWT feels like dog poop; warm amd squishy but it stinks. Mom tells 
you to stay outside and clean your    
     shoes. Flies think your sweet.
---------------------------------------

Carl Banks wrote:
> On Apr 4, 5:23 pm, "Chris Lasher" <chris.las... at gmail.com> wrote:
>   
>> A friend of mine with a programming background in Java and Perl places
>> each class in its own separate file in . I informed him that keeping
>> all related classes together in a single file is more in the Python
>> idiom than one file per class. He asked why, and frankly, his valid
>> question has me flummoxed.
>>     
>
> A: Because you don't have to.
>
> Less smart aleck: Python allows programmers to put more than one class
> per file.  Given that freedom, most people didn't obey one-to-one
> correspondence between classes and files.  Therefore, it's the more
> common idiom in Python.
>
>
>   
>> I tried to rationalize this Python idiom by claiming a file--a single
>> module--makes for a great container of code which is logically tied
>> together, such as a class and its subclasses. He posited that
>> directories (packages) can tie the files together just as well,
>>     
>
> Which is not incorrect.
>
>
>   
>> and by
>> having the classes as separate files, he can "diff" them to see how
>> they differ, something he wouldn't be able to do with the code all in
>> one file.
>>     
>
> I agree with Bruno: feeling the need to do this is a big red flag that
> the code is way too cut-and-paste.
>
> (diff'ing different versions is useful, of course, but you can
> usefully diff modules with many classes in them.)
>
>
>   
>> I also offered that having related classes under one file gives more
>> direct access to those classes, e.g.:
>>     
>
> [snip examples]
>
>   
>> He doesn't find my arguments convincing, so I thought I'd ask here to
>> see why the Python idiom is the way it is: why should we NOT be
>> placing classes in their own separate files?
>>     
>
> There's no overwhelming reason not to, IMO.  As long you have some
> organization, be it with packages or modules, everything's ok.  Most
> things you have to gain or lose by doing one way or the other are of
> minor importance.
>
>
> Carl Banks
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20070405/451b87f3/attachment.html>