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++; 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'd really like to make blessing into things like '', '0', 'HASH', and "\0" illegal just to put some things to rest.

I'll agree with you with regard to everything but 'HASH' and other type specific designations. Since ref was so ill-conceived from the beginning there will always be code out there that gets nailed by bad coding decisions. Being able to bless a reference so that it appears to crude analysis to be of a different type than than it really is can be a useful workaround. It can be used to deal with bad coding such as ref $obj eq 'HASH' when you want to pass in a blessed hash, or a couple of other tricks like things with overriden deref operators.

Truth be told however, I would almost argue that blessed and reftype should be added to the perl core (without requiring Scalar::Utils) and ref deprecated. I would also make reftype take an optional second argument turning it into a type specific ISA.

I agree that its a real pitty that ref is so poorly thought out. But theres not much to be done about it now.



---
demerphq



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

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.

I don't think I forgot anything.

Well, it seemed to me that you forgot that its somewhat traditional in Perl to leave as much rope as people need to hang themselves. Personally I dont see it as too much of a problem. *shrugs*

is the possibility of a reference blessed into package 0 (zero) or package '' sufficiently rare and unlikely that I can reasonably ignore the possibility?

In general I would say that you can ignore the possibility. If you happen to decide to write something is supposed to walk any data structrue correctly then I would say that you should consider the whole slew of possibilities in this area.

BTW, I didnt mean to imply that you should be worried about redefining constants. Just that its a useful feature in some respects and the side effect of when it is needed for useful things is that it allows some very dangerous things. As does blessing.

Anyway, cheers.



---
demerphq



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

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.