Hi,

yampa at mindspring.com wrote:
> 
> On Wed, 28 Aug 2002 09:30:30 -0500 (Central Daylight Time) Aaron
> <reic0024 at d.umn.edu> wrote:
> 
> > On Wed, 28 Aug 2002, Karl Ramberg wrote:
> >
> > > I think private methods usually are in the
> > private category, and not
> > > necessary
> > > have a selector name indicating it's private.
> >
> [...]
> 
> > After the original message was posted, I tried
> > it out, created a
> > class-side method on a class, #pvtInspectMe,
> > which simply does a ^ 'hello'
> > inspect.  I then tried calling it in a
> > workspace with Object pvtInspectMe,
> > and Squeak told me that it was private, with a
> > compilation error. That is,
> > it expanded to something like Object *Private
> > methods cannot be called
> > like this.* pvtInspectMe.
> >
> > Aaron
> >
> >
> >
> The compilation error comes from MessageNode >> pvtCheckForPvtSelector:
> encoder,  which checks for the 'pvt' at the beginning of the method.  This is
> what I was asking, that given a clean slate, should code be written to take
> advantage of having private methods like this.
> 
> But while I didn't give method categories as an option in the first question,
> Karl is right that this is the way it is done most of the time.  But it is
> kind of a "soft" private, as opposed to a "hard" private that gives an error.
> 
> So, if people prefer categories labeled private to actual private methods, you
> can state that too.
The reason for preferring soft private over hard private methods lies often in the point stated by Richard in one of his latest posts:
_You_cannot_use_hard_private_methods_as_initializers_
That is, the most common usage of them is hindered by the fact that 
"self new pvtInitialize" is not a self send. If this was not the case i would be using hard private methods all the time. I even considered enforcing private use of private mehtods at runtime (at practically no cost).
If someone can help me overcome this limitation i will adopt hard private methods instantly.

Just my two cents