|
Re: Use of 'our' considered harmful
by Juerd (Abbot) on Sep 24, 2004 at 09:52 UTC
|
What you are really saying is:
Use of new features considered harmful
You are of course allowed to have any opinion you want, but I strongly disagree. The new features make some things much easier and that is worth the trouble in my opinion.
I think neither the original title nor my rewrite of it really do anything about the real problem you have. I humbly propose the following statement:
Use of ANCIENT PERL considered painful
Perl 5.005_03 is 5 years old.
I'll buy a crate of beer for the first person who can show me some real-world code which absolutely requires our and can't be re-written to use my.
With those unstrict rules, it's easy:
package Acme::Example;
use base 'Exporter';
our $VERSION = '1.00';
our @EXPORT_OK = qw(example);
sub example { ... }
This cannot be rewritten with my, because then things start to break. It can be rewritten using use vars, but you didn't mention that at all. You owe me a crate of beer :) I'm not the first, but tantarbobus has earned the beer! :)
| [reply]
[d/l] |
|
|
Of course, it only matters if you use strict. I'm not saying you shouldn't use it, but what's stopping you from using it after the variables that really need to be public?
package Acme::Example;
use base 'Exporter';
$VERSION = '1.00';
@EXPORT_OK = qw(example);
use strict;
sub example { ... }
| [reply]
[d/l]
[select] |
|
|
Nothing's stoping you. But do you also access those variables before you use strict? :)
(That is, every mention of a package variable under use strict -- whether a declaration or use -- needs to be fully qualified, or in the scope of an our or a use vars. (Well, mentioning scope when talking about use vars is misleading, since its effect is declarative and not lexical.))
| [reply] |
Re: Use of 'our' considered harmful
by mpeppler (Vicar) on Sep 24, 2004 at 10:35 UTC
|
As the author of a couple of modules on CPAN I know that moving too quickly to use new features/constructs is a bad idea. Some users of my modules are still at 5.004. A while ago I had someone contact me trying to build sybperl with 5.002.
But - there are also issues with not using new features. There is a balance to strike, and it all depends on the particular module's code to find out what perl version/features should be supported.
BTW - the same can be said for C code. The C/XS portion of my modules is still, by and large, K&R level code. This is mainly due to having this as the lowest common denominator when the modules were written (f.ex. SunOS 4.x cc didn't understand prototypes). So using new features of tools isn't only a problem of perl.
Michael
| [reply] |
|
|
I actually like the K&R prototypes beter than the ansi:
int
foo(this, that, these)
char *this;
char *that;
char *these;
{
}
/* Is much nicer than: */
int foo(char this, char that, char those)
{
}
| [reply]
[d/l] |
|
|
The point in ANSI prototypes is that when you use them,
any call to the function will actually convert the parameters
to whatever type the prototye says.
More clearly, the K&R style declaration of
arguments (which is not a prototype btw) say
only what the function pops off the stack,
but not what the caller pushes to the stack.
If, however, a function has an ANSI C prototype
(and it's included in wherever you call the function from),
the C compiler will automatically convert parameters
to whatever the prototye says, and will warn
you if you call the function with an incompatible
number or type of parameters.
| [reply] |
|
|
|
|
Nothing to stop you writing
int
foo ( char *this,
char *that,
char *these )
{
...
}
FWIW... :-)
Michael
| [reply]
[d/l] |
|
|
In both cases the type (and most of the modifiers and other cruft) is on the wrong side of the variable. Does anyone think "and now I'm going to need an int, let's call it counter"? I think not. Normal people say to themselves "and now I'm going to need a counter, an int will be enough".
Not speaking about the mess with pointers to functions and functions returning pointers etc. int *foo() vs. int (*)foo() anyone?
Jenda
Always code as if the guy who ends up maintaining your code
will be a violent psychopath who knows where you live.
-- Rick Osborne
| [reply]
[d/l]
[select] |
|
|
|
|
Re: Use of 'our' considered harmful
by tantarbobus (Hermit) on Sep 24, 2004 at 09:46 UTC
|
You would probably be better off using use vars qw// instead of my, since it is more like our. And as for a real world situation, how about a closure where you want to use a var declared outside of the closure, but without "making a copy of the var".
| [reply]
[d/l]
[select] |
|
|
how about a closure where you want to use a var declared outside of the closure
Well, by definition, a closure does operate on variables outside itself... that's the whole point.
As for a closure that is based on a global variable (lexical or otherwise), I can only ask "Why would you want to do a thing like that?" If the variable is global, it sort of defeats the purpose of wrapping it up in a closure. (Otherwise you would just use local).
So yes, you could do so, but I don't think it qualifies as a Real World Example™ as per the OP. I think anything you could come up with could be wrapped up in a sub and use lexical mys, and I think it would be better that way.
- another intruder with the mooring of the heat of the Perl
| [reply] |
|
|
sub whatever_its_called {
our ($dbh) = DBI->connect(...);
sub do_hit {
$dbh->prepare("stuff");
}
}
| [reply]
[d/l] |
|
|
|
|
|
|
|
|
|
Re: Use of 'our' considered harmful
by ajt (Prior) on Sep 24, 2004 at 11:09 UTC
|
A better paraphrase should probably be "Don't use something new and trendy, because it's new and trendy".
Sometimes you need to use a new feature, but often there is a more legacy friendly solution. I believe that the use of "our" has been complained about before, there are plenty of modules on CPAN that use "our" when they don't need to, and that does cause lot of pain to users of older Perls.
I make no comment about the point at which older versions of Perl are considered too old to be used or supported.
| [reply] |
|
|
Bingo! I've not got a problem with people using (eg) Unicode-friendly features (#include rant about utf-*) if they need them. But no-one has a need for our that I can see.
Brother Juerd said further up the thread that maybe this should be about five year old versions of perl being considered harmful. Sorry Brother, but I just don't see that. This 'ere machine, which I installed not three months ago, has a *ten* year old version of awk and a six year old sed. I use those most days. There's no need to upgrade. Many users don't see why they should upgrade perl when their perl is only half that age. They consider such a moving target to indicate a certain immaturity in perl.
| [reply]
[d/l] |
|
|
| [reply] |
|
|
If evolving can be considered synomymous with immature, you are right. AWK is an old (and comparatively small) language frozen in time, so it's not surprising that the 10-year old interpreters work perfectly well. Perl is always experimenting, which I agree is problematic from a systems administrator's point of view. And since many sysadmins don't care about upgrading perl, I often end up having my own version on my ~/bin directories...
| [reply] |
Re: Use of 'our' considered harmful
by tilly (Archbishop) on Sep 24, 2004 at 15:26 UTC
|
| [reply] |
Re: Use of 'our' considered harmful
by hardburn (Abbot) on Sep 24, 2004 at 12:53 UTC
|
Almost all of my code is going to run on my company's web server, and nowhere else. We have 5.8.0 running there. I have no need to waste my time trying to get it to run on something less.
IMHO, you are correctly pointing out that our is bad, but for the wrong reason. It's bad because package-scoped variables get you into all sorts of trouble. I code with very tight lexical scopes so that variables live for exactly as long as they need to (View Gameboy Cartridge Information is a good example).
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply]
[d/l] |
Re: Use of 'our' considered harmful
by Zed_Lopez (Chaplain) on Sep 24, 2004 at 18:47 UTC
|
require 5.6;
And then the SysAdmin could have just upgraded to Perl 5.6 or higher to take advantage of the require version syntax.
Simple!
| [reply]
[d/l] |
|
|
"Just" upgraded to Perl 5.6? "Just"? I don't think there has ever been a Perl releases that did not break scripts out there. Every Perl release breaks things. Sometimes intentional. Sometimes because of a bugfix. Sometimes because a feature is suddenly considered a bug, or bad coding style, and it gets "fixed". Sometimes because behaviour was unspecified (but consistent) and then it got specified to act different from how it always worked. And often the breakage was unintentional.
There are (very) large companies out there, with tens of thousands of users using hundreds or thousands of tools who might take a year to roll out a new version of Perl. And who *intentionally* do not upgrade because of the breakage.
One can't assume that what you can do on your home PC - just upgrading Perl in 20 minutes - one can do everywhere.
| [reply] |
Re: Use of 'our' considered harmful
by itub (Priest) on Sep 24, 2004 at 12:59 UTC
|
Real life story: I wanted to make one of my modules as backwards-compatible as possible, so I installed various versions of perl to try it (including 5.8.0, 5.6.1, 5.004_05, and 5.005_03). After removing all use of the newest features such as our, I found that the oldest, pre-5.6 versions of perl crashed (as in segfault) when running my code (perhaps I was using features that were experimental at the time, but still syntactically valid?). My conclusion: I won't care about supporting ancient versions of Perl, so I can use our happily. One thing is to avoid new features, but it just takes too much time to work around the various bugs in ancient perls. | [reply]
[d/l]
[select] |
|
|
I think this also brings up a valid point - modules in general continue to evolve in incorporate newer language features. For example, the latest version of DBI does not work with 5.005x or earlier.
The more that modules continue to develop the more older versions of perl will be left behind.
| [reply] |
|
|
Nothing wrong with forced advancement as long as it's slow. If we had people happily writing Perl 5.005 code (or worse, imagine Perl 4), we would have people trying to keep up with the language and seek out new features. Stagnation = death. I don't want Perl to be like awk. No one does.
Also, more On-Topic: This topic isn't remotely about our being considered harmful, it's about your sysadmin being considered harmful. Our is not as good as my due to the principle of "smaller scope" is better, and I write code all day without it -- but I note a recent trend to tack "considered harmful" onto the end of meditations to appear like a certain famous computer science guy, and that's just silly.
| [reply] |
|
|
Re: Use of 'our' considered harmful
by quinkan (Monk) on Sep 27, 2004 at 13:15 UTC
|
Doctour, ye speke trouley to us alle.
Whan langage changen and be free,
No good to symple hackers shal bifalle.
Thilke thing is plain to see:
An six is come, this our is not for thee.
| [reply] |
Re: Use of 'our' considered harmful
by sauoq (Abbot) on Sep 25, 2004 at 05:28 UTC
|
The user was quite prepared to ditch the tool altogether and find another because it didn't Just Work.
That would probably have been a perfectly reasonable thing to do. Depending on various things, it might have been more reasonable than going through the script changing ours to mys. It might even have been easy to find a better replacement written by someone who cares about backward compatibility (or has enough Perl experience to avoid global variables when lexically scoped ones will do.)
Since you did urge your sysadmin to fix the script, however, I hope you also urged him to submit a patch to the author. Not only will you both know that you did your part in helping others in the same situation, but if an unrelated bug fix for that script comes out next month maybe your sysadmin won't have to spend more time fixing the tool before he can use it.
-sauoq
"My two cents aren't worth a dime.";
| [reply]
[d/l]
[select] |
Re: Use of 'our' considered harmful
by aufflick (Deacon) on Sep 27, 2004 at 00:12 UTC
|
I hesitate to add to the volume of existing replies, but you could also paraphrase your question as "why do you need to use that fancy loop control when the same thing can be achieved with goto?"
Some new language features are sytactic sugar that aren't really necessary. But like loop control, the our scoping keyword actually allows code that more closely matches a mental model more closely (and safely) than the global-magic of use vars.
I must say I worked on a 60,000 line perl project recently that was restricted to perl 5.005, and living without our really wasn't hard. But it is nicer, and it's not hard to backport if you really have to. | [reply] |
Re: Use of 'our' considered harmful
by tomhukins (Curate) on Sep 27, 2004 at 21:32 UTC
|
Your comments remind of Avoid fancy words, an idea expressed in Strunk and White's Elements of Style. I wouldn't be the first programmer to suggest this book helps us think about how we program, even though it discussed writing in a natural language - English - as opposed to a programming language.
Why use clever terminology when plain words suffice? For Perl, our stands out as a neologism. In time it will become an established part of the language. But it isn't there yet, at least not for all Perl users. It's a matter of judgement, or ear as Strunk and White put it:
Only the writer whose ear is reliable is in a position to use bad grammar deliberately; only he is able to sustain his work at the level of good taste.
Whether we use our, or other neologisms in Perl, is a matter of taste and timing. At present, both are contentious: our has existed in Perl long enough for common use, but too short for universal acceptance. I avoid it in public code for the reasons you mention, but those reasons become weaker as time passes.
| [reply]
[d/l]
[select] |
Re: Use of 'our' considered harmful
by Anonymous Monk on Sep 27, 2004 at 14:18 UTC
|
The moral of the story is that the Perl world could learn something from the Java world. Java, just like Perl, is a moving target. Java 1.1 isn't the same language/environment as Java 1.4, just like Perl 5.0 is quite different from Perl 5.6. Hence, it's not uncommon for an application written in Java, to be distributed with whatever Java environment it needs. Problem solved.
A Solaris admin | [reply] |