Re^6: Is it ok to mix functional and oo programming in one package?

Be aware. If you don't deliberately arrange the code in a weird order, it works just fine. That is, if your modules are loaded before the code that uses them, as in you have use Your::Module;, or even just ensure that the modules are compiled before the code that uses them, then the problem does not arise:

#!/usr/bin/perl
use warnings;
use strict;

package Foo;

sub new {
    return bless {},shift;
}

sub hello {
    print "hello";
}

package main;

sub new {
    print "haha";
    return;
}

my $a = new Foo;

$a->hello;

__END__
C:\test>junk2
hello
[download]

Just another example of the over-zealous promotion of a rare scenario, that by-the-by, provides clear and unambiguous diagnostics, into a "thou shalt not" that throws the baby out with the bath water. Just another justifiction.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re^6: Is it ok to mix functional and oo programming in one package? Select or Download Code

Replies are listed 'Best First'.
Re^7: Is it ok to mix functional and oo programming in one package? by chromatic (Archbishop) on Oct 19, 2007 at 05:42 UTC
If you don't deliberately arrange the code in a weird order, it works just fine. In larger programs which are not small tests cut down for didactic purposes, do you always know when exactly when everything gets declared? How about in programs that use Module::Pluggable or another extension mechanism? I've debugged this problem more than once. (I've also debugged the `$_` gets localized implicitly except when it doesn't.) Sure, it's not always a problem... but when it is, it's not always as obvious as anyone would like.	[reply] [d/l]
Re^8: Is it ok to mix functional and oo programming in one package? by BrowserUk (Patriarch) on Oct 19, 2007 at 11:30 UTC
...do you always know when exactly when everything gets declared? Generally, yes. The use inevitably appears lexically before, and by general definition is compiled before, any statements that call methods that the used module contains. There are situations, particularly when using require in a thread to avoid cloning, where the loading of the module is deferred, but that is a situation that requires other special considerations--like the explicit invocation of `export()`--that one has to be aware of. How about in programs that use Module::Pluggable or another extension mechanism? I've never had occasion to use that module or anything similar, but looking at the POD it seems that you would always need to obtain a 'handle' to the module first, and using direct method invocation on objects and handles is the natural way to go. There is no bare-word upon which to invoke a class method indirectly. (I've also debugged the $_ gets localized implicitly except when it doesn't.) Kind of a strange aside given the subject matter, but useful. Given that this problem is far more subtle, and unlikely to be detected at compile time much less give a clear diagnostic as you get with most incorrectly parsed indirect method invocations, do you generally advocate always explicitly localising `$_`? I know there are those that eschew all uses of `$_`, but I don't recall you as being one of them. It seems to me that when this problem arises, it is far more insidious, far less likely to produce a clear diagnostic and far harder to debug. So why not advocate: "Thou shalt never rely upon implicit localisation of `$_`?" Not that I would subscribe to it, but it seems like a far stronger candidate to me. In general, I only use indirect method invocation for class methods, not instance methods. Why use it at all? Maybe it's a throwback to my (hated) C++ days. Or maybe it just 'feels right'. I tend to say: "I'm going to by a new car", not "I'm going to by a car new". But mostly I think that applying direct method invocation to a bare-word is unintuitive. And the use of contrived examples to deprecate things that work perfectly well in normal situations just seems like bad karma. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l] [select]
Re^9: Is it ok to mix functional and oo programming in one package? by chromatic (Archbishop) on Oct 19, 2007 at 18:28 UTC
And the use of contrived examples to deprecate things that work perfectly well in normal situations just seems like bad karma. It's not the normal situations that worry me in programming. For what it's worth, I argued for removing the indirect object syntax entirely from Perl 6, but can live with the postfix indirect object disambiguation marker which renders the parsing ambiguities moot. The syntax bothers me, but the potential for non-deterministic code is the real problem with the syntax in Perl 5. Perl 6 fixes that, so what's left is merely a matter of style, for which Perl allows more than one way to do it. Update: Disambiguated my second paragraph.	[reply]
Re^7: Is it ok to mix functional and oo programming in one package? by rhesa (Vicar) on Oct 19, 2007 at 01:30 UTC
Ah, but wait, you didn't write `hello $a;` [download] Why's that? It works ;-) Read more... except when it doesn't... (740 Bytes)	[reply] [d/l] [select]
Re^8: Is it ok to mix functional and oo programming in one package? by BrowserUk (Patriarch) on Oct 19, 2007 at 11:34 UTC
Ah, but wait, you didn't write `hello $a;` True, but when I have an object instance, invoking instance methods using direct method invocation is, well, natural. I'd never think to do it any other way. But class methods on a bare-word... Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l]