Front page | perl.perl5.porters |
Postings from September 2011
On 13 September 2011 18:18, Zefram <zefram@fysh.org> 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
That works with $pkg being a string, right now.
> $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
>
> 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.
if $pkg is a metaobject, it's tempting to add introspection methods to
it. (Like $pkg->keys() to return the stash keys, to give a simple
example). But they could clash with methods of the class it
represents.
I would prefer avoiding thinking about $pkg as a special kind of
object. It looks more like a new first-class feature of the language
(which could be called simply "package" or "namespace")
Thread Previous
|
Thread Next