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
