From: David Douthitt Date: 2002-09-03T23:24:59+09:00 Subject: Re: Ruby aesthetics This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. ----=_NextPart_ST_09_24_55_Tuesday_September_03_2002_29855 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable You said: I like the LISP convention of everything lowercase and hyphenated. Well, I though LISP convention was all UPPER-CASE and hyphenated. Modern L= ISPs probably ignore case (right?). These naming conventions are interesting: FORTH, COBOL, LISP all use upperc= ase and hyphens; Smalltalk used mixed case; others have used the underscore= =2E David Douthitt CUNA & Affiliates UNIX Systems Administrator ddouthitt@cuna.coop >>> mgushee@havenrock.com 9/1/02 5:32AM >>> On Sun, Sep 01, 2002 at 06:53:40PM +0900, Luc Heinrich wrote: > On dimanche, sep 1, 2002, at 03:12 Europe/Paris, Gavin Sinclair wrote: >=20 > >- indentation-as-syntax > >- explicit "self" parameter to methods >=20 > May I add: >=20 > - lots of useless '_' everywhere... I beg to differ. The underscores in Python are far from useless: _foo() is a (pseudo-) protected method* __bar() is a (pseudo-) private method* __foobar__() is a voodoo method (unless it's __init__ or __del__) class_ lets you use self-explanatory names without conflict with reserved words Now if you called them ugly, I'd be the first to agree with that. Personally I think the underscore character should be eradicated from the face of the earth. Call me weird, but I like the LISP convention of everything lowercase and hyphenated. =20 * Python deliberately lacks true access control, the idea being that "we're all adults here." So 'protected' just means the name doesn't get exported, but you can still access it in qualified form; 'private' means the name gets mangled so that you would have to=20 write some really ugly code to get at it. --=20 Matt Gushee Englewood, Colorado, USA mgushee@havenrock.com http://www.havenrock.com/ ----=_NextPart_ST_09_24_55_Tuesday_September_03_2002_29855 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

You said:

I like the LISP convention of
everyth= ing=20 lowercase and hyphenated.

Well, I though LISP convention was all U= PPER-CASE=20 and hyphenated. Modern LISPs probably ignore case (right?).

These naming conventions are interesting= : FORTH,=20 COBOL, LISP all use uppercase and hyphens; Smalltalk used mixed case; other= s=20 have used the underscore.

David Douthitt
CUNA & Affiliates<= BR>UNIX=20 Systems Administrator
ddouthitt@cuna.coop

>>> mgushee@havenrock.com 9/1/0= 2 5:32AM=20 >>>
On Sun, Sep 01, 2002 at 06:53:40PM +0900, Luc Heinrich=20 wrote:
> On dimanche, sep 1, 2002, at 03:12 Europe/Paris, Gavin Sincl= air=20 wrote:
>
> >- indentation-as-syntax
> >- explicit "self" parameter to methods
>
> May I add:
>
> - = lots=20 of useless '_' everywhere...

I beg to differ. The underscores in Pyt= hon=20 are far from useless:

=20 _foo()        is a (pseudo-) protected method*
__bar()       is a (pseudo-= )=20 private method*
__foobar__() is a voodoo method (unless it'= s=20 __init__ or __del__)
class_      &n= bsp;=20 lets you use self-explanatory names without=20 conflict
          &nb= sp;      =20 with reserved words

Now if you called them ugly, I'd be the first to= =20 agree with that.
Personally I think the underscore character should be eradicated from
the face of the earth. Call me weird, but I like the LIS= P=20 convention of
everything lowercase and hyphenated.

* Pytho= n=20 deliberately lacks true access control, the idea being that
  = =20 "we're all adults here." So 'protected' just means the name=20 doesn't
   get exported, but you can still access it in qualif= ied=20 form;
   'private' means the name gets mangled so that you wou= ld=20 have to
   write some really ugly code to get at it.

-= -=20
Matt Gushee
Englewood, Colorado,=20 USA
mgushee@havenrock.com
http://www.havenrock.com/

----=_NextPart_ST_09_24_55_Tuesday_September_03_2002_29855--