Pat Maddox wrote:
> >> > > > 4. What are singleton methods all about?
I'm not doubting that you know what the singleton pattern is. I'm just saying you clearly don't know what a singleton METHOD is. Either that or you didn't read the question.
My bad. I was recovering from a nauseating refactoring session regarding the Singleton Pattern, so I indeed forgot to read the word "methods".
Phlip wrote:
Pat Maddox wrote:
I know what MVC is. I was just saying that, to me anyway, a 3-tiered architecture is something completely different.
And all Rails is, out of the box, is 3-layered. Not true MVC, and not 3-tiered.
Hmm. Given the constraints of working with HTTP, is Rails any less MVC than J2EE Model 2 MVC? That pattern is what is commonly referred to as 'MVC' in web application development.
Justin Forder
Pat Maddox wrote:
[snip]
I'm not doubting that you know what the singleton pattern is. I'm just saying you clearly don't know what a singleton METHOD is. Either that or you didn't read the question.
Here's the simplest case of a singleton method: class Foo def self.foo "This is a singleton method on Foo" end end
foo is a singleton method on the class Foo. You might also know it as a class method. I generally find them helpful, and not in the context of trying to shoot myself.
I was curious what singleton method is as well but found your explanation unclear. According to this link,
http://www.math.hokudai.ac.jp/~gotoken/ruby/ruby-uguide/uguide16.html
a singleton method is a method specialized on an instance of a Class, not the class itself.
Here we define a singleton method on an object. o = Object.new def o.foo "foo" end
Yes, this is how one would define a singleton method.
which could also be class << o def foo end
Hmmm, interesting...
Singleton methods are, quite simply, methods defined on the singleton class of an object.
Again very confusing statement.
I recommend picking up Ruby for Rails, it has a very good discussion of singleton methods. It's probably the most in-depth Ruby book around.
Pat
Hi --
Pat Maddox wrote:
[snip]
I'm not doubting that you know what the singleton pattern is. I'm just saying you clearly don't know what a singleton METHOD is. Either that or you didn't read the question.
Here's the simplest case of a singleton method: class Foo def self.foo "This is a singleton method on Foo" end end
foo is a singleton method on the class Foo. You might also know it as a class method. I generally find them helpful, and not in the context of trying to shoot myself.
I was curious what singleton method is as well but found your explanation unclear. According to this link,
http://www.math.hokudai.ac.jp/~gotoken/ruby/ruby-uguide/uguide16.html
a singleton method is a method specialized on an instance of a Class, not the class itself.
However, a class is itself an instance of Class, and in that capacity, it can have singleton methods. As Pat says, the singleton methods of a Class object are what we call "class methods". Mostly that's just a convenience term; singleton methods work the same way whether their object is a Class, a String, or a Whatever. However, there's one special behavior: a subclass can call its superclass's singleton methods:
class C def self.talk puts "Hello" end end
class D < C end
D.hello
That's the only case where an object can access another object's singleton methods. It's a bit of an anomaly, but it's a worthwhile anomaly because it adds a useful functionality.
Here we define a singleton method on an object. o = Object.new def o.foo "foo" end
Yes, this is how one would define a singleton method.
which could also be class << o def foo end
Hmmm, interesting...
Singleton methods are, quite simply, methods defined on the singleton class of an object.
Again very confusing statement.
All you need is some info on singleton classes, and then it will make sense. Here's a starting point: http://www.wobblini.net/singletons.html
David
Justin Forder wrote:
Hmm. Given the constraints of working with HTTP, is Rails any less MVC than J2EE Model 2 MVC? That pattern is what is commonly referred to as 'MVC' in web application development.
That system is why I went to the ModelViewController page on a certain Wiki and added 'When a system obeys the principle DoTheMostComplexThingThatCouldPossiblyWork, marketects often respond by clumping its rambling notions together into 3 groups. The sub-SpaghettiCode group nearest the User becomes the "view", that nearest the database becomes the "model", and the stuff in between becomes the "controller".'
To answer your question, the browser layer ain't the View. The View is "That which observes the Model", which is typically in our controller layer.
David wrote:
Hi --
[snip]
All you need is some info on singleton classes, and then it will make sense. Here's a starting point: http://www.wobblini.net/singletons.html
So this singleton method/class method is ruby-specific. Good starting point nonetheless.
Thanks,
Long
Phlip wrote:
Justin Forder wrote:
Hmm. Given the constraints of working with HTTP, is Rails any less MVC than J2EE Model 2 MVC? That pattern is what is commonly referred to as 'MVC' in web application development.
That system is why I went to the ModelViewController page on a certain Wiki and added 'When a system obeys the principle DoTheMostComplexThingThatCouldPossiblyWork, marketects often respond by clumping its rambling notions together into 3 groups. The sub-SpaghettiCode group nearest the User becomes the "view", that nearest the database becomes the "model", and the stuff in between becomes the "controller".'
To answer your question, the browser layer ain't the View. The View is "That which observes the Model", which is typically in our controller layer.
That does nothing to answer my question, and jumps to a wrong conclusion about what I thought the View was, but at least it tells us what one of your layers is.
The part of Rails that *presents* the Model is the View.
Model 2 MVC is a server-side MVC model constrained by the grain size of the HTTP request/response, dividing responsibilities as follows:
- the controller interprets the HTTP request, makes any changes required on the model, and decides what view should be presented next;
- the view renders the required parts of the model, together with user controls, to provide the body of the HTTP response;
- the model is an appropriate OO model of the application domain.
This is a perfectly valid interpretation of MVC, given the constraints, and has been the dominant OO web architecture over the past five years. Competition from component-oriented MVC web architectures (JSF, Tapestry, WebObjects...) is growing, and continuation-based approaches are worth keeping an eye on.
You concentrated on the "observing" relationship between the view and model which is an important part of classical MVC. That works well Smalltalk (and in 'fat' applications in general), where the view can be updated incrementally, but is less relevant when you are using HTTP with a stateless server. Then you have to create the whole rendered result on each request.
regards
Justin Forder
Justin Forder wrote:
Phlip wrote:
Justin Forder wrote:
Hmm. Given the constraints of working with HTTP, is Rails any less MVC than J2EE Model 2 MVC? That pattern is what is commonly referred to as 'MVC' in web application development.
That system is why I went to the ModelViewController page on a certain Wiki and added 'When a system obeys the principle DoTheMostComplexThingThatCouldPossiblyWork, marketects often respond by clumping its rambling notions together into 3 groups. The sub-SpaghettiCode group nearest the User becomes the "view", that nearest the database becomes the "model", and the stuff in between becomes the "controller".'
To answer your question, the browser layer ain't the View. The View is "That which observes the Model", which is typically in our controller layer.
That does nothing to answer my question, and jumps to a wrong conclusion about what I thought the View was, but at least it tells us what one of your layers is.
The part of Rails that *presents* the Model is the View.
Model 2 MVC is a server-side MVC model constrained by the grain size of the HTTP request/response, dividing responsibilities as follows:
- the controller interprets the HTTP request, makes any changes required on the model, and decides what view should be presented next;
- the view renders the required parts of the model, together with user controls, to provide the body of the HTTP response;
- the model is an appropriate OO model of the application domain.
This is a perfectly valid interpretation of MVC, given the constraints, and has been the dominant OO web architecture over the past five years. Competition from component-oriented MVC web architectures (JSF, Tapestry, WebObjects...) is growing, and continuation-based approaches are worth keeping an eye on.
You concentrated on the "observing" relationship between the view and model which is an important part of classical MVC. That works well Smalltalk (and in 'fat' applications in general), where the view can be updated incrementally, but is less relevant when you are using HTTP with a stateless server. Then you have to create the whole rendered result on each request.
oops - "works well Smalltalk" should be "works well in Smalltalk"
Justin