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

Re: Package:: still ambiguous

Thread Previous
Stevan Little
September 13, 2011 10:28
Re: Package:: still ambiguous
Message ID:

On Sep 13, 2011, at 10:21 AM, Zefram wrote:
> I'm dubious about using stashes themselves, as they currently exist,
> as the core class metaobject.  I think the visible metaobject should
> be visibly of a different type from hashes.  That's not a major hassle:
> stashes are already somewhat more magical than ordinary hashes.

I completely agree with you, I really don't think we want to attach more behavior and special meaning to stashes. One of the really difficult and problematic parts of Moose has always been dealing with the underlying stashes and mapping them to a meta-object in a sensible way. 

On Sep 13, 2011, at 12:18 PM, Zefram wrote:
> Rafael Garcia-Suarez wrote:
>> So, if I understand that last paragraph, that implies new syntax ?
> Depends what you count as new syntax.  Certainly some new semantics,
> including new builtin functions, but we don't need to add to perly.y.
> I imagine something like
> 	$pkg = package_metaobject("Foo::Bar");
> 	# or: $pkg = new_anon_package();
> 	$obj = $pkg->new();   # unambiguously call class method
> 	$obj = bless({}, $pkg);   # only way to bless into anon package
> 	$pkg = ref_metaobject($obj);   # only for blessed objects
> 	use strict_packages;
> 	$obj = Foo::Bar->new();   # error

I would really like to avoid calling this a "metaobject" because that really is not what it is and the term somewhat implies the existence of a greater MOP somewhere out there. 

> Obvious sources of trouble:
> 	$pkg = package_metaobject("Foo::Bar");
> 	bless($pkg, "Heh::Heh");
> 	$obj = $pkg->new;   # Foo::Bar->new or Heh::Heh->new?
> 	sub new {
> 		# current idiom, breaks if $_[0] is a package metaobject
> 		my $class = ref($_[0]) || $_[0];
> 	}
> 	$pkg = new_anon_package();
> 	$obj = bless({}, $pkg);
> 	$class = ref($pkg);   # surprising metaobject or useless string?
> So we need some non-trivial thought about how the semantics will fit
> together.  I'm determined that we won't get the kind of ill-thought-out
> mess we've so often had before.

Agreed, you basically start to have a real problem here because it attempts to draw a line between class and instance methods and Perl OO really does not make that distinction at all. This is one of the parts of the current Perl OO that is (IMO) totally broken, but unfortunately so deeply entrenched within Perl OO culture that you probably can't fix it without breaking things.

- Stevan

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About