Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday January 13, 2009
12:36 PM

Discuss the Pros and Cons

[ #38276 ]

This:

sub concrete_classes {
    my $self = shift;
    return grep { ! ( /::Base::/ || /::SUPER$/ ) } $self->domain_classes;
}

Or this:

sub concrete_classes {
    my $self = shift;
    return grep { not $_->is_abstract } $self->domain_classes;
}

Which of those would you choose and why? Are there arguments for the other? What are the downsides of the "wrong" choice? Would you do something entirely different (tough to know with so little info)? I've already got my opinion, but just want to hear your point of view in case I've missed something obvious.

Update: Fixed a couple of typos which were pointed out.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I suspect you mean $_->is_abstract and not $self->is_abstract. Beyond that I think I need to know more of the context in which this is used.

    - Stevan

    • Also I think he needs the opening '(' for { ! ( /::BASE::/ || /::SUPER$/ ) }.

    • Each method attempts to do the the same thing: return a list of non-abstract classes. The first method inspects class names and uses a heuristic to find out if they're abstract classes. The second method asks the classes if they're abstract classes. How this is used could vary, obviously. As an abstraction, there are any number of reasons why you might want a list of non-abstract classes.

  • The second option is probably more maintainable, especially if is_abstract is implemented in some common base class somewhere. If you've got grep's like that peppered throughout your code for some reason, even more so. If you don't, then it might not make sense to add that level of abstraction.
  • That would require that you never have a concrete class inheriting from another concrete class, which feels like a very bad thing to bake in.

    Of course, I don't know how those ::SUPERs get in there. It's possible they can only arise when the class is already known to be abstract; but that just makes the whole thing even more obscure.

    So, the second :). I would probably want the is_abstract method to be a sprinkling of sub is_abstract { 1 } and { 0 }s rather than simply that expression, as well.

  • Well that probably depends on a whole lot of things that aren't evident from the examples or your description.

    So I have no clue.

    • Why not:

        return grep { $_->can('new') } $self->domain_classes;

      Also, it's somewhat silly to use the word "class" for something that's not a class. (An abstract class is not a class.) When you think "abstract class" and you are a Perl programmer, you really want roles.