http://www.perlmonks.org?node_id=321120

I've reached the point where I'd rather use MethodMaker (or something similar) to write classes, as opposed to writing them from scratch. I think I would have arrived here sooner if MethodMaker was part of the core distribution.

This makes me wonder why Class::Struct is standard but MethodMaker is not ??

Update:After further meditation, I realise that there are many Class automators on CPAN; although I feel that this issue is important enough to be addressed by a core module, putting any one of these in the core would be unfair to all the others (its hard enough to chose one for personal use). Thank you all for sharing your thoughts.

Replies are listed 'Best First'.
Re: Class automators should be standard
by ysth (Canon) on Jan 13, 2004 at 22:11 UTC
    standard ne included in core

    Much of what is in the core should be regarded as historical accident.

    There is great sentiment toward a much leaner core distribution, so you may see Class::Struct booted out of the core at some point. (Though there will probably still be bloated distributions available.)

[reply]
Re: Class automators should be standard
by hardburn (Abbot) on Jan 13, 2004 at 22:23 UTC

    No. While I'm not going to say using MethodMaker is always bad, it would encourage those new to OOP to design sloppy objects (such as accessors and mutators on every attribute). Further, it only teaches you one aspect of Perl OOP. There are already too many people who limit themselves to bless alone, and with MethodMaker, they wouldn't even learn that much.

    If you happen to like MethodMaker, know how bless works already, and already understand why you should limit the use of accessors/mutators, then go ahead and use MethodMaker. I just don't want coders encouraged into bad practices too soon. There's quite enough of that as it is.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]
[select]

      Arunbear asked how you do OOP in Perl without bless; I'd much rather know why you think it is important to know how to do that.

      Update: looks like hardburn already answered the question.

      [Jon]

[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Class automators should be standard
by rkg (Hermit) on Jan 14, 2004 at 03:46 UTC
    One thing I find troubling about MethodMaker is often my class setter/getters change object state beyond that attribute. There's probably a name for this, but I don't know it.

    For example, suppose you have a car object, with attributes of  accelerator_setting,  gas_in_tank,  velocity, etc.

    You can get or set the accelerator, but doing so should change the velocity and available gas.

    If you use MethodMaker to automagically make getters and setters, the resulting get/set methods are bare-bones basic. And if bare-bones basic isn't what you want, so you need to subclass or rewrite these methods (so that, in this case, pressing the accelerator moves the accelerator and also increases speed and decreases gas), then why use C:MM to create them?

    (And imho I don't the appearance of a class which uses C:MM for some getter/setter methods but hand-rolls others... just doesn't fit my code aesthetic.)

    Perhaps I am missing something, but that's my problem with automatic method makers. The OO examples in the docs always use independent attributes like name, rank, serial number -- and promoting a solider doesn't change his or her name or number.

    The easy stuff is great for C:MM, but not all objects are so simple.

    rkg

[reply]
[d/l]
[select]

      (And imho I don't the appearance of a class which uses C:MM for some getter/setter methods but hand-rolls others... just doesn't fit my code aesthetic.)

      It fits my code aesthetic; in fact, I think it is very attractive. But even if I didn't, I would continue to mix C:MM and hand-rolled code because of this lazy principle:

      If it is simple and/or repetitive, the computer should do it.

      Do you think that the principle itself is ugly, or just the "C:MM with hand-rolled code" implementation of the principle?

      I think the following is a great example of C:MM, due to my liberal application of the hubris virtue. ;-)

      use Business::Shipping::CustomMethodMaker
    new_with_init => 'new',
    new_hash_init => 'hash_init',
    boolean => [
        'update',
        'download',
        'unzip', 
        'convert',
        'is_from_west_coast',
    ],
    hash => [ 'zone' ],
    grouped_fields_inherit => [
        optional => [ 
            'zone_file', 
            'zone_name',
        ],
        required => [
            'from_state',
        ],
    ];

      [download]

      The above would take a lot of coding to represent manually. You can see simple methods, and slightly-less-simple methods (like the required() and optional() methods, which automatically call parent methods and concatenate the results to their own). (Note that the above is using a sub-classed version of C:MM, taken from the Business::Shipping project.)

      While I'm on the subject, I think it would be great if Java had something like C:MM, but the closest you can get is those code-generators that run just before compile.

      As far as the topic's original question, I wouldn't mind if all or none of the OO modules were in the core. Newbies can continue to find the ones they like by reading the OO docs. (Damian Conway's book was my initiation to the Perl OO world.) Which makes me wonder, is there an "OO Perl Module Survey" doc somewhere that is updated when new OO modules come out?

      -Dan

[reply]
[d/l]
        Ok, I'l agree with your point about making the computer do the boring repetitive stuff.

        But back to my question:

        How do you handle getter/setters when the attributes interact? In your shipping example, what would keep me from (assuming I understand the methods correctly) setting  from_state to Massachusetts and is_from_west_coast to TRUE? Shouldn't setting the state cause the west coast flag to flip on or off as appropriate?

        A handrolled get/set could enforce all these things; doesn't C:MM fall short here?

        I am not C:MM bashing; I use it and am a fan; I just haven't figured out how to handle interrelated attribs yet.

        Thanks for your comments

        rkg

[reply]
[d/l]
[select]

Back to Meditations