in reply to Re: The beauty of MMD
in thread Perl 5's greatest limitation is...?

Jumping into a fray that isn't mine:

I think that the point is MMD is usefull and would be nice to have. I'm not sure what your argument agianst that was except that you didn't like his argument. So here is a plain as day example using Perl6 MMD and i'd like to see your example of the same code that is at least as simple.

multi method name ()              { return $.name };
multi method name (Str $new_name) { $.name = $new_name; $new_name };

[download]

The return value of the second call is always debatable, but not realy the point here. This is obviously a very simple example, but the point is, anytime your action varies depending on the types of paramters, MMD is a nice trick to have available. BTW Perl6 allows MMD and allows you to still have your old fashion perl5 send me everything in @_ subs too, so you can have your cake and eat it too (whatever that means ;) )


___________
Eric Hodges

Replies are listed 'Best First'.
Re^3: The beauty of MMD
by tilly (Archbishop) on Jul 28, 2005 at 22:44 UTC
    Here is a Perl 5 example that is simpler than what you provided, even without the Perl 6 syntactic sugar: 
    sub get_name {$_[0]{name}}
sub set_name {$_[0]{name} = $_[1]}

    [download]
    And in Ruby it is simpler still: 
    attr_accessor :name; # creates name and name= methods for you

    [download]
    The one thing that my examples are missing which yours provides is a check that the accessor really wants a string. This check is not something that I personally value, but YMMV.
[reply]
[d/l]
[select]

      If you change the problem then yes that is an answer. The point of MMD is one name for a sub that acts differently based upon inputs. The original question was over perl 5 being limited by not having MMD. Which it can be made to do, but your post does not. You may claim that MMD is useless to you, and that is fine, however it makes some tasks quite simple like shown in my post. Your answer is fine and it is probably arguable that any use of MMD can be reformated so that it can be solved without MMD. The same is true for OO, and probably any other single peice of programming or concept, it is however not realy a sound argument agianst anything at all.


      ___________
      Eric Hodges
[reply]
        The question is not whether any use of MMD can be reformatted so that it can be solved without MMD. The question is whether it is better to do so.

        I happen to believe that it should be very clear what a given subroutine does. That gives me an admitted bias against MMD, because the job of MMD is to make it easy to have subroutines which are ambiguous, they do lots of different things depending on input. However I accept that there are cases where you do need polymorphic behaviour. What I'm not convinced of is that it is worth using MMD to provide that behaviour.

        Depending on the exact problem, I'm happy to not have accessors at all in OO code. Or if you do want accessors, I'm happy to name getters and setters differently. Certainly your example doesn't give me a burning desire to use MMD.

        Now perhaps you don't think, You're adding a lot of complexity and I don't think you're getting much for it is a valid argument. In which case I don't quite know what to say. We are supposed to be in the business of managing complexity, not creating more because it is fun.

        On the other hand perhaps you think that we are getting a lot for the complexity. I don't see the wins as being significant, but we may just have different opinions on that. In which case that is fair, people do not have to agree on everything. Perl always had the attitude that it should be a big language, and people can just pick a subset that is comfortable for them.

        But I'm still puzzled at why so many seem to be so enthused about MMD, and consider it a critical missing figure. Because I obviously don't "get it" at all.

[reply]
OT: Having your cake
by kelan (Deacon) on Jul 29, 2005 at 17:49 UTC
    Off-topic comment on "have your cake and eat it too" below.
    Read more... (767 Bytes)
[reply]
      I think it came from a proverb "You can't have your cake and eat it too."

      So when things go well the saying is "You CAN have your cake and eat it soon."

      Sparky
      FMTEYEWTK
[reply]
[reply]

In Section Meditations