use Perl

• Use Method Dispatch! (Score:1)

  by chromatic (983)

  I agree with you and Dave about the fragile inheritance problem (and wonder if adding hook methods [martinfowler.com] or migrating to a Class::Std [cpan.org]-based object model would solve some of these problems.

  However, one of your suggestions makes a similarly unwarranted assumption, specifically:

  if (UNIVERSAL::can($self->{gallery}, $name) {
      $self->{gallery}->$name(shift);
  };

  What if I want to overload can()? It's a method. Why shouldn't I be able to do that?
  • Re:Use Method Dispatch! (Score:1)

    by jk2addict (4946)

    I'm not sure how to take or answer that question. So I should never use UNIVERSAL::can because you may want to override it? :-)
    
    Of course, I didn't have to check the method I'm referenceing exists at all. It just seemed like a safety measure. But then again, if you override anything in UNIVERSAL, its effects are your problem, not the modules authors problem right?
    
    Or, was this comment geared towards the UNIVERSAL::can vs. $object->can debate that flares up from time to time? :-)
    • Re:Use Method Dispatch! (Score:1)

      by chromatic (983)

      Yes, it's the great "Why in the world are you explicitly calling the parent implementation of a method on an instance of a known-derived class?" debate. Someday I'm going to write UNIVERSAL::new and write code that calls that directly instead of the actual constructors just to show how stupid a debate it is.
      • Re:Use Method Dispatch! (Score:1)

        by jk2addict (4946)

        Easy killer. :-)
        
        I'll admit, I'm a tard when it comes to that debate. I've heard mutterings and seen people use can both ways. In an effort to make me less stupid, care to elaborate on the difference between the two in the context of that debate?
        • Re:Use Method Dispatch! (Score:1)

          by chromatic (983)

          can() is an object method. There's a default implementation in the UNIVERSAL base class so that classes that don't need to define their own implementations can inherit it.

          Classes for which the default implementation is unsuitable can override it with their own implementations -- and there are good reasons for doing so, such as if you have a proxying or delegation relationship you want to keep transparent, if you autogenerate methods you can't know at compile time and don't necessarily want to install th
          • Re:Use Method Dispatch! (Score:1)

            by btilly (5037)

            I think that you're unfairly summarizing the other position in the debate.
            
            The other position as I see it can be summarized as, I think it more likely that some idiot who doesn't know about UNIVERSAL::can will write a can method that does the wrong thing, than that some smart guy will write a can method that works where UNIVERSAL::can would have failed.
            
            Which is a vote of non-confidence in others, not a desire to see things break.
            • Re:Use Method Dispatch! (Score:1)

              by chromatic (983)

              I can only see that argument as "Because someone else might write broken code, I'll deliberately write broken code."
              • Re:Use Method Dispatch! (Score:1)

                by btilly (5037) on 2005.08.27 21:59 (#42912) Journal

                Just because the argument looks silly doesn't mean that it is wrong.
                
                See this thread [perlmonks.org] where multiple good programmers, having just been told what some of the problems are trying to mix AUTOLOAD and can, tried to write a can routine and got it wrong.
                
                If good programmers who have just been told some of the big pitfalls can't do it, then why should I expect that anyone else will get it right?
                
                The problem isn't with the maintainance programmer. It is with how a couple of independent features do not combine in any reasonable way.

                Reply to This

                Parent

                • Re:Use Method Dispatch! (Score:1)

                  by chromatic (983)

                  If someone needs to override can() and does it incorrectly, calling UNIVERSAL::can() will give the wrong answer. You can't fix that without fixing their code. That's their bug.

                  If someone needs to override can() and does it correctly, calling UNIVERSAL::can() will still give the wrong answer. How is that possibly good? What possible legitimate reason is there for recommending it? This technique has no chance of working correctly in the face of an overridden can()! That's your bug.

                  For the record, I'
                  • Re:Use Method Dispatch! (Score:1)

                    by btilly (5037)

                    I think that I said it fairly well here [perlmonks.org]. From my point of view, can is not to be considered fully trustworthy or reliable. Since I don't consider it reliable, I do not rely on it, and I don't waste much energy worrying about whether I'm breaking it.
                    
                    By contrast you view it as something that is documented and supposed to work. If someone breaks it, you expect them to fix it. And since you expect people to fix it, you get upset if someone else bypasses that fix.
                    
                    To me that seems like a lot of stress and eff