Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Re: Re: Re: Why breaking can() is acceptable

by tilly (Archbishop)
on Apr 06, 2004 at 05:30 UTC ( [id://342839]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Re: Why breaking can() is acceptable
in thread Why breaking can() is acceptable

With your code snippet, if someone has an object of your class (or a class that inherits from your class) and wants to know if you can foo, where it can foo because of your AUTOLOAD, then your can will say that it can't foo because the person calling can is not making that call from within your class.

Again, this is not as easy as it looks.

Furthermore allow me to point out that AUTOLOAD predates can by many years, and is far more widely used. Is code that was written before they decided to start populating UNIVERSAL:: in Perl 5.004 broken because Perl 5.004 came out? Does code written by someone familiar with Camel ed. 2 need to be rethunk because p5p decided that people might like to have a feature that most people don't use?

My belief is that p5p adding to Perl should not invalidate accepted practices. My further belief is that of AUTOLOAD and can, AUTOLOAD matters more to most Perl developers. Going further, my impression is that people who are familiar with other dynamic languages are more likely to want to reach for something like AUTOLOAD (perhaps they'll call it method_missing, but they expect it to be there) than they will can.

My conclusion, therefore, is that someone who wants developers to not break can with AUTOLOAD is fighting an uphill battle. Furthermore, knowing everything that I do, my sympathies are with the person who wants to use AUTOLOAD to full effect. (Though admittedly I'm more likely to creating a bunch of functions by typeglobbing some closures rather than use AUTOLOAD. Unless I have a reason to use AUTOLOAD.)

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Why breaking can() is acceptable
by stvn (Monsignor) on Apr 06, 2004 at 06:04 UTC
    With your code snippet, if someone has an object of your class (or a class that inherits from your class) and wants to know if you can foo, where it can foo because of your AUTOLOAD, then your can will say that it can't foo because the person calling can is not making that call from within your class

    LOL, you are right, I updated the code to reflect my dumb mistake. Once again, waaaay past my bedtime.

    As for how it might affect subclasses (and please note I specifically did not handle subclasses in the code). It is your responsibilty when subclassing to take care of stuff like this. Sure that might be a little to "white-box" for some, but again, if you are using AUTOLOAD in the presence of inheritance, you are already in trouble, so you should expect to get your hands dirty.

    My belief is that p5p adding to Perl should not invalidate accepted practices. My further belief is that of AUTOLOAD and can, AUTOLOAD matters more to most Perl developers.
    This may be so, but again I dont like it much, so I am biased. No matter how old AUTOLOAD is though, I am wary of using it too much with inheritance, to me it just sounds like a bad idea. But again, these are my opinions, nothing more.
    Going further, my impression is that people who are familiar with other dynamic languages are more likely to want to reach for something like AUTOLOAD (perhaps they'll call it method_missing, but they expect it to be there) than they will can.
    I dont know if i agree with this, I can see where AUTOLOAD can be a nice tool, but I wonder if you are not restricting your view of can too much. In alot of ways they are similar, can being just a more manual approach. I think people who might be comfortable with using class reflection would be more likely to go for can, where as those more familiar with run-time code generation would reach for AUTOLOAD. Both are common aspects of dynamic languages though.
    My conclusion, therefore, is that someone who wants developers to not break can with AUTOLOAD is fighting an uphill battle.
    Alot of this depends upon in what context this is all being used/implemented, we are debating a wide open field here. But I do not think it is unreasonable to expect that can is not broken in an OO module. IMO, one should not play lightly with AUTOLOAD and objects. More imperative-style modules is another story, which I would guess (although I dont know) is the more common usage of AUTOLOAD historically.

    -stvn
      Going further, my impression is that people who are familiar with other dynamic languages are more likely to want to reach for something like AUTOLOAD (perhaps they'll call it method_missing, but they expect it to be there) than they will can.
      I dont know if i agree with this, I can see where AUTOLOAD can be a nice tool, but I wonder if you are not restricting your view of can too much. In alot of ways they are similar, can being just a more manual approach. I think people who might be comfortable with using class reflection would be more likely to go for can, where as those more familiar with run-time code generation would reach for AUTOLOAD. Both are common aspects of dynamic languages though.
      I think that you hit it in this paragraph. My background/interest is definitely for run-time code generation of various kinds. Class reflection is simply not really to my taste.

      That would make me more aware of the equivalents of AUTOLOAD in other languages, aware of its uses, and inclined towards caring more about it than class reflection.

      For me OO is a tool, not an ideal. You can feel free to apply pejorative terms to me for what results from that attitude, but insults won't rearrange my priorities. If I feel inclined to use an AUTOLOAD, and I think that in the situation where I'm using it, it is justified (which is in actuality rather rare), then I'll use it and not be bothered overly much if I leave can broken. (Unless I'm working in a code base where can is already in use, in which case that fact would factor into my decision about whether to use AUTOLOAD.)

      I don't think that that is wrong, nor do I think that I'm alone. I'll admit, though, that most people who fundamentally agree with me haven't necessarily thought the matter out as much as I have. Then again I don't think that most who disagree have thought about it that much either.

      Incidentally where I have seen AUTOLOAD most commonly used with objects is in a base class. All classes which inherit are supposed to play nice with the AUTOLOAD, and there are no other AUTOLOADs in the class hierarchy. An example of what that AUTOLOAD might do could include autogenerating a standard basic interface, including a list of accessor methods. (That would be where I'm inclined to typeglob closures instead.)

        For me OO is a tool, not an ideal. You can feel free to apply pejorative terms to me for what results from that attitude, but insults won't rearrange my priorities.
        Good code is good code, when I do code reviews that is all i care about. The paradigm used is irrelevant. I personally prefer OO, it lends itself to the way my mind works. But I also love functional and declarative programming, to me they are fascinating and elegant, but short of "declarative" SQL, I don't get to do them much at work.
        If I feel inclined to use an AUTOLOAD, and I think that in the situation where I'm using it, it is justified (which is in actuality rather rare), then I'll use it and not be bothered overly much if I leave can broken.
        I agree, I see AUTOLOAD much like source filters. A really cool and interesting tool, but one that should not be used lightly, and only in the hands of someone who really knows what they are doing. As for leaving can broken, if it is your code its your perogative. If you are releasing it to the public I would argue you shouldn't, but you still dont have to agree with me :) so again, your code, your choice (although I would be inclined to write you a patch just to mess with you).
        I'll admit, though, that most people who fundamentally agree with me haven't necessarily thought the matter out as much as I have. Then again I don't think that most who disagree have thought about it that much either.
        This my friend, is where you have hit the nail on the head. Too many people don't think these things through thoroughly. But then again too many people don't test thoroughly either.

        -stvn

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2024-03-29 02:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found