SitePoint Sponsor

User Tag List

Page 6 of 8 FirstFirst ... 2345678 LastLast
Results 126 to 150 of 190
  1. #126
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    Such as?

    OOP - particularly OOP combined with testing - is a much more powerful way to work. I can understand if it looks over-complicated or unecessary on first contact (I thought that when I was starting out) but statements such as above can be very misleading for people who are trying to learn. You don't have to, of course. Php is a bus you can hop on and off anywhere you like. But if you do want to learn to produce the best quality code you possibly can, OOP and testing is the way to go. We'd be selling people short to pretend that procedural is just as good or that it's all just a matter of personal preference.
    Examples of awful places to use objects / classes:

    - Templates themselves (a "templating" class is usually a good idea, but templates should be pretty much just plain text with some conditional logic thrown in).

    - Entry points / boot strapping

    - Maintenance scripts


    The primary advantages of classes are:

    - Modularity (irrelevant since in php you're dealing with individual files...everything is already highly modular)

    - Encapsulation (depending on context can be important or not. Generally speaking, it's a lot easier to encapsulate data with classes than without, but php's file-scoped nature means that you have other options).

    - Reusability (largely irrelevant to a dynamically typed, interpreted language since you can very easily reuse the same function call or include line for many different types of data without issue)

    - Aiding in self-documenting code (ppp methods are more about documentation than actually enforcing anything. Many languages don't actually enforce the constraints at run time, and are only checked at compile time).

    That being said, using classes within php generally gives you some advantages, but they aren't the traditional variety:

    - Using classes as "namespaces"
    - Taking advantage of autoload / class_exists / method_exists / interfaces for some truly dynamic programming.
    - Ability to override behavior of many engine internals using SPL.

    And, of course, exceptions are tremendously useful, but there's no real reason why an exception has to have anything to do with objects.

    Most of the traditional advantages afforded by classes are beneficial in the nasty world of strong, statically typed, compiled languages, but have little impact on the paradigm under which PHP shines.

    Well, you can't deny that a code is definatly of better quality if it uses one class to handle let's say all the news functions instead of retyping all of the code everytime you need to do something with news.
    Only an extremely novice programmer would do that. Classes don't magically create "reusability". You can get just as much reusability out of a collection of functions as you can out of a class. Do you write an entire regex engine every time you want to do some complex pattern matching on a string? Of course not, you use the (procedural) PCRE functions.

    The problem with java in this regard is that primitives aren't objects; if they were, all that functionality could simply be replaced with method calls to number objects, as they are in Ruby. So really, this is a case of the language not being OO enough.
    You mean half-assed? There's no real difference between doing 5.sqrt() and sqrt(5), if you look at Math as a namespace (think C++, where you might see something like std::sqrt(5)).

    Wrapping functions in a class is useful in PHP because there isn't a namespace, but wrapping the native functions that you're never likely to alter in a class just for the sake of being "more OOP" is a waste of your time. I can say with a fair degree of certainty that you're not going to be re-implementing functions like sqrt, pow, and other basic math routines any time soon.

    There's nothing wrong with mixing procedural and OO code. Think about ordinary human language -- some times you say something with the noun first, then the verb, and other times you do the reverse.

    dog.poop() makes sense, but

    walk(dog) does too.

    poop.dog() and dog.walk() aren't things I think anyone is interested in seeing.

    yes you can program everything in procedural (but u can also do the same thing in assembly, (or even binary)) but it just gets rediculos!
    Yeah, ridiculous, like the Linux Kernel, most (if not all) BSD Kernels, Apache, PHP, most unix tools...

    OOP doesn't really make development go any faster or make it any easier to maintain. In many cases (such as C++, which is usually just more trouble than it's worth unless you stick to the basic features), it actually slows development down.

    or if you have a fetish for brackets you can program in SCHEME, same thing the program will work but ittl be a waste of your time
    If it weren't for the crappy syntax, I'd love to use SCHEME (or lisp) more regularly. Unfortunately about the closest I get to those on a daily basis is javascript (which is basically lisp in C's clothing). Not sure what this has to do with anything, as OOP has nothing to do with functional vs structured programming anyway. Javascript is an OO ("everything is an object"), functional language.

    write a multithreaded server and graphical browser in Java then write the same in procedural C and then youll see for yourself
    You really have no idea what you're talking about, do you? OOP vs procedural has nothing to do with this. The only real advantage that OOP gives you with regards to threads is that it allows you for convenient storage of your mutexes and the like, but threads are usually a bad idea for most servers anyway (unless you're stuck developing for windows, which managed to completely drop the ball with regards to their process handling and relies on kludges like packing a bunch of individual services into a single process...so much for virtual memory as a safety mechanism!)

    except for php5 which as language is quite nice and fast but lacks thousands of packages and classes that make Java and .NET languages so usefull for programmers
    I'm pretty sure that the thousands of packages available through PECL and PEAR compare pretty favorably to what's available to Java and .NET programmers...and considering that PHP is the most popular web development language in existence I think it's fair to say that the programmers are getting by quite well with the tools that they have. Nobody's dropping PHP to jump to Java or .NET. They might be jumping to Ruby or one of the recent Python implementations, but anyone who does heavy web development realized long ago that the "P" languages (and those like them) are an infinitely superior tool for this type of task.

    You have missed the key feature of OO...
    PHP Code:
    $table = new WithCrossLinks(new TableDisplay(new DefaultAccount()));

    $table = withCrossLinks(tableDisplay(getDefaultAccount());
    doSomethingWith($table);

    Changing the noun-verb relationship has very little real impact on project development.

    OO vs procedural code usually boils down to...

    PHP Code:
    $obj = new Object();
    $obj->doFirstThing();
    $obj->doSecondThing();
    $obj->doOtherThingWith(new Thing()); 
    vs

    PHP Code:
    $obj Object();
    doFirstThing($obj);
    doSecondThing($obj);
    doOtherThingWith($obj,Thing()); 
    I suppose this distinction can help some people, but I haven't really found that it makes a single drop of difference on projects. I'm currently working on an absolutely enormous real time communication system that's almost entirely in C++, and the code that has been written so far is just as bad as the old system which was done in C.

    A lot of the OO stuff doesn't work so well in dynamically typed languages for other reasons; for example, most languages have all kinds of funky ways of creating containers. In php you pretty much always just use a map (what they call "array"). You never think about iterators or insertion operators or any of that. It's just not a problem that has to be solved.

    The biggest failing of OOP is that it attempts to solve the problem of "large" systems, when in truth large systems should simply be avoided like the plague. You should break up large systems into small, modular, and INDEPENDENT chunks, ideally with each one operating in separate environments. For large scale systems, this is a must anyway, since scalability pretty much mandates that every component of the system operate on a separate piece of hardware. In this model, OOP vs procedural is meaningless.

    Yes, as long as they address problems in PHP, not some other language
    That hits the nail right on the head. I'm still baffled as to why people try to implement patterns that have no place in PHP in PHP. It's just a waste of time.

  2. #127
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    but php's file-scoped nature means
    There's no file-scope in php ? Or did you mean global scope ?

    Quote Originally Posted by Etnu
    Reusability (largely irrelevant to a dynamically typed, interpreted language since you can very easily reuse the same function call or include line for many different types of data without issue)
    Inheritance is a very powerful tool for reusability. Procedural lumps of code just can't do that.

    Quote Originally Posted by Etnu
    dog.poop() makes sense, but

    walk(dog) does too.

    poop.dog() and dog.walk() aren't things I think anyone is interested in seeing.
    Do you mean person.walk(dog) ? Or does the dog actually walk by itself, in which case dog.walk() would make sense ?

    Quote Originally Posted by Etnu
    OO vs procedural code usually boils down to...
    Not really. You are assuming a procecural mindset, which of course will lead to similar code in the to syntaxes.

    In the example, you gave (the second), there is a static coupling between the utilizing code and the function Thing(). In the first example (which uses OOP syntax), you could pass the object in, and thus decouple that relationship.

  3. #128
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    using classes within php generally gives you some advantages, but they aren't the traditional variety
    Polymorphism? Really, that's the beginning and end of the OOP v procedural debate right there. Procedural got hit below the waterline in one of the very first exchanges and is sinking fast.

    I agree with some of the things you've said but I also think that OOP is not just for large systems. Any non-trivial piece of code will benefit from OOP. You will find different roles - ie objects - if you hunt them down.

  4. #129
    SitePoint Guru
    Join Date
    Aug 2005
    Posts
    986
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think it is easier to get design right with object oriented style. You have high level objects, which operate on lower level objects, which in turn operate on even lower level objects. You can spin this both ways, see?
    No, this isn't true. If you have an object, this object handles all operations himself (if you've done OOP "right"). So that would be both lower and higher level operations.

    The primary advantages of classes are:

    - Modularity (irrelevant since in php you're dealing with individual files...everything is already highly modular)
    "Modularity - A quality of a system where it consists of various parts which separate cleanly and fit together well. High modularity costs some design time but pays back well through clarity, elegance, maintainability and flexibility."

    I think you have better modularity (on a small scale) if you use functions because every function is essentially a module, "which separates cleanly". With OOP, an entire class is a module, and the functions depend on each other's effects, so a *class* is a module. I don't know if this makes a huge difference on this small level, but it could.

    - Encapsulation (depending on context can be important or not. Generally speaking, it's a lot easier to encapsulate data with classes than without, but php's file-scoped nature means that you have other options).
    You hide implementation with encapsulation. There is no difference here, because you hide implementation in methods or functions. You still hide the implementation in the same way.
    - Reusability (largely irrelevant to a dynamically typed, interpreted language since you can very easily reuse the same function call or include line for many different types of data without issue)
    I assume we're talking about intra-application-re-usability, and not inter-application. Practically the only thing you can share between applications is a database class/are database functions.

    As you said, you can easily reuse the same function or class. I think that functions are more reusable, because you could be able to reuse one (or two) methods of a class for a new one. You can't do that (unless you inherit from the existing class, which is a problem if you want to inherit from another class too), but with functions, you can easily reuse one function for different things. I don't think there is much difference here if you have multiple inheritance or something like mix-ins, but PHP doesn't have these.

    - Aiding in self-documenting code (ppp methods are more about documentation than actually enforcing anything. Many languages don't actually enforce the constraints at run time, and are only checked at compile time).
    I don't think that there is a difference here, besides that the name of the class is explicit if you define it. You could easily add a comment like:

    Code:
    # these functions work on #{kind-of-thing}
    But there is a problem here. In OOP, methods belong to an object, but if you use functions, they don't necessarily belong to the first argument of the function.

    Example:

    Code:
    function add_to_todo($todo_list, $item){}
    Does this function belong to the todolist or to the item?

    And if we'd written it like this:

    Code:
    function add_to_todo($item, $todo_list){}
    (I don't like the order of the arguments in this function personally)

    If you use a class, that function would probably be in the TodoList class. If I'm uncertain about the order of arguments I want a function to have, I ask myself in which class I would put it if I were using OOP, and use that as the first argument ;-). So maybe some things are easier to get "right" if you use OOP.

    Not really. You are assuming a procedural mind set, which of course will lead to similar code in the to syntaxes.
    The syntax really doesn't matter. CLOS (yea, that's a thing in a paren language) uses this syntax:

    Code:
    (method object arg1 arg2 .. argn)
    instead of:

    Code:
    $object->method($arg1, $arg2, .. $argn)
    In the example, you gave (the second), there is a static coupling between the utilizing code and the function Thing(). In the first example (which uses OOP syntax), you could pass the object in, and thus decouple that relationship.
    That's because you can't dispatch functions on arguments in PHP. With OOP, you can at least dispatch on one argument (the first). If you have a good type system, you can dispatch on all arguments (which means polymorphism on all arguments). But you're right, this is one advantage of OOP in languages without a good type system.

    I agree with some of the things you've said but I also think that OOP is not just for large systems. Any non-trivial piece of code will benefit from OOP. You will find different roles - ie objects - if you hunt them down.
    So, what is the benefit, besides having to hunt down the objects?

  5. #130
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Fenrir2
    No, this isn't true. If you have an object, this object handles all operations himself (if you've done OOP "right"). So that would be both lower and higher level operations.
    Really? Ever heard of, say, a Facade?

    Aren't you the least bit worried about not being able to create your own data types? With the way you're going, you'll need to emulate them with in-built structures on the spot, and have to handle them using special functions instead of them being neatly wrapped and contained. I have a hard time imagining encapsulation in procedural form. That's just in my head, of course, but it might be an indication of which approach would be easier to handle.

    Some pseudo:
    Code:
    def output(data):
       switch(true):
          case is_string(data): print data; break;
          case is_int(data): print i_to_s(data); break;
          case is_float(data): print f_to_s(data); break;
          case is_array(data):
             foreach key => value in data:
                output(key)
                print " => "
                output(value)
                print "\r\n"
             end
          break
       end
    end
    
    # vs.
    
    def output(data):
       print data.to_s
    end
    What happens when you have a format that needs to be handled differently? How do you solve it in the former case? By passing around handlers for different situations with the associated data? If so, why not just couple the two together to begin with? Tell me about your approach.
    Last edited by Ezku; May 22, 2006 at 09:26.

  6. #131
    SitePoint Evangelist CapitalWebHost's Avatar
    Join Date
    Apr 2003
    Location
    Albany, NY
    Posts
    417
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm just amazed that my little comment in another thread was the catalyst for such a great discussion.

  7. #132
    SitePoint Guru
    Join Date
    Aug 2005
    Posts
    986
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Really? Ever heard of, say, a Facade?
    Yes. A facade is something that wraps a hard to use interface in a nice to use class. But I think you missed my point. A facade doesn't solve the problem I mentioned, because it only makes things easier for the caller. What I meant is that with OOP, an object should handle all operations on the object (encapsulation). Some operations could be low level, others will be high level. They all belong in the same class. This way, you don't structure your code in nice modular blocks which accomplish the one task.

    Aren't you the least bit worried about not being able to create your own data types? With the way you're going, you'll need to emulate them with in-built structures on the spot, and have to handle them using special functions instead of them being neatly wrapped and contained. I have a hard time imagining encapsulation in procedural form. That's just in my head, of course, but it might be an indication of which approach would be easier to handle.
    This has nothing to do with OO ;-). You can create new datatypes transparently by building them from things that already exist. It just isn't explicit, so that might be why you haven't noticed.

    The example code you give is ridiculous. The functional equivalent would be:

    Code:
    def output(data)
       print to_s(data)
    end
    (do you program in Ruby too? Your code is nearly correct Ruby code)

    The ability to dispatch on types has nothing to do with OOP:

    Instead of doing:

    Code:
    class Integer
      def to_s
        # do something
      end
    end
    
    class String
      def to_s
        self
      end
    end
    You do:

    Code:
    def to_s(Integer i)
      # do something
    end
    
    def to_s(String s)
      s
    end
    Unfortunately this is not possible in PHP. You got me, that's one + for OOP.

  8. #133
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Fenrir2
    Unfortunately this is not possible in PHP. You got me, that's one + for OOP.
    Or in any other language for the matter, unless of course the datatype is explicitly declared ...

  9. #134
    SitePoint Guru
    Join Date
    Aug 2005
    Posts
    986
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Of course, it's like defining a class. (but you'd have multiple dispatch).

    Bah, I think I have to create my own language.

  10. #135
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Fenrir2
    A facade is something that wraps a hard to use interface in a nice to use class.
    You're thinking of Adapter, I believe. Facade is intended to wrap several subsystems into one.
    What I meant is that with OOP, an object should handle all operations on the object (encapsulation). Some operations could be low level, others will be high level. They all belong in the same class.
    If the Facade didn't do the trick, let me put it this way: have you heard of delegating? All the code related to completing an action doesn't need to be included in a single class (just as it doesn't need to be included in a single function!), they can be spread out to layers of delegates that handle increasingly lower level operations the deeper you go.

    The ability to dispatch on types has nothing to do with OOP
    I posit that without OO you cannot define your own types, which renders the following invalid:
    The functional equivalent would be:
    Code:
    def output(data)
       print to_s(data)
    end
    You do:
    Code:
    def to_s(Integer i)
      # do something
    end
    def to_s(String s)
      s
    end
    This, of course, won't work at all if
    • the language of choice doesn't support defining the same function multiple times with different arguments (or overriding the function with an ability to call the overrided one from the inside, in effect creating a CoR), or
    • to_s() receives something that on top looks like, say, an array, but you'd like it to be formatted differently - you can't differentiate your "types" from the base ones
    Either way, you're stuck at not being able to extend the functionality in question.

    Am I making sense?

    (do you program in Ruby too? Your code is nearly correct Ruby code)
    Somewhat familiar with it. I just needed to try and remove the OOness of Ruby to construct a sensible example.

  11. #136
    Web-coding NINJA! silver trophy beetle's Avatar
    Join Date
    Jul 2002
    Location
    Dallas, TX
    Posts
    2,900
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Are you guys are talking about function overloading being somewhat analgous to two classes that share a common interface? (or even implement an Interface proper?)
    beetle a.k.a. Peter Bailey
    blogs: php | prophp | security | design | zen | software
    refs: dhtml | gecko | prototype | phpdocs | unicode | charsets
    tools: ide | ftp | regex | ffdev




  12. #137
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by beetle
    Are you guys are talking about function overloading being somewhat analgous to two classes that share a common interface? (or even implement an Interface proper?)
    I do believe that is what Fenrir2 is trying to apply, yes.

  13. #138
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    Polymorphism? Really, that's the beginning and end of the OOP v procedural debate right there. Procedural got hit below the waterline in one of the very first exchanges and is sinking fast.
    Polymorphism is a crutch for statically typed languages. Dynamically typed languages need polymorphism about as much as a fish needs dirt. If polymorphism is the "beginning and the end" of OOP, then OOP is truly pointless. However, it isn't, as there are other OOP features that can be very useful.

    I agree with some of the things you've said but I also think that OOP is not just for large systems. Any non-trivial piece of code will benefit from OOP. You will find different roles - ie objects - if you hunt them down.
    It's not just for large systems, it's just foolhardy to say that OOP = quality code. It has nothing to do with it. If you read the end of my post you'll note that I point out that "large" systems are inherently flawed anyway.

  14. #139
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    Polymorphism is a crutch for statically typed languages. Dynamically typed languages need polymorphism about as much as a fish needs dirt.
    That is not true. Maybe you're confusing polymorphism with typecasting ?

  15. #140
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    Polymorphism is a crutch for statically typed languages.
    I would say catagorically untrue. Polymorphism is just as powerful in a dynamic language as a staticly typed one. Can you explain yourself further?
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  16. #141
    SitePoint Guru silver trophy Luke Redpath's Avatar
    Join Date
    Mar 2003
    Location
    London
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have to echo the above sentiments - I'm not sure where you get the idea that polymorphism isn't useful in dynamic languages - polymorphism is just as useful in either static and dynamic languages even though implementation for one isn't neccesarily appropriate for the other (interfaces and typehinting in static languages vs duck typing in dynamic languages).

  17. #142
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Fenrir2
    Of course, it's like defining a class. (but you'd have multiple dispatch).

    Bah, I think I have to create my own language.
    Before you begin take a look at the multi class:

    Code:
    multi(:foo, Integer) { |x|
    	puts "integer #{x}"
    }
    multi(:foo, String) { |x|
    	puts "string #{x}"
    }
    
    foo 10
    foo "hello"
    Quite nifty, isn't it?

  18. #143
    SitePoint Guru
    Join Date
    Aug 2005
    Posts
    986
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think that polymorphism is important, even in dynamically typed language (but maybe less important). For example, Ruby's method === is based on it, and because Ruby has polymorphism, functions like Enumerable#grep() (wich uses ===) can be made.

    Quite nifty, isn't it?
    It certainly is! That looks a lot cleaner than a switch-dispatch in foo(). Thanks!

  19. #144
    SitePoint Addict
    Join Date
    Mar 2004
    Location
    Grand Junction, CO
    Posts
    292
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    I would say catagorically untrue. Polymorphism is just as powerful in a dynamic language as a staticly typed one. Can you explain yourself further?
    I'm not entirely sure what he means, but my best guess is that duck-typing renders polymorphism irrelevant.

    Before I show any examples, I want to point out that Ruby is the only dynamic language I know. I imagine other dynamic languages support duck-typing as well, but I'm not positive.

    In Java, you could have the following code:
    Code:
    class Animal {
      public String talk() { return ""; }
    }
    
    class Dog extends Animal {
      public String talk() { return "woof"; }
    }
    
    class Cat extends Animal {
      public String talk() { return "meow"; }
    }
    
    // Some random method
    public void speak(Animal a) {
      System.out.println(a.talk());
    }
    
    speak(new Dog());   #  woof
    speak(new Cat());    #  meow
    For something like that you'd probably use an interface instead, but you get the idea.

    In Ruby, there's no need to create a base class or an interface. You just make sure that the class supports the #talk method.

    Code:
    class Dog
      def talk; "woof"; end
    end
    
    class Cat
      def talk; "meow"; end
    end
    
    def speak(a)
      puts a.talk
    end
    
    speak Dog.new  # woof
    speak Cat.new   # meow
    Polymorphism is a tool to write flexible, dynamic code in a statically typed language (though still not as flexible as a dynamic language). Ruby doesn't benefit from it, simply because it doesn't check types at compile time.

  20. #145
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pergesu
    I imagine other dynamic languages support duck-typing as well, but I'm not positive.
    Yeah, that's a tautology - all dynamic languages support duck typing.

    Quote Originally Posted by pergesu
    Polymorphism is a tool to write flexible, dynamic code in a statically typed language (though still not as flexible as a dynamic language). Ruby doesn't benefit from it, simply because it doesn't check types at compile time.
    It's nitpicking I know, but you're getting it wrong. If you replace the word polymorphism with typecasting, your quote makes sense. The example you showed above, utilizes polymorphism. This is true for the java as well as the ruby example.

    Off Topic:


    Quote Originally Posted by pergesu
    ... doesn't check types at compile time.
    Does ruby code compile ? I thought it was interpreted ?

  21. #146
    SitePoint Addict
    Join Date
    Mar 2004
    Location
    Grand Junction, CO
    Posts
    292
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    The example you showed above, utilizes polymorphism. This is true for the java as well as the ruby example.
    You're absolutely right. That Ruby code is polymorphic, even though the classes aren't related at all.

    So that leaves me wondering what Etnu was talking about I just took my best shot...and missed

    Off Topic:

    Does ruby code compile ? I thought it was interpreted ?
    Yeah, it's interpreted. It doesn't check types at compile time because there is no compile time.

  22. #147
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pergesu
    I'm not entirely sure what he means, but my best guess is that duck-typing renders polymorphism irrelevant.[...]

    In Java, you could have the following code:
    [...]

    In Ruby, there's no need to create a base class or an interface. You just make sure that the class supports the #talk method.

    Code:
    class Dog
      def talk; "woof"; end
    end
    
    class Cat
      def talk; "meow"; end
    end
    
    def speak(a)
      puts a.talk
    end
    
    speak Dog.new  # woof
    speak Cat.new   # meow
    Polymorphism is a tool to write flexible, dynamic code in a statically typed language (though still not as flexible as a dynamic language). Ruby doesn't benefit from it, simply because it doesn't check types at compile time.
    It seems you are confused as to what the term "polymorphism" actually means. Polymorphism, in the most generic sense, means that code can call some identifiable interface, and the runtime can dispatch that call to different implementations based on some characteristic. Polymorphism as it is being used in this thread is referring to the ability to dispatch to different method implementations based on the type of the object in question. It really doesn't have anything to do with dynamic typing or static typing.

    Your Ruby example above is actually a perfect illustration of polymorphism. How does ruby determine what code to run when your speak() function calls a.talk? It determines this based on the way your a object responds to the "talk" message. Dog's implementation differs from Cat's implementation, but the speak() function doesn't need to know or worry about that. As long as the parameter can respond to the "talk" message (in some way, even if it ends up using a missing method handler) everything is fine. This is polymorphism...

  23. #148
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    Enough point scoring already . What makes good code?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  24. #149
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    What makes good code?
    Why, I do ... Oh ... no more cheap points, you said ?

    I suppose that we can keep enumerating technicalities, which are good practice, but doesn't ensure anything in and by itself. The real answer isn't a technical one though - it's the same as to "What makes a good novel". Good code has good litterary qualities.

    As a programmer I often feel a bit misunderstood by my non-computer friends (I have a few left, yes). The general assumption is that programming is an engineering discipline - we all know the metaphore of 1's and 0's. Of course to some extend it is, but I have always felt that programming is much more of a linguistic discipline than a technical one. I failed math horribly in highschool, yet I make a good programmer (should I say it myself at least).

  25. #150
    SitePoint Member
    Join Date
    Jan 2006
    Location
    Norway
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Good code is like the perfect woman.
    Hard to define, but it is love at first "site"


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •