Front page | perl.perl5.porters |
Postings from September 2011
Re: Package:: still ambiguous
Thread Previous
|
Thread Next
From:
Stevan Little
Date:
September 14, 2011 08:55
Subject:
Re: Package:: still ambiguous
Message ID:
7E639C03-2C48-4F1C-A610-40F1D230CE69@iinteractive.com
On Sep 14, 2011, at 11:10 AM, Zefram wrote:
> Nicholas Clark wrote:
>> On Wed, Sep 14, 2011 at 01:55:15PM +0100, Zefram wrote:
>>> probably end up implemented as an svtype, SVt_PVPK.
>>
>> On boy, is that going to break any XS code that processes hashes,
>> identifies hashes as SvTYPE(sv) == SVt_PVHV, and is used by any other
>> code that passes in stashes, knowing that stashes are just hashes.
>
> I imagine the namespace part of a package continuing to be implemented
> as a hash. %Package:: can continue to refer to that hash, which can
> continue to be an SVt_PVHV, without that having to be the same as the
> package object. (I have a nagging concern about extra memory usage if we
> separate stash from package object, but I doubt it would be substantial.)
> Of course, any version of this will break much code that does more
> interesting things with stashes. I think it's OK to break most stash
> stuff, but anything we're presenting as a hash should be as normal a
> hash as it can be.
>
> Here's another concept for package objects that I came up with this
> morning: the package can be represented by an object that's blessed
> into itself. So ref($pkg) gives you the package name, preserving the
> "ref($_[0]) || $_[0]" idiom, and providing a natural way to dispatch
> class methods. Blessing the package object into some other package (one
> of my sources of trouble) would rather obviously constitute breaking the
> package, meriting a "don't do that then" response. Downside is increased
> likelihood of mistaking the package object for an instance of the class,
> especially if the package object is actually the HV stash.
>
> Also, a concept for how ref($obj) should behave on anonymous classes:
> make the class not actually anonymous, just weakly referenced by its name.
> new_anon_package() gensyms a name, sets up a package by that name, and
> returns a ref to the package object. However, the reference to the stash
> or package object from the name is weak, so the package only continues to
> exist as long as there's a hard ref to the package object or an instance.
> So it doesn't survive unduly long if it was a temporary class, yet it
> still has a fully working name as long as it does survive.
>
> These are just concepts, of course, not complete designs. Anyone else
> want to join in at this blue sky stage?
Sure, I will.
So, one thing I noticed while playing around with Rafl's Package::Anon
experiment (which does something similar to what your new_anon_package
is proposing). How do you handle inheritance?
My (limited) understanding of the mro functionality is that it is still
very tied to string lookup for package names. And obviously @ISA is also
based on string lookup as well.
So an anon-package would obviously have a string name of some kind, but
how could we be sure that if that string was in an @ISA somewhere that
the package would not get GC-ed?
Here is a short example ...
{
package Foo;
sub bar { 'Foo::bar' }
}
{
my $anon = new_anon_package();
$anon{baz} = sub { 'ANON::baz' };
push @Foo::ISA => ref($anon);
Foo->baz; # this should work here
}
Foo->baz; # but will this work here?
Additionally, I am not so sure that blessing the package "object" into
itself is not an abuse of bless, which while it might work, is just
another bit of Perl OO weirdness that would lead to problems down the
road.
- Stevan
Thread Previous
|
Thread Next