Re: [code-review] Hello!

Hi all,

	First, I wanted to thank all of you for your wonderful comments.  I've 
worked in a few environments that had very useful code review sessions, but 
this is the first time I've seen it done in a distributed fashion for open 
source code.  It is just as useful and I'm really enjoying it.  Thanks.

	Though my position has more or less already been stated by others, I 
wanted to chime in on the question of backward compatibility of new modules 
as I provided the seed for the conversation.
	While I see the value in sticking to reasonably current perls, all sorts 
of people don't do so for all sorts of reasons.  As people have pointed 
out, some people don't have the access to do so easily in the environments 
in which they work.  While I'm aware that in most cases you can install a 
newer perl locally, with only mildly out-dated versions, it isn't worth 
it.  In addition, some people do meaningful work with Perl without the 
expertise required to do that.
	Other people do their work in large organizations that are slow to upgrade 
perl.  Until last October, I worked at a large company that is absolutely 
wonderful with respect to handling technology and in both its use of, and 
contributing to, open source, but is so intensely busy and has such a large 
installed base that upgrades of that sort aren't done casually.  I think 
they're still on a late 5.005.  I'm sure there are many similar 
environments.  I'd hate to cut them off.
	I think the best approach is to be as backwards compatible as is "easily" 
possible.  What I mean by this is that I'll balance using language features 
that I need or want with their likely availability among my intended 
audience.  My module uses lexically scoped variables, for 
instance.  Strictly speaking I could avoid this, but at this point *very* 
few people are stuck with Perl 4, and the only available remedy is making 
the code harder to use, maintain and update.  I don't think that sort of 
backward compatibility is worth the costs.
	By contrast, the issue that got this started was my choice to use an array 
ref to hold values and then accessing the values by numeric subscript.  A 
poster suggested that this isn't as clean as using constant and calling 
those values by name.  This is a much smaller liability than not using 
strict and not having lexicals, so if the choice is between that small lack 
of clarity and backward compatibility, I might choose to allow the lack of 
clarity to exist anyway... but that isn't a choice I need to make.  Perl 
has a handy mechanism for accessing data by name that has been around as 
long as I've used Perl, in hashes.  I can make the change desired in a way 
that doesn't require a newer version of perl than what I'm already 
implicitly requiring through the use of lexicals.
	Finally, I think there is little value to the "political" argument to give 
people reasons to upgrade perl.  What would be the purpose?  perl makes its 
own argument.  New versions are driven by new and better functionality and 
improvement of existing functionality.  Each individual can make informed 
decisions about whether it is worth whatever hurdles he perceives as 
existing to upgrade to a newer version.  What possible motive do I have in 
trying to skew that decision in one direction by creating a new module that 
user might enjoy that requires a particular upgrade decision?
	I think this kind of decision is best, at least for me.  I wouldn't have 
uploaded the module to CPAN in the first place if I hadn't wanted it to be 
available as broadly as possible and be useful to as many people as 
possible.  It seems that any design principle that cuts off usage to some 
people for little to no gain would be self-defeating.

Cheers,
Jeff