Re: Re: OO-style modifiers for 'sub' ?

[Gilimanjaro]

Good question... :)

I guess I'm trying to make my code (modules) easier to use for both myself and others; if the the method is used incorrectly, and the program when runs tells me 'hey don't do that, you should use me in this and that way' it would cut down substantially on my debugging hours...

But it's quite true that as soon as your code works, the whole checking becomes quite useless...

Invoking the methods would still work exactly the same way, but if the 'modifiers' indicate that the method 'expects' a certain kind of first argument (be it class, object or either), the method could check to see if that's ok, and if not, croak.

Almost every way of using the methods would still work. The only thing that might not, would be 'borrowing' methods from other modules/classes without using inheritancy. But I can't help feeling that doing something like that indicates a design flaw anyway...

So yes, I would like to have the option to have Perl behave a bit like some other language... But then again, aren't most good things based in part on a collection of other good things? If I remember correctly, Larry was using sed and awk, but needed more... So he invented Perl and borrowed a bunch of the functionality from those tools amongst others. Which is great! I love it!

It's not like I'm saying "Hey Perl should change, and everyone should do this!"... But traversing @ISA, and the UNIVERSAL class seem to be considered standard perl, and you are allowed, not obliged to use them... I would think being allowed (but not obliged) to use features such as the modifiers I suggested would further extend the freedom a Perl programmer has to build 'mean & clean' OO code...

Everyone seems to be asking "Why do you want to be able to do this?"... Well, I would ask "Why would you not want to be able to do this?". Right now I'm doing it manually anyway... :)

So either I'm just not getting what the 'evilness' is in my idea (even though I read every reply at least twice), or I just don't agree... :)

[trs80]

I don't think your idea is evil in anyway. I like Perl because it is flexible and it lets you do what you want and assumes you know what you are doing.

I can see where doing the type of checking you are talking about could limit your debugging time. That time savings would be increased as the number of developers having to interact with new code increases. Not knowing the coding environment it is difficult for anyone say if all the checks are really needed in the long run. It might be nice to be able to put the checks into their own method or function that could be overridden via configration variables, that is bypass the tests entirely under certain conditions.

Another module that you might want to check out is Params::Validate.

[Gilimanjaro]

Bunch of good points!

The environment I'm building the code for is one where about five or six people will end up using my code, and maybe expanding it... I figured doing these kind of checks and giving some solid feedback about errors would make the modules & methods easier to handle.

I think I know pretty much what I'm doing, so I like the flexibility. I can't vouch for the experience the people that will use the code have, so that's why I'd like to do some checking...

I like your idea of being able to bypass the checks a lot; the development environment would always use the checks, but the production environment wouldn't, speeding up the application. In that context, it may be an idea to build a module to set up wrappers (maybe using the sub wrapping module Aristotle suggested), which do the checking. It could then be enabled by a single use statement with a list of method names as a parameter...

I can't wait to start tinkering! But sleep comes first... :)

[jeffa]

I am with the camp of "this is a waste of my time." Why? Because this is Perl, not Java. If i want someone to use my API correctly, i give them proper documentation. Yes, i suppose that nice friendly error messages would be nice ... but, the more Perl you program, the better you get at debugging.

"as soon as your code works, the whole checking becomes quite useless..."

That's right. The same goes for when you decide to change your design. Now you have extra baggage that you have to take care of to make sure that your 'bondage and discipline' code still works. No thanks. I'll gladly just make sure that my documentation is up to date.
So, are you wasting your time by doing this? Of course not ... i am glad to you see trying to further your own knowledge of application design and OO in general. What i am saying is that i have been programming OO Perl for 2 years now (Java for 2 before that) and my applications do not suffer from any symptoms that you think might arrise from using my API wrong. It's really quite simple, if it is a circle, don't put a square in it - put a circle in it. If i really really really wanted something else, i'd be spending my days programming Java. This is Perl after all ...

One more thing: (bold type added by me)

"The only thing that might not, would be 'borrowing' methods from other modules/classes without using inheritancy. But I can't help feeling that doing something like that indicates a design flaw anyway..."

Keep in mind that some think that using only inheritance is a design flaw ... OO newbies are always in a rush to solve every problem with inheritance and forget to consider aggregation.

So, in closing - you asked "why would you not to be able to do this?" My answer - it's a waste of my time. It's (as dragonchild says) "borrowing trouble." But, please continue -- don't stop just because i think it is silly. After all, someone wrote Attribute::Handlers and Hook::WrapSub, so you aren't alone on this one. ;)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

[Aristotle]

After all, someone wrote Attribute::Handlers and Hook::WrapSub, so you aren't alone on this one.

You realize, of course, that these modules can be used for a huge range of things far beyond introducing BDSM OO to Perl, don't you. :) For an example, see adrianh's Class::InsideOut - yet another riff on inside out objects..

Makeshifts last the longest.

[adrianh]

Everyone seems to be asking "Why do you want to be able to do this?"... Well, I would ask "Why would you not want to be able to do this?". Right now I'm doing it manually anyway... :)

Obviously, if you find it useful carry on doing it - I certainly don't think it's evil :-)

However, if I was working in a team where people were regularly calling methods as Class::method($self) rather than $self->method I would immediately stop and spend some time teaching them some more about how perl works. The two are not equivalent, and using the former to call OO code is almost always a bad idea.

Class::method($self) calls a subroutine method in package Class, and passes $self as the first argument.

$self->method looks at the package $self is blessed into, uses this to find method in the inheritance hierarchy and execute it, passing $self as the first argument. Perl also keep enough context around so that we can call SUPER:: in method if necessary.

By calling Class::method($self) we are:

• explicitly breaking encapsulation by saying that method is implemented in package Class - setting yourself up for future problems if you push the method into another class during refactoring.
• not treating $self as an object

To me this is the moral equivalent in perl of, for example, doing pointer arithmetic to find a slot in a C++ object. Protecting against this kind of inappropriate usage is best done by educating developers (or hiring new ones), rather than by adding extra code.

I don't worry about it in the same way I don't worry about people using Data::Dumper to get at my objects state. If somebody is that foolish they deserve all they get :-)

I will happily argue for checking of method arguments - since this can make design decisions explicit. However, for me, calling object methods as methods, rather than subroutines, is a matter of correct use of perl and shouldn't need explicit checks.