On 3/2/07, Adam Kennedy [EMAIL PROTECTED] wrote:
99.999% of the time you do not want to really know how something is
implemented, you want to remain ignorant.
I concur, which is what really pisses me off them
IO::String-new(\$string)-isa('IO::Handle') returns false, because the
author
On Friday 02 March 2007 00:53, demerphq wrote:
*snip good discussion*
Now if there was an -implements() utility function as well as the
-isa() funcation, then I think IO::Handle would contrive to ensure
that IO::String-new(\$string)-implements('IO::Handle') would return
true even though
On 2 Mar 2007, at 00:35, Adam Kennedy wrote:
[snip]
Well, except you aren't supposed to do that, because if -isa can
be overloaded, it can also die or throw an exception. So eval
{ $obj-isa($class) } falsely ignores errors.
[snip]
That, of course, depends on whether you want to ignore
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Moin.
On Friday 02 March 2007 08:53:43 demerphq wrote:
On 3/2/07, Adam Kennedy [EMAIL PROTECTED] wrote:
99.999% of the time you do not want to really know how something is
implemented, you want to remain ignorant.
I concur, which is what
Michael G Schwern [EMAIL PROTECTED] writes:
chromatic wrote:
On Thursday 01 March 2007 17:46, Adam Kennedy wrote:
Actually, isn't UNIVERSAL::can($x, 'can') still valid? I seem to
remember that at one point it was considered the only valid use of
UNVERSAL::can directly.
That's the only
Eirik Berg Hanssen wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
chromatic wrote:
On Thursday 01 March 2007 17:46, Adam Kennedy wrote:
Actually, isn't UNIVERSAL::can($x, 'can') still valid? I seem to
remember that at one point it was considered the only valid use of
UNVERSAL::can
On 3/2/07, Michael G Schwern [EMAIL PROTECTED] wrote:
Eirik Berg Hanssen wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
chromatic wrote:
On Thursday 01 March 2007 17:46, Adam Kennedy wrote:
Actually, isn't UNIVERSAL::can($x, 'can') still valid? I seem to
remember that at one point it
On Friday 02 March 2007 08:27, Joshua ben Jore wrote:
Does defined( Scalar::Util::blessed )have cooties? Its the only
predicate you've ever had that actually works.
Sometimes I want to detect class methods too.
Y'know, at some point it's worth saying Here's how this works. Here are the
Joshua ben Jore wrote:
Does defined( Scalar::Util::blessed )have cooties? Its the only
predicate you've ever had that actually works.
It requires depending on an XS module if you want compatibility pre-5.8.1.
I have to worry about stuff like that.
* Michael G Schwern [EMAIL PROTECTED] [2007-03-02 22:35]:
Joshua ben Jore wrote:
Does defined( Scalar::Util::blessed )have cooties? Its the
only predicate you've ever had that actually works.
It requires depending on an XS module if you want compatibility
pre-5.8.1.
Which is the Perlish
Michael G Schwern wrote:
Yuval Kogman wrote:
Likewise with ref in boolean context, I almost never want the object
to be able to lie to me.
But if it has to work hard to lie, then does it matter?
Yeah, I'm with Yuval here. There seem to be a cold war going on here wrt
identifying an object.
chromatic wrote:
On Monday 26 February 2007 13:50, Michael G Schwern wrote:
But what if isa() is broken or has side effects, hmm?
That's not the caller's problem. Fix the broken code. Don't break more code
trying to work around bugs.
I think the problem he's refering to is that if the
Adam Kennedy wrote:
IT SHOULD NOT BE THIS COMPLICATED TO IDENTIFY THE HERITAGE OF AN OBJECT!
use Params::Util '_INSTANCE';
if ( _INSTANCE($obj, 'Whatever') ) {
}
Oh good, depend on another module to implement a basic language feature.
(I appreciate your suggestion but I'm LAMENTING
Yuval Kogman wrote:
BTW, pure perl blessed() will work:
sub UNIVERSAL::a_sub_not_likely_to_be_here { ref($_[0]) }
sub blessed ($) {
local($@, $SIG{__DIE__}, $SIG{__WARN__});
length(ref($_[0]))
? eval { $_[0]-a_sub_not_likely_to_be_here }
Yuval Kogman wrote:
On Sun, Feb 25, 2007 at 22:34:15 -0800, chromatic wrote:
Why not, I already have half of the other stuff in UNIVERSAL
Just don't tell Adam.
As much as I dislike UNIVERSAL::, I'd FAR prefer to have it all
maintained by one person.
That way I can submit my
chromatic wrote:
On Monday 26 February 2007 06:35, Christopher H. Laco wrote:
Or me. I have a personal hate relationship with MockObject in this way.
I love MockObject. I hate getting warnings about 3 party modules use of
can in my test suite.
Ideally those third parties would fix their
On Thursday 01 March 2007 17:46, Adam Kennedy wrote:
Actually, isn't UNIVERSAL::can($x, 'can') still valid? I seem to
remember that at one point it was considered the only valid use of
UNVERSAL::can directly.
That's the only case I can think of too.
-- c
chromatic wrote:
On Thursday 01 March 2007 17:46, Adam Kennedy wrote:
Actually, isn't UNIVERSAL::can($x, 'can') still valid? I seem to
remember that at one point it was considered the only valid use of
UNVERSAL::can directly.
That's the only case I can think of too.
Hmm, that's a clever
On 26 Feb 2007, at 18:23, chromatic wrote:
[snip]
I'm open to a patch that allows people who know what they're doing
to disable
the warnings.
Thank you!
Adrian said he might write one.
[snip]
I shall. I might even do it now :)
Adrian
On 2/25/07, Joshua ben Jore [EMAIL PROTECTED] wrote:
I've hated it how ref() does the wrong thing so frequently so I wrote
a fix for it. I like to use mock objects to feed fake or proxy objects
to other things but this breaks when things not under my control use
ref() to examine the class of an
On 26/02/07, chromatic [EMAIL PROTECTED] wrote:
Please reconsider autobox.
I second this request.
autobox in on CPAN and works. Moreover, the intent of the work on
lexical pragmas was to enable people to write their own pragmas and
put them on CPAN. (*) So just use it.
Or, maybe you were
Rafael Garcia-Suarez wrote:
On 26/02/07, chromatic [EMAIL PROTECTED] wrote:
Please reconsider autobox.
I second this request.
autobox in on CPAN and works. Moreover, the intent of the work on
lexical pragmas was to enable people to write their own pragmas and
put them on CPAN. (*) So
Joshua ben Jore wrote:
On 2/25/07, Yuval Kogman [EMAIL PROTECTED] wrote:
Is there a function that is to this as overload::StrVal is to
stringification?
Wouldn't that just be CORE::ref $obj ?
On 2/26/07, Michael G Schwern [EMAIL PROTECTED] wrote:
Joshua ben Jore wrote:
On 2/25/07, Yuval Kogman [EMAIL PROTECTED] wrote:
Is there a function that is to this as overload::StrVal is to
stringification?
Wouldn't that just be CORE::ref $obj ?
I think Josh is doing something sorta evil
Yuval Kogman wrote:
On Sun, Feb 25, 2007 at 22:34:15 -0800, chromatic wrote:
Why not, I already have half of the other stuff in UNIVERSAL
Just don't tell Adam.
Or me. I have a personal hate relationship with MockObject in this way.
I love MockObject. I hate getting warnings about 3
On Sun, Feb 25, 2007 at 23:22:13 -0800, Joshua ben Jore wrote:
Ick Neither ref nor blessed have never been a booleans before and
even this doesn't change that. Ref couldn't even used to decide if you
had an object because the two false values '' and '0' can both be
returned by objects:
On 2/26/07, Michael G Schwern [EMAIL PROTECTED] wrote:
Joshua ben Jore wrote:
On 2/25/07, Yuval Kogman [EMAIL PROTECTED] wrote:
Is there a function that is to this as overload::StrVal is to
stringification?
Wouldn't that just be CORE::ref $obj ?
No. I don't know how to solve this problem
On Sun, Feb 25, 2007 at 23:55:13 -0800, chromatic wrote:
I wonder if pulling the new DOES() code out of universal.c into a module for
5.9.4 and earlier would alleviate that pain somehow.
I don't know, most of the times I have an if clause trying to figure
out all the possibilities of a value
On 2/26/07, Yuval Kogman [EMAIL PROTECTED] wrote:
On Sun, Feb 25, 2007 at 23:22:13 -0800, Joshua ben Jore wrote:
Ick Neither ref nor blessed have never been a booleans before and
even this doesn't change that. Ref couldn't even used to decide if you
had an object because the two false
On 2/26/07, Joshua ben Jore [EMAIL PROTECTED] wrote:
I'm of the opinion that it is clear and blatantly an error to ever use
ref as a boolean.
One liners and minor snippets where you control the input data would
be an exception IMO.
The correct boolean is defined( blessed( obj ) ) because
On Mon, Feb 26, 2007 at 17:47:23 +0100, demerphq wrote:
On 2/26/07, Joshua ben Jore [EMAIL PROTECTED] wrote:
I'm of the opinion that it is clear and blatantly an error to ever use
ref as a boolean.
One liners and minor snippets where you control the input data would
be an exception IMO.
On 2/26/07, Yuval Kogman [EMAIL PROTECTED] wrote:
On Mon, Feb 26, 2007 at 17:47:23 +0100, demerphq wrote:
On 2/26/07, Joshua ben Jore [EMAIL PROTECTED] wrote:
I'm of the opinion that it is clear and blatantly an error to ever use
ref as a boolean.
One liners and minor snippets where you
On Mon, Feb 26, 2007 at 18:22:21 +0100, demerphq wrote:
I am. Actually my view is that using ref at all unless you control the
input is an error.
Code like Data::Visitor does not need to be as low-level-true as
e.g. Data::Dump::Streamer, but still has to polymorphically handle
objects, refs
On Monday 26 February 2007 06:35, Christopher H. Laco wrote:
Or me. I have a personal hate relationship with MockObject in this way.
I love MockObject. I hate getting warnings about 3 party modules use of
can in my test suite.
Ideally those third parties would fix their buggy code, but after
Yuval Kogman wrote:
Likewise with ref in boolean context, I almost never want the object
to be able to lie to me.
But if it has to work hard to lie, then does it matter?
Yeah, I'm with Yuval here. There seem to be a cold war going on here wrt
identifying an object.
In the beginning we used
On Monday 26 February 2007 13:50, Michael G Schwern wrote:
But what if isa() is broken or has side effects, hmm?
That's not the caller's problem. Fix the broken code. Don't break more code
trying to work around bugs.
That little mantra could have solved a whole lot of this mess.
And what
On Mon, Feb 26, 2007 at 13:50:58 -0800, Michael G Schwern wrote:
Please reconsider autobox.
While I second that for the aforementioned reasons I have an off
topic one too:
That's the only way it'd get accepted. Something that devious has to
be in core to pass off as safe.
--
Yuval Kogman
I've hated it how ref() does the wrong thing so frequently so I wrote
a fix for it. I like to use mock objects to feed fake or proxy objects
to other things but this breaks when things not under my control use
ref() to examine the class of an object.
No longer. Under most circumstances ref()
Is there a function that is to this as overload::StrVal is to
stringification?
I don't see it on the CPAN yet so I figured I'd ask.
The feature is übersweet, and Data::Lazy should make good use of it
too. You++!
Cheers,
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org
On Sunday 25 February 2007 22:26, Joshua ben Jore wrote:
I was going to send this just to chromatic because its his
Test::MockObject but then figured it'd be better to tell perl-qa about
it.
Why not, I already have half of the other stuff in UNIVERSAL
Looks like a great idea to me.
On 2/25/07, Yuval Kogman [EMAIL PROTECTED] wrote:
Is there a function that is to this as overload::StrVal is to
stringification?
No. blessed() doesn't lie to you and I don't change that. I didn't
provide any ref-alike that provide the complete old behavior.
If you read t/basic.t file, you'll
On Sun, Feb 25, 2007 at 22:51:43 -0800, Joshua ben Jore wrote:
On 2/25/07, Yuval Kogman [EMAIL PROTECTED] wrote:
Is there a function that is to this as overload::StrVal is to
stringification?
No. blessed() doesn't lie to you and I don't change that. I didn't
provide any ref-alike that
On Sun, Feb 25, 2007 at 22:34:15 -0800, chromatic wrote:
Why not, I already have half of the other stuff in UNIVERSAL
Just don't tell Adam.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpBQt76ylqNT.pgp
Description: PGP signature
BTW, pure perl blessed() will work:
sub UNIVERSAL::a_sub_not_likely_to_be_here { ref($_[0]) }
sub blessed ($) {
local($@, $SIG{__DIE__}, $SIG{__WARN__});
length(ref($_[0]))
? eval { $_[0]-a_sub_not_likely_to_be_here }
: undef
On 2/25/07, Yuval Kogman [EMAIL PROTECTED] wrote:
On Sun, Feb 25, 2007 at 22:51:43 -0800, Joshua ben Jore wrote:
On 2/25/07, Yuval Kogman [EMAIL PROTECTED] wrote:
Is there a function that is to this as overload::StrVal is to
stringification?
No. blessed() doesn't lie to you and I don't
On Sunday 25 February 2007 23:04, Yuval Kogman wrote:
Hmm I usually do
if ( ref $x ) {
if ( my $class = blessed $x ) {
} else {
}
}
in code that tries to be very duck friendly.
I wonder if pulling the new DOES() code
46 matches
Mail list logo
