Hi all!
A few thoughts (after going through this list after my vacation):
1. Go, go, Squeakers! The activity on the list seems to be growing and more names pop up by the day. Very nice!
2. A few things that really NEED to be done in Squeak ASAP IMHO: Exception handling and good networking code · la Correspondents. There is a fast growing amount of code out there and these things really are essential for most of the work in Squeak. Exceptions because everyone needs them and networking code because many of the projects that can use Squeak today depend on it.
3. Before throwing in Namespaces i Squeak though... Is it only me that feels that they really "get in the way" when programming Java? Import this and import that, oops, old imports laying about... Gah!
Of course namespaces are cool. And useful. But they also break the "modelessness" that Smalltalk has. You can always hack a oneliner in any of Smalltalks textareas (inspectors, debuggers, browsers, workspaces etc.) and just doit. The only context you have to think about is your "current obect" which is natural. But in Java I always have to qualify myself to death and it is truly annoying.
I glanced through Allan's PDF-document but I did not see any reference to how he thinks namespaces will affect our lovingly productive and effective Smalltalk environment and how we work with our code/objects, anyone have any thoughts? Allan?
4. XML is very nice. I work with it in Java and we are using it right now both as a more robust way of representing objects in files than serialization. If you do it right and couple XML with some nice "builder" objects you can isolate your testdata better from the evolving class schemas.
Another perfect fit for XML is representing UIs as Mozilla are doing in their Xul stuff. VWs windowsSpecs together with builder objects were in retrospect "the right way to go". :-) I hate UI code generation and I do not really believe in UI serialization as Sun seems to do. And hacking the UIs by hand is tedious and results in code bloat. Go XML.
But serialization of objects between languages is hard. HARD on the brink of impossibility I would presume. OMG/CORBA are trying aren't they? I say good luck. :-)
If you want more inspiration on the subject of moving objects, take a good long look at Voyager from ObjectSpace. Truly cool technology. RMI deluxe with mobile agents on top. Something like that would really be cool in Squeak. I have not looked at the fly-by-wire stuff, is it something like Voyager?
And finally how truly wonderful it would be to have some XML package in Squeak. :-)
regards, Gran
=== Gran Hultgren, gohu@rocketmail.com, icq#:6136722 GSM: +46 709 472152, http://195.22.65.4 "First they ignore you. Then they laugh at you. Then they fight you. Then you win." -- Gandhi _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
"Göran Hultgren" wrote:
- Before throwing in Namespaces i Squeak though... Is it only me that
feels that they really "get in the way" when programming Java? Import this and import that, oops, old imports laying about... Gah!
Of course namespaces are cool. And useful. But they also break the "modelessness" that Smalltalk has. You can always hack a oneliner in any of Smalltalks textareas (inspectors, debuggers, browsers, workspaces etc.) and just doit. The only context you have to think about is your "current obect" which is natural. But in Java I always have to qualify myself to death and it is truly annoying.
I glanced through Allan's PDF-document but I did not see any reference to how he thinks namespaces will affect our lovingly productive and effective Smalltalk environment and how we work with our code/objects, anyone have any thoughts? Allan?
I have the same reservations about most of the namespace proposals I have seen introduced here in the Squeak list. Prefixing classes with a (hopefully) unique identifier to prevent collisions is ugly, but I would take that over the need to qualify everywhere. Unfortunately, I cannot claim any great insight into what would be the Right Thing (tm) for Smalltalk.
Perhaps some inspiration could be drawn from the "packages" defined for CommonLisp. For the most part, they are reasonably unobtrusive in use and solve essentially the same problem for a dynamic language of similar scale and system complexity as Smalltalk.
-- Dwight
squeak-dev@lists.squeakfoundation.org