use Perl

• Use Method Dispatch! (Score:1)

  by chromatic (983) on 2005.08.22 11:08 (#42791) Homepage Journal

  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?

  Reply to This

  • 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 jk2addict (4946)

            Thanks for that. Now I get it.
            
            Would it be safe to assume that I should always use ->can against other classes, but if I was overriding and making my own can() sub, that the guts of my new and improved can() should use UNIVERSAL::can; or should it use $self->SUPER::can?
            • Re:Use Method Dispatch! (Score:1)

              by chromatic (983)

              It's a normal method, so treat it as you would handle any inherited method. If you use SUPER, the implementation in the parent can change but the child can continue to work without change.
          • Re:Use Method Dispatch! (Score:1)

            by rjbs (4671)

            Using UNIVERSAL::can() as a function is unfair to objects, which might implement their own can method. Using the can method, however, is a real pain, because one can't just say:

            if ($scalar->can("explode")) {

            because the program will die unless $scalar is an object or package name. If it's an unblessed reference or a simple scalar, calling a method throws an exception, so one ends up writing:

            if (ref $scalar and blessed($scalar) and $scalar->can("explode")) {

            which is just a lot of typing, and we kn

            --
            rjbs
            • Re:Use Method Dispatch! (Score:2)

              by Matts (1087)

              The first ref($scalar) there is redundant, so it's a *bit* less typing ;-)
              • Re:Use Method Dispatch! (Score:1)

                by rjbs (4671)

                You're right, this is my fault for waffling. I was going to say:

                if (ref $scalar and (not grep { ref $scalar } @std_types) and $scalar->can('explode')) {

                but then I decided that it was fine to assume, for the example, that Scalar::Util was available, and that I was being overly snarky.
                
                By the way, note the use of UNIVERSAL::isa in perldoc -f ref.

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

                  by chromatic (983)

                  Don't worry; Rafael applied my patch to perlfunc a little while ago.
            • Re:Use Method Dispatch! (Score:2)

              by malte (1708)

              able is a good idea. Plus we need an option for Scalar::Util:

              use Scalar::Util export => "able", to_namespace => "Customer::ProjectName"
          • 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)

                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
                • 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