in reply to Recursive map Design Questions

$seen->{ ref($_) ? $_ : \$_} = undef

You are aware that ref can return a false value even if its argument is a reference?

$ perl -wle 'print ref bless [] => 0' 0

You ought to check for definedness, which is easy in 5.8.1 with the defined-or patch:

$seen -> {ref () // \$_} = undef;

Abigail

Replies are listed 'Best First'.
Re: Re: Recursive map Design Questions
by BrowserUk (Patriarch) on Oct 02, 2003 at 09:53 UTC

    Abigail. Are you seriously suggesting that people should cater to the possibility that references may have been blessed into a package of 0?

    Firstly, it would have to be a deliberate, willful act to do it as it isn't possible (that I am aware of) to actually have a package 0;

    Secondly, shouldn't bless [], 0; be considered a bug and reported for fixing?

    Is there any possible legitimate use of this?


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
    If I understand your problem, I can solve it! Of course, the same can be said for you.

      I think you have a point on one level and on the other have temporarily forgotten a core principle of Perl.

      Do these tricks have a legitimate purpose?
      Not really, or not to my knowledge anyway. Maybe obfus or something.
      Are they probably a bad idea to do?
      Yep.
      Should we worry about it in average code?
      Nope.
      Should we worry about it in code specifically meant to properly grok various data types and structures?
      Yep.
      Should we make thse things illegal?
      Nope.
      Why not?
      Just because we can't see a good reason to do these things doesn't mean that there will never be a good reason to do them. So its better to leave them alone.
      Yeah but isn't that a bit dangerous
      Yeah but so is ten feet of rope.
      It is?
      Sure, somebody could hang themself.
      Er...
      Ever notice that you can redefine the value of numeric constants in perl?
      What?
      Sure. You can define 1 to be an approximation of pi if you like.
      Oh god.
      Yep. Be careful with that there rope now y'hear.

      ;-)


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi


        demerphq++; I mostly agree with what you've said. But Perl already disallows some similar things so I'd really like to make blessing into things like '', '0', 'HASH', and "\0" illegal just to put some things to rest.

        I'm quite tired of hearing about how simple code doesn't work in all cases and the resulting discussions of things-that-should-never-be-done that would break the simple code and then people replacing really simple code with really complicated code in order to deal with this nonsense.

        Now, this will only fix one of the problems with ref($h) eq 'HASH', but there are other improvements that fix the other problems [UNIVERSAL::isa() and Scalar::Utils].

                        - tye

        I don't think I forgot anything.

        I was genuinely asking whether Abigail thought that this was something that I should be testing for in my programs or just another of those many perl quirks that it's good to be aware of but probably pointless actually coding tests for.

        Abigail tends to have a very dry sense of humour and I couldn't tell if this was a serious concern for everyday use or not from his post, so I asked.

        We could put checks in our code to make sure that someone hasn't re-defined our defined constants, but that would render them pretty pointless.

        So, my question remains -- should I be checking the return from ref for definedness every time I call it, or is the possibility of a reference blessed into package 0 (zero) or package '' sufficiently rare and unlikely that I can reasonably ignore the possibility?


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
        If I understand your problem, I can solve it! Of course, the same can be said for you.

      Well, people are expected to consider the possibility files are named "0", or that files can end with "\n0" (for the latter, there are even warnings build in in Perl).

      I'd say that if you code general solutions, and that's what the OP was doing, you should consider such possibilities. Programs that run in a specific, or controlled environment may not have to take such things into consideration.

      Oh, and don't get the idea that a package of '0' has never happened. The original post triggered a memory. Years ago, a co-worker was working on some complicated template system. Some code also dealt with 'ref' and blessed objects. And code *did* fail because some other code (which generated code) blessed objects in the package '0'.

      OTOH, I've never encountered a supposedly text file that ended with "\n0". That doesn't mean I won't check for definedness when necessary.

      Secondly, shouldn't bless [], 0; be considered a bug and reported for fixing?

      Uhm, why? Just because it's inconvenient? Then we might as well forbid filenames to contain spaces and Microsoft Outlook - that's inconvenient as well. ;-)

      Abigail

        I guess while it can happen, it must be checked for, so in that sense, I agree with your conclusion for generic solutions, and applaud you for your original mention as it was something I had never considered.

        That said, I think I would stil tend to ignore the possibility. If a reference my code is given to deal with has been blessed into a package who's name tests and false, then it is either a diliberate attempt to screw things up, or is the result of an accident. In the former case, the user gets what they deserve:). In the latter, it will mean my code will fail, which is probably a good thing as it will bring the error to the user attention.

        Uhm, why? Just because it's inconvenient?

        If there was a legitimate (even if esoteric and obscure) reason for blessing things into a false-testing namespace, then I could see the reasons for allowing it.

        However, without a legitimate reason, it makes no sense to me to inconvenience everyone with the need to test for it, when a simple test + error in the implementation of bless could remove that inconvenience.

        ...and Microsoft Outlook...

        I wouldn't forbid it, I would make it's use a capital offense with no possibility of commutation or appeal:) I once nearly lost a pretty good job by refusing to use it, and I will continue to do so. Though my reasons have nothing to do with convenience or lack thereof.


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
        If I understand your problem, I can solve it! Of course, the same can be said for you.

Re: Re: Recursive map Design Questions
by bsb (Priest) on Oct 02, 2003 at 08:20 UTC
    Now I'm confused.
    $ perl -wle 'print defined ref 0' 1 $ perl -wle 'my $a; print defined ref $a' 1 $ perldoc -f ref ref EXPR ref Returns a true value if EXPR is a reference, false otherwise. If EXPR is not specified, $_ will be used. The value returned depends on the type of thing the reference is a reference to. # Salvation? $ perl -MScalar::Util=blessed -wle 'my $a; print defined blessed(bles +s [] => 0)' 1 $ perl -MScalar::Util=blessed -wle 'my $a; print defined blessed($a)'
      Yes, my bad. If the argument isn't reference, 'ref' returns the empty string, not undef. But the first line of the documentation you quote is provebly wrong. I'll write a patch.

      Abigail