Lex Spoon wrote:
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.
Hmm, I somehow don't see how is it impossible when it is happening right now, see subclasses of FileDirectory. Downside I see is that it makes image rather bigger, having code inside which will never be used while running on same platform.
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.
I can't imagine an example of such situation. Maybe I don't exactly get what is "standard" image and what is "perfectly valid" VM.
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.
I can imagine a scenario of having auxiliary small image with platform specific containment. I don't know if such thing would be possible. It brings out a lot of questions as well.
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.
In this specific case it tells you why connection was not successful. But reason reported (connection timed out) is somewhat different from reality (connection refused). But of course if purity of image should be touched by this I also prefer not involve platform-specific code into the image. I guess I'll better do like I don't see class PowerManagement and classes alike inside.
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.
No need. I freely resign to solution that my application just reports "there was a network error". It just leaves me in little sadness that my java, c# and other friends are more matured in this way. Sorry for disturbing.