| Home | Forums | Reviews | Guides | Newsgroups | Register | Search |
 |
| Thread Tools |
|
Guest
Posts: n/a
|
On Thu, May 29, 2008 at 12:37 PM, David A. Black <> wrote:
> > The idea of duck typing, as I understand it, is to embrace this > inalterable fact about Ruby objects, rather than try to wish it away, > with ancestry checks and the like. This makes sense to me; it stands > to reason that a language with objects whose types can change during > runtime would be well-served by a programming style that deals as > directly and economically as possible with precisely that condition. I have to admit that I was quite disappointed that my implementation of traits got so few feedback. That is not the personal disappointment that comes simply for the reason that one wants to share a project and cannot as it does not interest others, that is a risk to take of course  .It surprised me though that Rubiests that I learnt to like and respect, like e.g. you Dave, still use the terms "types" and "classes" as if they were not in contradiction to what they are saying about duck typing afterwards. With traits we are exactly talking ducktyping, we combine behavior, which we try organize intelligently and forget about inheritance and is_a? modeling. It really gives us the chance to implement applications without abusing of inheritance. The beauty of Ruby is of course that single inheritance and Mixins are still available for projects where this is appropriate, and there are many. The bold statement I will make now is the following: Whenever a projects seems best suited to use ducktyping as its dominant design scheme, traits (as e.g. in Squeak) or prototypes ( as e.g. in Javascript) somehow seem a more natural approach than classes and mixins. Now using mixins extensively (pun intended) is a good thing especially if we refrain from abusing is_a?, Module#=== ed altri. It can lead to beautiful designs(1), but so can using traits and prototypes (1) beware of the double inclusion trap though Cheers Robert -- http://ruby-smalltalk.blogspot.com/ --- Whereof one cannot speak, thereof one must be silent. Ludwig Wittgenstein |
|
|
|
|||
|
|
| |
|
Guest
Posts: n/a
|
Hi --
On Thu, 29 May 2008, Robert Dober wrote: > On Thu, May 29, 2008 at 12:37 PM, David A. Black <> wrote: > >> >> The idea of duck typing, as I understand it, is to embrace this >> inalterable fact about Ruby objects, rather than try to wish it away, >> with ancestry checks and the like. This makes sense to me; it stands >> to reason that a language with objects whose types can change during >> runtime would be well-served by a programming style that deals as >> directly and economically as possible with precisely that condition. > > I have to admit that I was quite disappointed that my implementation > of traits got so few feedback. That is not the personal disappointment > that comes simply for the reason that one wants to share a project and > cannot as it does not interest others, that is a risk to take of > course .> It surprised me though that Rubiests that I learnt to like and > respect, like e.g. you Dave, still use the terms "types" and "classes" s/Dave/David/  > as > if they were not in contradiction to what they are saying about duck > typing afterwards. Sorry, I'm not sure which contradiction you're talking about. Can you clarify? David -- Rails training from David A. Black and Ruby Power and Light: INTRO TO RAILS June 9-12 Berlin ADVANCING WITH RAILS June 16-19 Berlin INTRO TO RAILS June 23-26 London (Skills Matter) See http://www.rubypal.com for details and updates! |
|
|
|
|
|||
|
|
| |
|
Guest
Posts: n/a
|
On Thu, May 29, 2008 at 1:35 PM, David A. Black <> wrote:
> > s/Dave/David/ s /^/So sorry, why does this always happen to me?/ > >> as >> if they were not in contradiction to what they are saying about duck >> typing afterwards. > > Sorry, I'm not sure which contradiction you're talking about. Can you > clarify? Contradiction is maybe a too strong a word, let me put it like this, IIUC, you and others made some interesting points about static modeling and ducktyping as one way of a more dynamic approach fitting Ruby's dynamic nature quite well. As many people on this list I completely adhere to this statement. I however have always thought that it was kind of exploring an interesting road without trying some new paths. E.g. using prototypes instead of inheritance and mixins or traits. Prototypes have been around for quite some while as a result of Ara's work, though I am afraid it is broken now. I have delivered a more primitive implementation (very slow 10*slower than mixins) of prototypes and a quite acceptably performing traits implementation (5*slower for 1.8, 2*slower for 1.9 although it could be faster than inheritance and mixins in a far future, but this is not really an issue here). Now I do not really want to promote my packages here, I will not even make the noise of putting uris here, those intersted can search for Labrador and ruby-traits on Rubyforge. What I want is to encourage people to go ahead, not accepting things as they are, forgetting of inheritance and mixins sometimes and try out some different approaches, not necessarily mine. And all that simply because I feel that establishing is_a? relationships does not really make much sense if we do not use them. The polymorphic approach is not at all limited to the static inheritance scheme, it is even much more ducktypier than that . Andthat is why I believe that using class and inheritance and mixins is often convenient and very often not a problem at all, but it is maybe more a tool than a concept in Ruby. Pheww I hope I got some messages across if not sorry for the waste of bandwith. Cheers Robert > > > David > > -- > Rails training from David A. Black and Ruby Power and Light: > INTRO TO RAILS June 9-12 Berlin > ADVANCING WITH RAILS June 16-19 Berlin > INTRO TO RAILS June 23-26 London (Skills Matter) > See http://www.rubypal.com for details and updates! > > -- http://ruby-smalltalk.blogspot.com/ --- Whereof one cannot speak, thereof one must be silent. Ludwig Wittgenstein |
|
|
|
|
|||
|
Guest
Posts: n/a
|
[Note: parts of this message were removed to make it a legal post.]
On May 29, 2008, at 2:14 AM, David Masover wrote: >> >> I can say >> quite categorically, that in OOP, classes are ways to generalize. You >> generalize based on characteristics and behaviors. A class is not >> simply a random collection of methods. It would be rather useless if >> class was unrelated to category. > > I'm going to have to respectfully disagree here. I'm not sure what you're disagreeing with, here. That classes are categories? If so, I could refer you to any number of the sources I learned OOP from - except that I've given them all away by now. If classes are not categories, what are they? > Unless you are going to have branching based on type -- that is, > simple method > overloading (as in C++ and friends) -- I don't see as much point to > a rigid > type system. I've done a lot of C++, and I remember when RTTI (runtime type information) was introduced. I was pretty strongly against its use, believing that polymorphism through virtual functions was the way to "branch" on type. I would have strongly avoided code like v === Numeric. As I would avoid it today, in Ruby. We're actually talking about something that I think should be rare, which is branching on type. We're only doing it to validate parameters. In good Ruby, we would not do this, relying on the runtime to tell us when we're using the wrong type. To me, duck typing doesn't mean "ask me if I quack" as much as "quack, you!". So I think this whole discussion is about an edge case. > It boils down to: Why should I care whether I'm being passed a > number or > something which merely behaves like a number? Why should I care if > I'm being > passed a string or an array of characters? Actually, I agree, in general, and this discussion has clarified the concept for me. > > Now, for the simple case of a Numeric, we're probably over-analyzing > it. Yes, I don't think I would have made the same case for a less basic class. However, I still think using responds_to? to identify an object's type is risky. As I said, it relies upon a much larger namespace than class constants, hence much more chance for accidental positives (e.g., #draw meaning different things to different objects). >> But I'm finding these remarks about "attititude" kind of amusing. >> It's >> like Ruby isn't a tool, it's a "mindset." We don't forgo something >> like Numeric === v because it's _wrong_ (the OP in fact said it was >> slightly more readable), but because Ruby has duck-typing, > > Well, there is some truth to that -- as an example, Ruby completely > lacks > anything resembling the C for loop. If that's what you're expecting, > you have > to build it out of a while loop: > > i=0 > while i < data.length > do_something_with data[i] > i += 1 > end > > There's nothing wrong with that. But I hope most of us forgo it in > favor of: > > data.each { |datum| > do_something_with datum > } > > Which ends up being more readable, among other things. Exactly. It has absolutely nothing to do with Ruby's "mindset," or "the way we do things in Ruby." We choose the latter because it's better, not because it's the Ruby way. It's the other way around: it's the Ruby way because it's better; not that it's better because it's the Ruby way. The former attitude is pragmatic, the latter is religious. > But if you do that, I don't understand why you're using Ruby. Again, > nothing > wrong with it -- do whatever makes you happy, and maybe you're right > and I'm > wrong. But I doubt I'll ever understand it. There _is_ something wrong with it. It's harder to read and more prone to error. > Can you outline a few real-world examples, where it's OK to get a > descendant > of Numeric, but not something which merely implements to_i or to_f? The obvious case is an object that implements to_i in a noncongruent way. For example, let's say the number passed in is to be used as a count. An IP address may respond to to_i, but it can't possibly be correct in this context. >> True. And often the most straightforward and fundamental way to do >> that is to call its #class method. > > Not really. > > Firstly, #class doesn't provide any way to be in multiple > categories. Ruby > doesn't support multiple inheritance. We're not talking about multiple categories - just one. In all my years of using MI in C++, I've very rarely, if ever, seen a class that didn't have a "dominant" base class. Most of the time MI is used for mixing in. You might have a class, for example, that descends both from Numeric and Observable, but obviously, its main category is Numeric. In the case under discussion, I don't think multiple categories are relevant. At any rate, even if you don't think we should be using #class, you can sure bet the language disagrees! We wouldn't get very far without it. I was emailcommunicado for a day or so, so I'm trying to catch up and I'm running out of steam, here. ... ///ark |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
On Fri, May 30, 2008 at 3:12 PM, Mark Wilden <> wrote:
> If classes are not categories, what are they? A convenient tool for specifying behavior and using inheritance and mixins for code reuse. At least that is what Ruby classes give us. Free to you to apply paradigms that can be implemented with this tool. To claim that Ruby classes *are* that kind of paradigms does not meet my approval. Maybe classes are very easily to be used as categories but I do not know that. > > I've done a lot of C++, and I remember when RTTI (runtime type information) > was introduced. I was pretty strongly against its use, believing that > polymorphism through virtual functions was the way to "branch" on type. I > would have strongly avoided code like v === Numeric. For a very good reason, because it is Numeric === v. But I feel a need to to justify my original reply to OP, he just really needed that kind of check to make something work quickly, so I showed him how to do it. I however completely agree with you that code like that rings an alarm bell. > > As I would avoid it today, in Ruby. We're actually talking about something > that I think should be rare, which is branching on type. I boldly (my turn now state that there is no type in Ruby, but Iknow what you mean and still agree! >We're only doing it > to validate parameters. In good Ruby, we would not do this, relying on the > runtime to tell us when we're using the wrong type. To me, duck typing > doesn't mean "ask me if I quack" as much as "quack, you!". I would not like to ban early failure checks like that totally. Again it just rings an alarmbell, but in some contexts TTD is difficult and then extremely defensive programming might be in order,. > So I think this > whole discussion is about an edge case. Right indeed, this was forgotten OP even stated so, good point. >> Now, for the simple case of a Numeric, we're probably over-analyzing it. > > Yes, I don't think I would have made the same case for a less basic class. For me there is a substantial difference though, and my bad that I did not mention it in my original post. Checking things like Integer ===, or String === are surely less errorprone than MyOwnClass ===, as I strongly feel that the randomly chosen Ruby programmer will mess around with them less, especially when it comes to override or revoke standard behavior. > > However, I still think using responds_to? to identify an object's type is > risky. It is even plain wrong, it specifically ask if behavior carrying a given name is implemented or not, well you put that quite nicely into the next sentence anyway > As I said, it relies upon a much larger namespace than class > constants, hence much more chance for accidental positives (e.g., #draw > meaning different things to different objects). > >>> But I'm finding these remarks about "attititude" kind of amusing. It's >>> like Ruby isn't a tool, it's a "mindset." We don't forgo something >>> like Numeric === v because it's _wrong_ (the OP in fact said it was >>> slightly more readable), but because Ruby has duck-typing, It really feels wrong because indeed each tool creates its own mindset, yet people are quite tolerant with it, but you just have to remember all the time in Ruby (not as a mindset but as a simple consequence of how Ruby works) Class != Behavior >> There's nothing wrong with that. But I hope most of us forgo it in favor >> of: >> >> data.each { |datum| >> do_something_with datum >> } Amen. >> >> Which ends up being more readable, among other things. > > Exactly. It has absolutely nothing to do with Ruby's "mindset," or "the way > we do things in Ruby." We choose the latter because it's better, not because > it's the Ruby way. >It's the other way around: it's the Ruby way because it's > better; not that it's better because it's the Ruby way. The former attitude > is pragmatic, the latter is religious. Strangely enough I see it the other way round: "It is better" ( a very dangerous statement indeed) seems dogmatic to me. using the mindset implied by semantics OTOH feels very pragmatic. >> Firstly, #class doesn't provide any way to be in multiple categories. Ruby >> doesn't support multiple inheritance. You just have come to the end of your own argument I am afraid. Not being an expert I might be wrong of course, do you mean that mixins are not powerfull enough to satisfy that model? Robert |
|
|
|
|
|||
|
|
| |
|
| Thread Tools | |
|
|
