Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Re: Re (tilly) 2: Paradigm Shift - Dual Use Constructors

by demerphq (Chancellor)
on Nov 13, 2001 at 23:51 UTC ( #125127=note: print w/replies, xml ) Need Help??

in reply to Re (tilly) 2: Paradigm Shift - Dual Use Constructors
in thread Paradigm Shift - Don't use strict

Tilly perhaps ive missed your point, but you seem to be doing the same thing as merlyn. You are trying to apply OO models from various languages to Perl. OO is a simple idea: the strong association or binding of procedures with the data that they manipulate. Everything else in OO is an extension of this simple concept. Now many languages embraced this idea and as mathematicians (think i)and computer science types often do extended the idea to its logical limits, or beyond in some cases, to see what the implications, pros cons etc of such systems.

But these ideas (prototypes, inheritance, polymorhism, overloading....) are just additional concepts that have been added (or not depending on the language) because of the interests, predilictions and whathaveyou of the various authors and users of the various languages. The fact that they are often useful or desirable features of a language does not mean that they are necessary, much less right.

Im happy that you prefer smalltalks OO model, and even happier that perl provides what is necessary to emulate it. But not because I like the smalltalk model but because I like the perl model, where I can do all kinds of things, only a few of which are considered to be standard OO techniques.

Now as I said, I have come to agree with merlyns point, but not for any of the reasons he provided (which were, to be blunt, crap). You said: The blind repetition of programming patterns that you have not thought about and do not understand. Well Im sorry but to me that is exaclty what merlyns statement about marking people down whenever he saw the construct is. The blind application of a rule of thumb without trying to understand why it was done. For instance I have written a number of GA implementations in perl (unpublished sofar). Now I have a class GA::Entity in my model. This class is used to represent a solution in the GA. When I call GA::Entity->new() it returns a randomly generated solution. When I call $ga_entity->new() it produces a randomly mutated version of $ga_entity, and when I call $ga_entity->new($other_ga_entity) it returns a cross of the two. I thought long and hard if I wanted this type of behaviour and experimented with a number of alternatives before deciding I was happy with this approach. But of course merlyn would mark me down bigtime without considering why I had done it, and what my reasons were. And that my friend is plain and simple Cargo Cult Programming.

Now, Ill grant that if merlyn had said something like "Well, generally I dont think this is a good idea. If I saw this in a code review I would want to see good justification for doing it, and a healthy amount of documentation to explain what is going on" or something to that effect then my attitude would be very different. Also I will grant that if the users of this construct are as you allege unaware of the issues related to it, then indeed it is cargo cult programming as well, but this doesnt change the fact that merlyns comments are too.

I think you might want to reread my sarcastic comment about hungarian. I was trying to come up with the equivelent of a perl guru advocating the use of hungarian in perl.

As for the C/Context point, I dont agree. To me there is little or no difference between someone who has experienced a (different) concept or not experienced the concept at all in a given langauge demanding that a second language behave the same way. That quite possibly is why they are different languages.

Your last sentence is to me the key here, Their opinions might be wrong for Perl, but they at least have an experience base which is somewhat relevant, yes their opinions are relevant but not necessarily correct. And that is exactly what I think of merlyns post. Relevent and wrong.

Yves / DeMerphq
Have you registered your Name Space?

Replies are listed 'Best First'.
Re (tilly) 4: Paradigm Shift - Dual Use Constructors
by tilly (Archbishop) on Nov 16, 2001 at 22:08 UTC
    I disagree on whether merlyn's comments on this topic are Cargo-Cult programming. To say that it is is to say that this is a topic that he, has not thought about and does not understand.

    To the contrary, merlyn has done OO programming for 20 years, and has done OO programming in Perl for as long as Perl has had support for it. In that time he has seen many different approaches to OO programming, in quite a few languages, and has developed strong opinions on the subject. I would be very, very wary about claiming that he has not thought about the relevant issues, or claiming that he doesn't understand OO programming in Perl.

    Now Perl's OO is, you claim, a simple idea. Not so fast. Perl's OO is a simple implementation of a fundamental concept. The fundamental concept behind OO programming is that it provides support for modelling your programming universe, and then later using that model to find good solutions for your problems. The implementation in Perl is simple partly because other features in Perl make it easy to do whatever you want. The amount of OO specific flexibility that needs to be added is little, but the OO model you get is more complex. And the potential OO models are even more complex.

    So back to what OO is. I claimed that OO is about ways of creating conceptual models and then working with that. The key idea is indeed to create "things" that you can interact with. The things contain internal data, and are bound to methods. The modelling tools that you use to create your models of the things vary, but modelling is the job.

    Now if you are going to be modelling, then it is important to think about what kinds of models you want and why. And part of that is your model of what the relationship is between a class and an object in that class. merlyn's point, and mine, is that when you use the ref || $proto trick, what you are really doing is making it possible to confuse the object and the class. As I, and merlyn, point out, this confusion will only work partway. While sometimes the effect can be useful, most of the time the model is misleading.

    Which is why I say that most of the time you should either not do that, or else you should go the rest of the way. I am not saying that you should program Perl like it was Smalltalk. I am saying that to whatever extent possible you should encourage clear mental models of your classes. Don't reflexively type in an idiom because you have seen it. Stop, think about whether it is what you want, and then conciously choose whether you want it.

    Now to address a fundamental issue. While it is true that when merlyn is hired to do a code review, he flags that item, my experience is that this is a provisional opinion. If you point out why you did it, and have a reason, he has no trouble going, "OK, you know what you are doing" and takes back what he said. It is like strict. Most of the time it is a danger flag. But sometimes, based on what the code is doing, strict really can't be used. The rule that is true 95% of the time isn't always true.

    For instance take a look at Re (tilly) 1: Nested Classes for an example where I used the ref||$proto idiom. As I commented in the code, it wasn't Cargo-cult. And merlyn sent me a private note about that when he says that he only minds seeing that construct in the code of people who don't really understand what is going on. But he says that in that code he would not have flagged it.

    And a final few corrections. First of all I think that other languages can do a lot more with OO than you give them credit for. Secondly mathematicians do not do anything particular with OO, in fact most do not even know what the heck it is. And finally given my background, I am far more likely to see other languages through Perl tinged glasses than vice versa...

Re: Re: Re (tilly) 2: Paradigm Shift - Dual Use Constructors
by Matts (Deacon) on Feb 20, 2002 at 08:01 UTC
    When I call GA::Entity->new() it returns a randomly generated solution. When I call $ga_entity->new() it produces a randomly mutated version of $ga_entity, and when I call $ga_entity->new($other_ga_entity) it returns a cross of the two. I thought long and hard if I wanted this type of behaviour and experimented with a number of alternatives before deciding I was happy with this approach. But of course merlyn would mark me down bigtime without considering why I had done it, and what my reasons were.

    I fail to see how someone would mark you down on this, because you wouldn't have the traditional my $class = ref($proto) || $proto, you would have something much more complex wrapped around:

    if (ref($proto)) { if (ref($_[0])) { cross polinate } else { mutate } } else { construct new }
    Which would look far more reasonable in a code review, and would almost inevitably have to be documented. So I don't buy your argument.
      Hmm. Interesting angle. But ircc (its on my home computer) the code went more like
      sub new { my $proto=shift; my $class=$proto || ref $proto; my $self=bless {},$class; if ($class eq $proto) { #class call $self->init_rand(); } elsif (@_) { $self->init_cross($proto,shift); } else { $self->init_mutate($proto); } return $self }
      So the dreaded line was/is present. But you are correct I did/would comment this.

      Yves / DeMerphq
      When to use Prototypes?

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2021-10-21 21:10 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (85 votes). Check out past polls.