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...@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 > >
