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

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]}
And in Ruby it is simpler still:
attr_accessor :name; # creates name and name= methods for you
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.

Replies are listed 'Best First'.
Re^4: The beauty of MMD
by eric256 (Parson) on Jul 30, 2005 at 23:52 UTC

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

        Perhaps I'm just having trouble following the thread, but I see MMD the other way around. MMD's job is to make it easy to have subroutines which are concrete and unambiguous.

        =item calculate_area The calculate_area function calculates the area of the points passed in. You can pass the points in a number of different ways, but, regardless, you'll get the area back. =over 4 =item * You can pass in a series of points. The function will assume that the shape described is a closed-shape, that is, the first point is automatically repeated as the end point. You can pass in the points as perl6 pairs, e.g.: $area = calculate_area( $x0 => $y0, $x1 => $y1 ); or as two lists of x's and y's: $area = calculate_area( @x, @y ); or as a list of Point objects $area = calculate_area( @points ); =item * You can pass in a Shape object. $area = calculate_area( $shape ); =item * You can pass in an equation, and a beginning x-value and an ending x-value, and the area will be that under the curve. The area may be negative in this case. $area = calculate_area( $equation, $x0, $x1 ); =back Returns: the area of the shape, in square units. =cut
        To me, the subroutine is incredibly unambiguous. It calculates area. It's a nice DWIMmy function that can handle any type of input. However, if I were to maintain this type of DWIMmery, it'd be a minor headache - I'd resort to something like this:
        sub calculate_area { unless ( grep { ref $_ ne 'Pair' } @_ ) { goto \&_calculate_area_pairs; } if (@_ % 2 == 0 and not ref $_[0]) { goto \&_calculate_area_x_list_y_list; } unless ( grep { ref $_ ne 'Point' } @_ ) { goto \&_calculate_area_list_of_points; } unless ( grep { ref $_ ne 'ARRAY' } @_ ) { goto \&_calculate_area_list_of_arrays; } if (UNIVERSAL::isa($_[0], 'Shape')) { goto \&_calculate_area_share; } if (UNIVERSAL::isa($_[0], 'Equation') and @_ == 3) { goto \&_calculate_area_equation; } die "Didn't recognise how you called calculate_area"; }
        And then I'd implement each possibility in a separate function. The interface is simple, and very perlish (DWIM's very well - and can add more DWIMmery later). The code is ugly. MMD handles the ugly part of the code in a very generic manner which means that it only needs to be debugged by the p6 team, not by each developer who wants it. Because I'm quite sure I've got sneaky little bugs in that untested code above.

        For me the definitive "why MMD?" example was one I saw recently in that DSL-in-lisp movie that was making its way around a few blogs a few weeks ago.

        The movie is mostly aimed at showing off lisp's macro abilities, but those to me are pretty old hat - I've been seeing smug lisp weenies praise macros for years - but along the way the programmer casually uses MMD where in perl I'd have to use a bunch of cascading if/elsif blocks or at best a dispatch table. It's not a huge difference, but having seen it in action, it's something I want. Not need, necessarily, but want in the way I really-want-but-can't-quite-justify a new desktop. (It's been a few years; on the other hand, there are other bills that must get paid...)

        Think of MMD as yet another way for the language to get out of your way when expressing the solution to a problem.

        -- @/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/; map{y/X_/\n /;print}map{pop@$_}@/for@/