functionality of Socket>>socketError

Lex Spoon lex at cc.gatech.edu
Thu Sep 2 17:29:19 UTC 2004


If I may flame in general for a moment, I really dislike
platform-specific codes creaping up into the image at all.  I agree that
many things are nice to write in Smalltalk instead of C, but presently,
we have no good way to do that for platform-specific code.  Our best
effort is to include in every image the platform-specific code for every
platform the image might ever run on.  This is impossible in general,
though, because Squeak runs on ever more platforms as time goes by.  I
find it a very sad thought that someone could have a perfectly valid VM
and yet not be able to run standard Squeak images.

There are solutions to this general problem that aren't too hard.  For
example, we could have a global variable Platform that is initialized by
a file-in that the VM supplies.  We could even work out a caching scheme
so that if an image is loaded on the same platform twice, it does not
reload the Platform variable.  But at any rate, we do not have such an
ability right now, and so I think it is a bad idea to have
platform-specific stuff at the image level.

On the specific problem, I think that any error-returning method should
have platform-independent codes.  And actually, we already have a
platform-independent way to report the errors for class Socket: the
method statusString is already sufficient.  The only thing it doesn't do
is tell you *why* a failure happened, but I don't think that is
sufficient reason to introduce non-portability.

Thus, I say we should axe this method, or at least rename it to
something long and obnoxious like
#reallyUnportableErrorCodePleaseDoNotInvokeThisMethod.  Then people who
want the method for debugging can use it, but most code will take the
hint and use the portable API.


-Lex



More information about the Squeak-dev mailing list