Byte arrays are not host specific.�� True.
But integers are not byte arrays.�� They don't even contain byte arrays.
Just like (boxed) Floats are not word arrays and don't contain word arrays.

For what it's worth, I find that it's quite unusual for a method to
change from private to public or vice versa.

The basic problem with putting methods in a "private" category is
that it has no actual effect.�� It was Smalltalk that taught me OO and
the importance of encapsulation.�� But Smalltalk doesn't actually
support encapsulation.�� Every detail of the implementation of
Dictionary, for example, is exposed.�� And the practice of
"self-encapsulation" is actually ANTI-encapsulation for this reason.

Now there are several ways to implement hashed collections.
The one I've had for years is pleasantly fast and pleasantly
free of weird restrictions (keys/elements can be nil and why
not).�� I've got a new one I'm working on that uses less space
and is faster still.�� Because my dialect *enforces* encapsulation,
when my testing is complete, I'll be able to swap the new
version in, knowing that no external code can possibly depend on
the implementation details.obj

As a particular example, it was only when I implemented
serialisation (nowhere up to Fuel's standards, of course) that
I implemented #pvtInstVarAt:[put:] and an object is *still*
completely and exclusively in charge of its own instance
variables.

I agree that using a prefix is not the best way to do this,
but the eye soon learns to skip over it.�� It's not that much
worse than "Inst" or "Var" or the pervasive and obtrusive
use of prefixes on selectors in VisualAge Smalltalk.�� I think
Pharo would be the better for having *some* way to enforce
encapsulation, but what the best way is I don't claim to know.

On Wed, 13 Mar 2019 at 21:35, K K Subbu <kksubbu.ml@gmail.com> wrote:
On 13/03/19 12:45 PM, Richard O'Keefe wrote:
> Base 256: that's an implementation detail.
> Little-endian: that's an implementation detail.

Architecture-specific no. Implementation yes. But that should be fine
for private methods.

> My Smalltalk uses base 65536 native-endian and
> takes some care not to let Smalltalk code find out.
> (Not least because on 64-bit machines I want to
> use base 2**32.)

This would make it host-specific. Byte arrays are not host-specific.

> For *private* methods, depending on otherwise
> hidden implementation details is fair enough.
> My Smalltalk picked up a convention from Squeak
> -- or rather, from the Squeak mailing list --
> that a 'pvt' prefix on a selector makes it truly
> private and *enforces* that.�� Pharo does not seem

pvt prefix is possibly inspired by Hungarian notation. I find that it
impairs readability and maintenance. Should a method change from private
to public or vice versa down the line, maintenance will be a nightmare.
My own preference is placing them in 'private' category (or even
private-* categories).

> to have anything similar, and #at: is the epitome
> of a selector in extremely wide general use.
> Since #digitAt: exists -- and is what the integer
> classes use -- it is practically certain that #at:
> is sent to an integer only by mistake.

You make a good point here. Perhaps #at:/#at:put: should throw an error
for all numbers and private methods could use basic versions instead.

Regards .. Subbu