Path: utzoo!mnetor!uunet!husc6!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!rochester!PT.CS.CMU.EDU!IUS3.IUS.CS.CMU.EDU!ralphw
From: ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre)
Newsgroups: comp.lang.smalltalk
Subject: Re: embeddedCapitals
Message-ID: <1229@PT.CS.CMU.EDU>
Date: 25 Mar 88 21:15:59 GMT
References: <2472@pdn.UUCP> <12100008@osiris.cso.uiuc.edu>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 31

In article <12100008@osiris.cso.uiuc.edu> goldfain@osiris.cso.uiuc.edu writes:
>
>Now that I've thought about it for a bit, I think there is no solution to the
>embedded-capitals-causes-naming-errors problem.  Anything you do to improve
>readability will cause possible name-matching  errors, whether you separate
>parts of long names with spaces, underscores, capitals, etc.
This is exactly why the name separator stuff might best be handled by a
programming environment, not the compiler/interpreter itself.  A potential
drawback is that you might end up limiting
For example, if uppercase is 'reserved' bu the programming environment
as a possible 'long-word-separator' attribute, then you may lose the ability
to use uppercase in program symbols. [but maybe these should be represented
internally by something other than character strings anyway, like a tagged 
number (so that the intepreter/compiler doesn't have to do parsing in addition
to its other duties.]

Ideally, the user preference could be whatever they're most comfortable with,
so a symbol displays as AVeryLongWord to users who prefer that style, or 
a_very_long_word, or just averylongword for those with a lot of patience.

Comments?
--
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
-- 
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA