develooper Front page | perl.perl5.porters | Postings from September 2000

Re: bless(REF, REF)

Thread Previous | Thread Next
From:
sthoenna
Date:
September 2, 2000 23:39
Subject:
Re: bless(REF, REF)
Message ID:
M/es5gzkgqxQ092yn@efn.org
In article <20000902092413.A28679@the.earth.li>,
Simon Cozens <simon@cozens.net> wrote:
> 
> In perldelta:
> The semantics of bless(REF, REF) were unclear and until someone proves
> it to make some sense, it is forbidden.
> 
> Bah. I had some code which depends on this. Let me try and explain.
> One of the nice things about Perl's OO model is that if you don't like it, you
> can write your own - in Perl. By providing a replacement bless() and
> UNIVERSAL::AUTOLOAD you can pretty much come up with any kind of OO you like.
> (No, I don't have an article on that, yet.)
> 
> One of the things I did was to make classes first-class variables, instead of 
> packages, so you can pass them around and manipulate them with subroutines. I
> did this by making classes into references. I've had to work around this
> additional restriction in 5.7.0 by having a global hash of classes keyed to
> their stringified references, but I'd really rather not have to. In fact, I'd
> rather bless() took references and ref() was able to produce real references
> instead of stringified ones. I'm happy to patch this (for 5.7.1, naturally) if
> it's deemed to make sense.

Giving the ref overload magic will suppress the warning.  You don't even
have to overload "".

I had suggested also suppressing the warning if the package actually
existed.  This might be the way to go.  C< %{"${x}::"} > creates
an arbitrary package $x (with implicit s/'/::/g, of course).

Whatever you do, make sure it still fails where someone calls
$instance->new instead of Class::->new where the class isn't expecting
a reference.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About