(forgot to copy the list)
Classes are certainly well known, but not the only way to get a well known object.
My pragmatic issue with using class side methods for Singletons is that it is a bunch of work to refactor the class side behavior to instance side later. Look at the original PWS server for a squeak specific example.
My design issue is that classes are for making instances (technically for defining behavior of instances). Making them the building block of the program means that I'm giving them extra responsibility. I like to keep the responsibility list as small as possible.
(Someone walked off with my Design Patterns Smalltalk Companion, which wrote about these issues better than I can.)
On Tue, Mar 25, 2008 at 2:51 PM, Ramon Leon ramon.leon@allresnet.com wrote:
I'm guessing you like that the class methods can be invoked easily from the class name. What you want is a well known object.
Like a class?
I wouldn't use a class object just to create a well known object. I'd probably start with a Singleton and work from there.
Like a class? Classes are singletons, what do you have against using them as such?
Ramon Leon http://onsmalltalk.com
(forgot to copy the list)
Classes are certainly well known, but not the only way to get a well known object.
My pragmatic issue with using class side methods for Singletons is that it is a bunch of work to refactor the class side behavior to instance side later. Look at the original PWS server for a squeak specific example.
Maybe it used to be, but it's a simple refactoring at the moment, refactor method >> move to instance side. Secondly, I'll worry about later... later, i.e. YAGNI, classes are nice singletons and it seems like useless work to manually implement a singleton when singleton is a built in feature.
My design issue is that classes are for making instances (technically for defining behavior of instances). Making them the building block of the program means that I'm giving them extra responsibility. I like to keep the responsibility list as small as possible.
Classes are objects too, just because most classes build instances doesn't mean they all have to. You might not want a class doing both, but I see no reason it can't do one *or* the other. Serving as a singleton works well when it's needed and keeps code simple. Saying a class should only create instances seems a rather arbitrary restriction to place upon your designs.
(Someone walked off with my Design Patterns Smalltalk Companion, which wrote about these issues better than I can.)
I'd love to see the arguments if you do recall them because so far, I just don't agree.
Ramon Leon http://onsmalltalk.com
On Tue, Mar 25, 2008 at 5:44 PM, Ramon Leon ramon.leon@allresnet.com wrote:
Classes are objects too, just because most classes build instances doesn't mean they all have to. You might not want a class doing both, but I see no reason it can't do one *or* the other. Serving as a singleton works well when it's needed and keeps code simple. Saying a class should only create instances seems a rather arbitrary restriction to place upon your designs.
As a beginner who is finally starting to do some useful [Smalltalk] work in a Healthcare organization, I am finding this conversation very interesting because I write a lot of "utility" code...mostly data "pre-processing" before it goes to the Warehouse, the Reporting engine, or to files to go out the door for required reporting to other organizations.
Should I consider something more than just "XXFileProcessor file: aFile" if it will only ever run on one file that shows up in a directory once a day and the whole point is that there is only ONE processor?
Just interested, because in such "utility" cases I end up with all my helper methods on the class side and wonder to myself, "is this wrong?" because it feels very similar to writing subroutines in any other language...
On that note, isn't that sort of all traits really are? A subroutine not attached to any particular object? But with no access to object data short of resorting to things like self classPool at: #Var, which I suppose defeats the point, but darn it, I keep running into situations where multiple inheritence would be great!
Rob Rothwell
On Tue, Mar 25, 2008 at 07:13:27PM -0400, Rob Rothwell wrote:
On Tue, Mar 25, 2008 at 5:44 PM, Ramon Leon ramon.leon@allresnet.com wrote:
Classes are objects too, just because most classes build instances doesn't mean they all have to. You might not want a class doing both, but I see no reason it can't do one *or* the other. Serving as a singleton works well when it's needed and keeps code simple. Saying a class should only create instances seems a rather arbitrary restriction to place upon your designs.As a beginner who is finally starting to do some useful [Smalltalk] work in a Healthcare organization, I am finding this conversation very interesting because I write a lot of "utility" code...mostly data "pre-processing" before it goes to the Warehouse, the Reporting engine, or to files to go out the door for required reporting to other organizations.
Should I consider something more than just "XXFileProcessor file: aFile" if it will only ever run on one file that shows up in a directory once a day and the whole point is that there is only ONE processor? Just interested, because in such "utility" cases I end up with all my helper methods on the class side and wonder to myself, "is this wrong?" because it feels very similar to writing subroutines in any other language...
If it works, cool. You can always refactor later
On that note, isn't that sort of all traits really are? A subroutine not attached to any particular object? But with no access to object data short of resorting to things like self classPool at: #Var, which I suppose defeats the point, but darn it, I keep running into situations where multiple inheritence would be great! Rob Rothwell
No. Traits are units of behavior that can be shared among objects.
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
My pragmatic issue with using class side methods for Singletons is that it is a bunch of work to refactor the class side behavior to instance side later. Look at the original PWS server for a squeak specific example.
Maybe it used to be, but it's a simple refactoring at the moment, refactor method >> move to instance side. Secondly, I'll worry about later... later, i.e. YAGNI, classes are nice singletons and it seems like useless work to manually implement a singleton when singleton is a built in feature.
I'll have to try it with a real example (like make PWS support multiple apps) before I change my practice.
My design issue is that classes are for making instances (technically for defining behavior of instances). Making them the building block of the program means that I'm giving them extra responsibility. I like to keep the responsibility list as small as possible.
Classes are objects too, just because most classes build instances doesn't mean they all have to. You might not want a class doing both, but I see no reason it can't do one *or* the other. Serving as a singleton works well when it's needed and keeps code simple. Saying a class should only create instances seems a rather arbitrary restriction to place upon your designs.
Singleton-ness is quite easy to code (and with class-instance variables can often be coded once and inherited). So it isn't worth it to me to mix-in my new object along with the class creation stuff from Behavior. My favorite superclass is Object (or my own, domain-specific superclass).
Do one thing and do it well is a great way to tease apart and find new objects. When the real world gives me a new problem, time for a new object. Object-oriented programming, after all.
You can do stateless, functional programming in Smalltalk. Some of the most beautiful parts of Smalltalk use a functional approach.
But loading a bunch of class side utility methods on some stateless Class doesn't feel like good object-oriented design.
Hi ramon
I agree with you. Now just without reading the complete thread, and for more complex situations here is my guideline to use singleton: I use one when I need one object "at a time" and not a single access point.
Often people confuse time and access. If you can get rid of a singleton just by adding an iv to you domain and adding a reference to point to your "singleton" then it was not a singleton but a global object access. Is it difficult to write that in a mail, a good singleton is a object representing really the fact that you cannot have two objects of the same class at the same time. Stef
On Mar 25, 2008, at 10:44 PM, Ramon Leon wrote:
(forgot to copy the list)
Classes are certainly well known, but not the only way to get a well known object.
My pragmatic issue with using class side methods for Singletons is that it is a bunch of work to refactor the class side behavior to instance side later. Look at the original PWS server for a squeak specific example.
Maybe it used to be, but it's a simple refactoring at the moment, refactor method >> move to instance side. Secondly, I'll worry about later... later, i.e. YAGNI, classes are nice singletons and it seems like useless work to manually implement a singleton when singleton is a built in feature.
My design issue is that classes are for making instances (technically for defining behavior of instances). Making them the building block of the program means that I'm giving them extra responsibility. I like to keep the responsibility list as small as possible.
Classes are objects too, just because most classes build instances doesn't mean they all have to. You might not want a class doing both, but I see no reason it can't do one *or* the other. Serving as a singleton works well when it's needed and keeps code simple. Saying a class should only create instances seems a rather arbitrary restriction to place upon your designs.
(Someone walked off with my Design Patterns Smalltalk Companion, which wrote about these issues better than I can.)
I'd love to see the arguments if you do recall them because so far, I just don't agree.
Ramon Leon http://onsmalltalk.com
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
beginners@lists.squeakfoundation.org
-
David Mitchell -
Matthew Fulmer -
Ramon Leon -
Rob Rothwell -
stephane ducasse