Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: A few Perl OOP questions.

by Zaxo (Archbishop)
on Oct 20, 2003 at 05:25 UTC ( #300476=note: print w/ replies, xml ) Need Help??


in reply to A few Perl OOP questions.

my $class = ref( $type ) || $type;

That sets $class to the string returned from ref. If that return is false ($type is not a reference), $class is set to the value of $type. That code is used to intuit a class name from an instance of the class, so a class method many be called as if it were an instance method. That is an idiom which is disparaged these days as too admissive of bugs.

$self->{ hireDay }->setDate( @_ );

$self is a reference to a hash. Its 'hireDay' key contains an object with an instance method called setDate. That method is called with the current argument array.

my $self = $class->SUPER::new();
$self is make to be an instance of the first parent class having a new() class method. It$self will likely soon be re-blessed into $class, perhaps with some additional initialization.

After Compline,
Zaxo


Comment on Re: A few Perl OOP questions.
Select or Download Code
Re: Re: A few Perl OOP questions.
by dragonchild (Archbishop) on Oct 20, 2003 at 13:17 UTC
    $self is make to be an instance of the first parent class having a new() class method. It$self will likely soon be re-blessed into $class, perhaps with some additional initialization.

    I don't think this is correct. Try the following:

    package Foo; sub new { my $class = shift; print "In Foo with '$class'\n"; return bless {}, $class; } package Bar; @ISA = qw(Foo); sub new { my $class = shift; my $self = $class->SUPER::new; print "In Bar with a self of '$self'\n"; return $self; }

    Now, I'm assuming that all classes in this hierarchy are using the two-arg form of bless. If they are, then $class will be passed around and it will be the child class.

    ------
    We are the carpenters and bricklayers of the Information Age.

    The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

    ... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      You're right. The delegated call still gets the child's class name as its first argument. Further initialization remains likely.

      After Compline,
      Zaxo

Re^2: A few Perl OOP questions. (disparaging)
by tye (Cardinal) on Oct 22, 2003 at 20:50 UTC
    my $class = ref( $type ) || $type;
    [...]That is an idiom which is disparaged these days as too admissive of bugs.

    It is disparaged by some people. I've repeatedly criticized people for disparaging it without specifying what one should replace it with. I find the most obvious way of not using it to be too likely to produce way-too-confusing errors:

    package Purified::Confusion; sub new { # my $proto = shift(@_); # my $class = ref($proto) || $proto; # To restore sanity, replace the line below # with the above two commented lines. my $class = shift(@_); bless [@_], $class; } sub get { my $self = shift(@_); return @$self if ! @_; return @{$self}[@_]; } 1;
    and
    #!/usr/bin/perl -w use strict; use Purified::Confusion; my $one= Purified::Confusion->new('a'); print $one->get(), $/; # A quite common idiom in Perl code # which produces no errors nor warnings: my $two= $one->new('b'); # ...but that produces not at all what is desired, # if the module author heeded the FUD; as we see here: print $two->get(), $/;
    produces the following output:
    a Can't locate object method "get" via package "Purified::Confusion=ARRA +Y(0x182f0d0)" at confusion.pl line 13.
    which I'll bet would confuse the vast majority of module users.

    If you are going to spread Cargo Cult FUD about

    my $class = ref( $proto ) || $proto;
    then at least take the responsibility to tell people what you suggest they replace it with! Perhaps even keep handy a link to a discussion of both sides of the controversy.

    I have my own techniques for avoiding such problems when I feel it is appropriate (usually by having my class and instance methods in different name spaces) which are way too much trouble to be the default idiom for writing OO Perl. So I advocate people follow this fine example found in the standard Perl documentation until such time as they feel the desire/need to move to more advanced techniques that can properly address class/instance method collisions without introducing such horridly confusing possibilities.

                    - tye

      I think the reason for disparaging that idiom has nothing to do with gifts from absent gods or monopolistic marketing practices. The reason is the idiom indicates an OO design flaw.

      The objection is one of OO principle - that class methods and instance methods should be distinct and disjoint. Instance methods deal with the state of a particular object. Class methods deal with class-wide state or instance construction.

      Your example is a common idiom only because it's one way ref($foo) || $foo methods are called. If it's necessary to intuit $one's class, why not say so by writing my $two = ref($one)->new('b');

      There is a borderline case - copy constructors. It is tempting to be able to write my $two = $one->new();
      for a deep copy of $one. Reflection on how much different that operation that is from construction with a parameter list suggests that a separate copy ctor is advisable, my $two = $one->clone();
      , an instance method. That could be written as a class method, my $two = Purified::Confusion->new($one);
      , but that would make for an unnecessarily complicated constructor.

      Tye, I thought you disliked cries of "Cargo Cult!" ;-)

      After Compline,
      Zaxo

        Yes, I understand all of that. I don't see you say a single thing about my points. *shrug*

        I know quite well why some people don't like it. I can see their points on some levels but mostly don't see those arguments as a big deal in many cases. I can also see the (contrary) point of making life easy for the module user. Most of the time, when given a concrete example of $obj->new() being supported by a real module, I have no confusion about what is going on. In theory, it can be confusing. In practice, it often just makes good sense.

        Your node really does have the ring of FUD to me. "class methods and instance methods should be distinct and disjoint" Why? Because someone says so? Perl certainly doesn't think so -- not in the least. I don't even see you doing it. I'm sure its a nice principle with plenty of validity behind it. I even, at times, follow it more in my own OO code than I've seen done in most any other Perl OO code I've read.

        BTW, you forgot to not name your constructor "new". Also a valid (and similar) point, especially in theory, that often doesn't cause the slightest problem in so many cases of practice.

        But I'm not here to argue those things (but I threw in a bit mostly cause it was fun). Some feel that way, and I can understand their points and agree with most of them to some degree. But I just haven't seen any of the complainers bothering to notice the consequences of their banishment of this idiom.

        "Cargo Cult FUD" just had such a nice ring to it. Turnabout is fair play, don't ya know? (: (I love the "think for yourself" or "you didn't think for yourself, because what you wrote is 'cargo cult'" meta argument -- always makes me wonder what is so weak about their argument that they have to resort to it. I couldn't resist, especially the redundancy of adding "Cargo Cult" to "FUD"; it just rolls off the tongue.)

        So, yet again, the FUD mongers refuse to provide a reasonable replacement for the acursed $proto idiom.

        I find it quite rude to be told "don't do this" without any "do this instead" or even the slightest hint of what is mixed about the purported blessing.

                        - tye
      I dislike the idiom because it promotes ambiguous code. The author of  $obj->new(); hides something that the author of  (ref $obj)->new(); tells you.

      Often it makes no real difference and the noise is about who is being forced to write code to accomodate someone else. I try to be more cooperative.

      Usually I would write your new more like this.

      sub new { my $class = shift( @_); croak "Bad class parameter" if not defined $class or ref $class; bless [@_], $class; }
      Which gives a message like:

      Bad class parameter at file.pl line 100

      What is it that you find fine about the idiom?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://300476]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (9)
As of 2014-09-23 22:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (241 votes), past polls