Could you be less rude, please?

You may have some good points, but your nastiness makes reading your blog posts really tiring.

I don't know why you take this tone. I find it very off-putting, and wish you would just state your case. Did you do so on the development mailing lists? I don't remember these arguments being made, although it has been a long time.

That is, it wasn't just decided by "the language police" for 5.16. The use of "defined" on arrays and hashes has been marked deprecated in perlfunc since perl 5.005_02! That is, since 1998. That is, for about fourteen years. If it performs some important job that needs to be picked up, then *by all means* bring this to the attention of perl5-porters.

That’s just Reini. You have to filter out the persecution complex in his writing in order to get to the meat, but I’ve found it worth the effort. He has done some great work that I’m frankly surprised gets so little attention. Maybe it’s also because in some ways he seems to want Perl to be a language that it’s not, but I find that his ideas there do not detract from his other work. And frankly (again), no one engages him on those questions on the level at which he looks at them – he might well be open to reconsideration if people did do that.

I didn't realize any of this was rude until I read the comments. I think it's nasty because some people start by thinking it's nasty. I sense a lot of defensiveness here to deflect from the real problem that Perl has some dubious and confusing design decisions. I find Dave and Ric's tone off-putting. Why can't either of you just state your case?

Frankly, I think the attitude of "take it to p5p" perfectly illustrates the "language police" jab (and it's just a jab) which Dave and Ric probably find objectionable. There's an attitude that these discussions should be buried in a mailing list that virtually no one reads (compared to the size of the user base) rather than be discussed in "public". The users don't matter, so what's the point of making people aware of these issues?

> But at least we can now officially declare our language specs broken by stupidity.
Hm, isn't stupidity a bit harsh?
If I were to introduce a new feature an have this called stupidity, I would quite certainly take it personal.
I have learned that such things are better discussed by telephone or even face-to-face.

I find the informative part of the post interesting to read.

I didn't realize any of this was rude until I read the comments. I think it's nasty because some people start by thinking it's nasty. I sense a lot of defensiveness here to deflect from the real problem that Perl has some dubious and confusing design decisions.

Calling people names creates an atmosphere of antagonism, and in this case I don't think anything happened that warrants that. It's not a constructive thing to do.

Frankly, I think the attitude of "take it to p5p" perfectly illustrates the "language police" jab (and it's just a jab) which Dave and Ric probably find objectionable. There's an attitude that these discussions should be buried in a mailing list that virtually no one reads (compared to the size of the user base) rather than be discussed in "public". The users don't matter, so what's the point of making people aware of these issues?

That doesn't mean these discussions can't also be held on blogs (I certainly agree we should do such things more often, our communication to the outside sucks), but that should be complementary to discussing them on p5p, not a replacement.

More on topic, I see Reini's use-case, but I don't think defined @foo is a good syntax for it at all. I'd find it more intuitive to have defined *foo{ARRAY} or some such do the same (though that currently doesn't seem to work).

defined is supposed to be non-destructive operator to not autovivify the accessed element.

Originally autovivification should just help accessing hash chains by creating intermediate hash values, e.g. $hash->{parent}->{value} would create the parent key and not fail. The safe version would be defined $hash->{parent} and $hash->{parent}->{value}.

defined has nothing to do with autovivification (though it's a common misconception).

doing

  if ($foo->{bar})

will not autovivify the bar key.

  if (defined $foo->{bar})

also won't. (same with exists).

doing

  if ($foo->{bar} and $foo->{bar}->{boo})

won't autovivify bar or boo.

  if (defined $foo->{bar} and $foo->{bar}->{boo})

neither. but the defined is useless here. avoiding autovivification is done by testing each "chain link" itself. defined doesn't make a difference there.

defined is for testing if something is not undef.

There is always autovivify pragma (usually used as no autovivify 'something') to avoid autovivification...

This behavior would actually be much less annoying if defined *foo{SCALAR} worked like all other defined *foo{THING}, though all of them still autovivify a nonexistent *foo glob.

My 5 cents here: I personally couldn't make any use of discussions on p5p, and my very subjective view is that Reini couldn't either, therefore the rant. Imagine you're trying to get your point through, cannot, feel ignored, and venting it out to your blog. But then comes police and says the blog is the wrong place for discussion, and appeals to the tone instead of the message ... it's just cheap people, let's hear the message, not silence it. I do respect people on p5p but discussions there so often get buried in discussions leading nowhere.

All of the use cases for defined except defined($scalar) are better done with exists, scalar,!! or just removing defined.

• defined &func === exists &func
• defined func === exists &func
• if defined @array === if @array
• $def = defined @array === $def = !!@array

I find it very sad that this thread is taking this tone while the "why I left Perl" stuff is going on. Please. Everyone. Lets take this down a notch.

Although it got heated, I'm glad there has been an amicable resolution.

Is there something that can be done to make the CPAN authors aware of the now broken code?

Reini's clarification mentions Google Code Search; however, it was unfortunately shut down on 15 January 2012. The Google Code Search Team listed some alternatives.

If the test suite does anything at all, it will let both authors and users know when there is a problem. This is, by the way, an argument for running tests.

When I find such problems I file a bug report. With fix if I can work it out, and for the defined() bug it's pretty easy. The bug reports are either acted on or ignored. I suppose we could spam the CPAN authors, but authors that ignore bug reports and test results may not be likely to respond to mail.

FWIW (perhaps little enough) I've always used

__PACKAGE__->can( 'foo' )

Worse than a problem of tone is a lack of effective argument where listening is evident so things don't devolve into repeating the same claims back and forth.

Most of the uses of defined(@array) that I have seen have been people who really meant !!@array and had code such that they never ended up with an allocated @array that was empty so defined(@array), for their code, happened to always (or at least usually) match !!@array.

So "fixing" defined(@array) to mean "the named variable has been declared or came into being by having been initialized" would actually break a bunch of Perl code. And it would /silently/ break a bunch of Perl code.

So it is much better to noisily break the code that sometimes or often or always (so far) "worked" so that it can be replaced with code that always works.

If defined(@array) hadn't become used incorrectly, then it might be reasonable to "fix" it to be useful for people doing introspection.

But the fact that defined(@array) has often been in use /not/ for introspection means that it may be an inappropriate tool for that. Even if all of the existing misuse of defined(@array) for checking "@array isn't empty" were eliminated, leaving defined(@array) around will lead to it being misused again unless it almost never works.

Granted, if defined(@array) were to mean "variable has been declared or created", then it would less often match "@array isn't empty". But I think it would match often enough that there would still be people using defined(@array) incorrectly when they meant "@array is not empty". That may not be big enough of a problem to justify never getting to the point when defined(@array) is introspection. But it should be enough reason to cause caution in pursuing that.

But I personally think it is clearly a bad idea to jump to defined(@array) as introspection without first making it fatal for a while in order to prevent a lot of "silent change" problems.

I'm not convinced that defined(@array) /looks/ like introspection, but that's a weaker argument against it. I prefer advanced things like introspection to not look so mundane.

If there is existing module code that manages to use defined(@array) for introspection effectively, I actually have less sympathy for such advanced code containing the less accurate test (over testing via the glob).

The best improvement I could see on that front would be to officially document how to do introspection. Even provide a core module dedicated to introspection, blessed by p5p.

The case of introspecting scalars, I believe, has long been acknowledged as slightly unfortunate but "fixing" it would require adding at least a boolean to every single glob. I don't know if that can be done without a space penalty. The CPU penalty would probably be minimal. But those still mean there should be some caution when it comes to "just fix it".

I don't have a great feel for how important "don't be forced to /assume/ that $foo hasn't been declared/created just because it currently contains undef and @foo or %foo has already been declared/created" is compared to the cost of enabling such.

I can see how people on either side of these issues could have a narrower view that results in them seeing the other side as "stupid". Demonstrating one's ignorance or narrowed focus by declaring such things seems less effective...

Clinging to the assessment of "that's stupid" is even worse (even if you never state it), because it prevents you from understanding the larger picture which prevents you from addressing other people's concerns which prevents you from improving things.

Reini, I don't how to get at codesearch now? I see that I can search googlecode hosted projects, is that all of it or can you get to more somehow? Searching github directly might help supplement.

One major source of this might be Advanced Perl Programming with the following:

Example 6.2: Dumping All Symbols in a Package

package DUMPVAR;
sub dumpvar {
my ($packageName) = @_;
local (*alias); # a local typeglob
# We want to get access to the stash corresponding to the package
# name
*stash = *{"${packageName}::"}; # Now %stash is the symbol table
$, = " "; # Output separator for print
# Iterate through the symbol table, which contains glob values
# indexed by symbol names.
while (($varName, $globValue) = each %stash) {
print "$varName ============================= \n";
*alias = $globValue;
if (defined ($alias)) {
print "\t \$$varName $alias \n";
}
if (defined (@alias)) {
print "\t \@$varName @alias \n";
}
if (defined (%alias)) {
print "\t \%$varName ",%alias," \n";
}
}
}

Hi Reini, hi all, very sorry to jump in that way, but even after reading this articles many times I can't find a way to solve my pb with defined.
Most web articles says defined(%hash) is useless but how can one test if a key of a hash of hash is itself an hash or just a end value , before running a "keys %hash" to get the unknown subkeys names ? (meaning can not do exists $hoh{$key}->$subkey since subkey is unknown.

with perl 5.10 , defined does the trick, but now I updated to 5.16, my script is broken.

My script take a hash of hash and dump its architecture into a file, like Dump::hash but in a custom way.

Any suggestion to replace defined ?
Thank you very much for your help !

sub dump_hash
{ # dump_hash_osa(hashname, filename)
my $hashname=shift;
my $filename=shift;
my $string;
open(CHAR, ">$filename");
$string=print_hash_elmt(\%{$hashname}, "");

print CHAR $string;
close CHAR;
}
sub print_hash_elmt
{
my $hashname=shift;
my $tmp_line=shift;
my $elm,$elm2,$elm3='';
my $string='';
my $stringr='';
foreach $elm ( sort sort {$a $b} keys %{$hashname}) {
if ($elm =~ m,\s,) {$elm2="\"$elm\"";}else {$elm2=$elm;}
if (defined %{$$hashname{$elm}}){
##--- KEY IS HASH ----
$string = print_hash_elmt(\%{$$hashname{$elm}}, $tmp_line."$elm2\t");
} else {
##-- KEY IS VALUE --
if (($$hashname{$elm} =~ m,\s,)&&($$hashname{$elm} !~ m,^\".*\"$,))
{ $elm3="\"$$hashname{$elm}\"" ;}
else {$elm3=$$hashname{$elm};}

$string = $tmp_line. "$elm2\t$elm3\n";
}
$stringr .= $string;
}