Joseph Pelrine jpelrine@acm.org wrote:
You're right, modularity is not everything, but it's a big step in the right direction. If you want to check out some good reference sources, start out by reading
[snip yummy references]
More recent work can be found in Gamma et al.'s Paper on TeamStreams, presented at XP 2000 (I'm not sure whether there's a web link to it),
I think this is it - http://www.xp2001.org/papers/Chapter9-Lippert+alii.pdf
Most of the work I'm doing for Stable Squeak is involved in implementing these and other ideas aimed at managing modularity in Squeak. I'm on a roll now, and may be able to show something next week.
Ok, fine, we're *already* salivating. Why are you wasting time answering silly emails? go code! ;-)
On the other hand, code quality can't be learned from a book. I benefited a lot from having had access to world-class Smalltalkers who would whack me upside the head if my code was crappy. It became a matter of pride for me to write clean code. If you're alone, SUnit and full-strength SmallLint help a lot.
I miss having the RB and friends. One thing I missed in those was something telling me my code is too complex - enter the HintingBrowser. Someday soon I hope to have all those together on one image with Celeste...
Cheers Joseph
Daniel
At 18:05 02.06.2001 , danielv@netvision.net.il wrote:
Joseph Pelrine jpelrine@acm.org wrote:
You're right, modularity is not everything, but it's a big step in the right direction. If you want to check out some good reference sources, start out by reading
[snip yummy references]
More recent work can be found in Gamma et al.'s Paper on TeamStreams, presented at XP 2000 (I'm not sure whether there's a web link to it),
I think this is it - http://www.xp2001.org/papers/Chapter9-Lippert+alii.pdf
Definitely not that paper! I don't know what those guys think they're doing, but it ain't XP. However, they have a reference to Gamma et al.'s paper in there.
An easy intro (which I - in my modesty - forgot before) is my talk on "Modularizing Smalltalk", presented at the ESUG conference in '97. You can find it at http://www.daedalos.com/~j_pelrine/ under "Lectures".
Most of the work I'm doing for Stable Squeak is involved in implementing these and other ideas aimed at managing modularity in Squeak. I'm on a
roll
now, and may be able to show something next week.
Ok, fine, we're *already* salivating. Why are you wasting time answering silly emails? go code! ;-)
I actually have a rich and enjoyable life, with a beautiful girlfriend, 3 cats, 2 jazz bands in which I play, etc. I code for a living, so I really don't look forward to spending every evening sitting at the computer hacking. Unfortunately, the day only has ca. 24 hours, so I can only Squeak when I have time. I recommend a rounded, complete life to all of you ;-)
On the other hand, code quality can't be learned from a book. I
benefited a
lot from having had access to world-class Smalltalkers who would whack me upside the head if my code was crappy. It became a matter of pride for me to write clean code. If you're alone, SUnit and full-strength SmallLint help a lot.
I miss having the RB and friends. One thing I missed in those was something telling me my code is too complex - enter the HintingBrowser. Someday soon I hope to have all those together on one image with Celeste...
Huh? I use the RB all the time for my Squeak work. I even call it from SUnit to wrap quality control tests in my work. Contact Bob Hartwig - he did the port, and is doing the StSq version too.
-- - Joseph Pelrine [ | ] Daedalos Consulting Email: jpelrine@acm.org Web: www.daedalos.com/~j_pelrine
Smalltalk - scene and not herd!
An easy intro (which I - in my modesty - forgot before) is my talk on "Modularizing Smalltalk", presented at the ESUG conference in '97. You can find it at http://www.daedalos.com/~j_pelrine/ under "Lectures".
Joseph,
I read your module presentation. It looks like one of the most straighforward explanations of these ideas that I've seen so far...it would be neat if it were done as Squeak project where the concepts could be readily demonstrated alongside the text...but I'm babbling now.
It would be nice to support the co-existence of two versions of a module in an image simultaneously. Is that part of the plan for StSq?
One other thing that would be great (but which presents even more challenges), would be to allow a module to override the behavior of an existing class, but have the previous behavior in effect for all modules except those that import the module with the new behavior.
Here's an example: Suppose I needed a collection to generate a notification when things are added. In my module, I modify #add: to trigger an event. Now, when I use the collection in my module, calling #add: triggers the notification. However, the other code in the system (which doesn't import my module), when calling #add:, gets the original behavior of that method (no event is triggered).
I realize that this would require deep modification of the message lookup mechanism, and how method dictionaries are organized...but, I wonder if any work has been done in this area.
- Stephen
At 22:40 02.06.2001 , Stephen Pair wrote:
An easy intro (which I - in my modesty - forgot before) is my talk on "Modularizing Smalltalk", presented at the ESUG conference in '97. You can find it at http://www.daedalos.com/~j_pelrine/ under "Lectures".
Joseph,
I read your module presentation. It looks like one of the most straighforward explanations of these ideas that I've seen so far...it would be neat if it were done as Squeak project where the concepts could be readily demonstrated alongside the text...but I'm babbling now.
Hey, thanks for the compliment <grin>. I tend to refrain from posting and writing because I realize how little I actually know (and how irrelevant most of it is). Also, I find that actions (code) speak louder than words. I'm happy that some of my musings are helpful to someone, though.
If someone wanted to put this into a Squeak project, I'd be happy to help - I just don't have the time myself. It could use some updating, too. I've learned a bit more since I wrote that presentation.
It would be nice to support the co-existence of two versions of a module in an image simultaneously. Is that part of the plan for StSq?
Hmmm. I know I *can* do it, I know *how* to do it (one possible way), but it hasn't been on the requirements list. I also wish I had more time to write code, or someone who would pay me for doing it (no, I'm not begging for a job - just musing again).
One other thing that would be great (but which presents even more challenges), would be to allow a module to override the behavior of an existing class, but have the previous behavior in effect for all modules except those that import the module with the new behavior.
Here's an example: Suppose I needed a collection to generate a notification when things are added. In my module, I modify #add: to trigger an event. Now, when I use the collection in my module, calling #add: triggers the notification. However, the other code in the system (which doesn't import my module), when calling #add:, gets the original behavior of that method (no event is triggered).
I realize that this would require deep modification of the message lookup mechanism, and how method dictionaries are organized...but, I wonder if any work has been done in this area.
I have some ideas about that (see above). The one guy who's been there and done that many times over is Dave Simmons.
-- - Joseph Pelrine [ | ] Daedalos Consulting Email: jpelrine@acm.org Web: www.daedalos.com/~j_pelrine
Smalltalk - scene and not herd!
This is just a personal note to let you all know that I am still around and very interested in the Squeak Foundation. Unfortunately, my attention these days is absorbed with a job search, as Wireless Knowledge, Inc. just dropped 30% of its workforce, including me. Sigh.
John Tobler squeaker@diganet.com grepninja@diganet.com johntobler@earthlink.net
squeakfoundation@lists.squeakfoundation.org
-
danielv＠netvision.net.il -
John Tobler -
Joseph Pelrine -
Stephen Pair