Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re (tilly) 1: OO Perl: calling a constructor within a class

by tilly (Archbishop)
on Sep 26, 2001 at 16:35 UTC ( #114793=note: print w/replies, xml ) Need Help??

in reply to OO Perl: calling a constructor within a class

I differ in my tastes from davorg. Instead I, like merlyn, prefer to keep instance and class methods separate. His opinion is stated more strongly than mine would be, but I would still make new your basic constructor, give your complex constructor from an existing object a more descriptive name, then just call new from within the more complex constructor. Something like this silly little example:
sub copy { my $self = shift; my $copy = ref($self)->new(%$self, @_); # Do stuff return $copy; } sub new { my $class = shift; return bless ({ NAME => '', USERNAME => '', # etc @_ # allows overriding defaults in the constructor :-) }, $class); }

Replies are listed 'Best First'.
Re: Re (tilly) 1: OO Perl: calling a constructor within a class
by perrin (Chancellor) on Sep 26, 2001 at 17:46 UTC
    I'm with merlyn -- ref($proto) || $proto is total cargo cult. I've never seen anyone actually use it to call new() as an instance method.
      I actually have seen people do it. But not often enough for it to be worthwhile in most circumstances.

      For the record it does serve a purpose. That purpose is to make Perl's OO look like it is prototyped-based. Depending on what language you first saw OO in, doing otherwise may feel unnatural.

      Before people who don't know what I am talking about go, "Huh?", let me explain.

      Suppose for a second that I had a class named Cat, a subclass named Cat::Siamese, and specific siamese cat named $meows_loudly. At this point you likely have a reasonable picture of what $meows_loudly looks like, and can probably make an educated guess as to what she sounds like. Now where do you get that picture from?

      Well if you are like most people you have a model of what a Cat::Siamese should be like. This model you have is probably based on a few cats you have met in the past. But does this model exist? Well, perhaps. It certainly isn't a walking, breathing cat (the abstract model, not the one sitting in your lap modelling right now) but philosophers can argue endlessly over whether the idea is a real thing in and of itself.

      But hey, what if we are talking about a programming language? Remember that programs don't have walking, breathing, cats. Programs have a different sense of what it means for things to exist. In a programing language we can identify the bits that make up $meowser, and we also have implemented the class Cat::Siamese. Given that the class has an implementation in the computer, it is as real as anything else there, so Cat::Siamese really exists. In fact in any self-respecting OO language (which Perl is not) it is going to be an object. But, to keep the philosophers happy, we get a new question! Namely, is Cat::Siamese a Cat?

      Now in real life there is no question. The idea Cat::Siamese is an idea. We established that it isn't truly a Cat. However computer languages are not the real world, they are human models. And in case you didn't notice, a human model of Cat::Siamese is pretty much always based on some real breathing cat. So to cut off the philosopher's fun, the answer to the question about whether or not Cat::Siamese is a Cat is, "It depends on the language."

      But the philosophers get the last laugh after all. Some people prefer to have an actual prototypical Cat that they call Cat::Siamese, and so like languages where Cat::Siamese is a real cat with methods like meow. The classic language that takes this approach is Self. The alternative approach is to make things like Cat and Cat::Siamese Objects of class Class. Cat::Siamese is not a Cat, and to treat it like one is to indicate fundamental confusion about the nature of the universe. The classic paragon of this approach is Smalltalk.

      Now where does Perl stand? Well it is a functional hodgepodge with no conceptual clarity. In Perl a Class is actually a string that names a package that has stuff implemented in it. There is no way that "Cat::Siamese" is an object inheriting from Cat. But on the other hand if you are going to make $meows_loudly able to meow, then Perl will let people ask Cat::Siamese to meow. It might not work. Certainly I would be inclined to expect that asking Cat::Siamese to meow will run into trouble when you ask how it should meow. (A question I hope will arise, else $meows_loudly is horribly misnamed.)

      So how should a programmer handle it? Well we tend to make things look familiar. People whose first exposure to OO was to a prototype based language like C++ will often try to make Perl work like a prototype based language does. And they can get half-way with the ref($proto)||$proto trick. Now $meows_loudly will serve perfectly well as a substitute for Cat::Siamese (1). People whose model of OO says that classes and instances of a class are unrelated kinds of things see that as a horrible mistake. They prefer to try to ignore the fact that you *can* call class and instance methods on both the cats and the instance, and then make it obvious that something is wrong by letting it break when you do the wrong thing.

      (1) And when you consider the effect of calling new on $meows_loudly, perhaps you see why I called her a "she"? The male doesn't really enter the picture, but that isn't too unusual for cats. The litter is kind of small though...

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2022-12-07 21:04 GMT
Find Nodes?
    Voting Booth?

    No recent polls found