On Tue, 28 Sep 2004, Wiggins d Anconia wrote:
> On Tue, 28 Sep 2004, Chris Devers wrote:
>
> > On Tue, 28 Sep 2004, Errin Larsen wrote:
> >
> > > On Tue, 28 Sep 2004 18:51:12 +0800, Edward Wijaya
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > > > use vars qw($f);
> > >
> > > The above is good, but is now obsolete.
> >
> > That is debatable.
>
> Please, beginners, recognize the above word, *debatable*!!
<aol />
I'm not forwarding this along as a blanket assertion that 'our' is bad,
broken, and always to be avoided. None of that is true. Rather, I'm
using it as an example of how a seemingly innocuous new feature can have
unexpected & possibly hard to debug consequences "in the wild".
If you're only writing for yourself on systems that you have fulll
control over, then this particular example probably isn't a big deal.
If, on the other hand, you get a job where you have to work with the
available software, then you may be stuck.
It is worthwhile to spend a few minutes figuring out what problem a new
feature solves, reflecting on whether that problem impacts you (chances
are good that it does, but it might not), and considering whether or not
using this new construct over older methods introduces new problems (it
should not, but it might).
To just blindly accept a suggestion like this without at least a little
bit of thought is what is called "cargo culting"; it's a bad habit:
<http://catb.org/~esr/jargon/html/C/cargo-cult-programming.html>
<http://www.physics.brocku.ca/etc/cargo_cult_science.html>
<http://en.wikipedia.org/wiki/Cargo_cult>
That said, here's one article (of several, surely) that contrasts the
'my' and 'our' functions:
<http://perlmonks.thepen.com/105446.html>
Be aware of what's going on here before concluding that 'our' is always
the one to use. It might be, maybe, but it might not.
That's all :-)
> > The moral of this story is that even if you have the latest and
> > greatest perl, you shouldn't use the latest and greatest features
> > unless you absolutely must. Because if you do you will severely
> > limit who will use your code. our in particular is really only a
> > convenience, saving a few key strokes at most. So don't use it.
> > Ever.
> >
>
> This is opinion taken out of context, and stated as a rule rather than a
> suggestion, which may be a bit over the top.
Maybe so, but I thought it was striking that Jokob Neilsen has written
similar things about adopting new features in web design. Consider the
footnote for this essay:
Normally, I advise against using new Web technologies for the first
year after they have been introduced. In most cases, using anything
new is asking for trouble and will alienate users with older browsers.
Link titles are an exception to the need to wait a year. First, their
use does not hurt users with browsers that don't display link titles
[....] Second, a browser that does not understand link titles will
simply skip them. [....] The only downside is that link titles will
add approximately 0.1 seconds to the download time for a typical
Web page over a modem connection. This is a rather harsh penalty,
but worth paying because of the increased navigation usability for
those users who do get to see the link titles.
At the time of this writing, link titles will probably only be seen
by 25% of the users. Normally, this would be insufficient to employ
a new Web technology, but since link titles are extremely easy to
add to your pages and since they do not pose any danger to users
with older browsers, it makes sense to go ahead and start using link
titles. [....]
<http://www.useit.com/alertbox/980111.html>
Note the way he thinks this through. The base instinct is conservative:
most new features introduce problems bigger than the one they solve, so
he avoids them. In this case, however, the problem is broad, the risks
are slight, and the benefits are large, so he breaks the usual rule.
That, I think, is the right approach to new features in any language.
> Definitely worth knowing about the downsides, but I would push the
> other direction, is it worth not using something that benefits to
> prevent something that may never happen?
Beats me -- is it?
I don't think there's a blanket rule here, one way or the other. It
comes down to what your expectations are for your code, whether or not
it could have a life of its own after you're done with it, etc.
If nothing else, it might not be bad to start off scripts using new
features with a
require 5.6.1;
(or whatever the first version with 'our' was), with a comment saying
what construct you're using that demands the require statement.
But anyway, I'll leave it at that, as this is turning into a long
discussion with no real right or wrong sides but lots of talk... :-)
--
Chris Devers
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
