# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #53302]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53302 >
Short version: Methods should not be automatically entered into
a namespace, as they are now. Instead we should provide a flag
(I propose ":export") to do so. Thus we have:
.sub 'abc' :method # 'abc' method, not in namespace
.sub 'def' :method :export # 'def' method, 'def' in namespace
.sub 'ghi' :method :export('xyz') # 'ghi' method, 'xyz' in namespace
I chose ":export" because it's roughly analogous to the meaning
of the "is export" trait on methods in Perl 6. I don't need the
:export('xyz') form at the moment, but Allison had suggested something
similar in RT#48631 so I'm including it here.
Background: Many of you may recall a similar discussion last
December in RT#48631, where I essentially argued in favor of
Parrot's current behavior of methods being automatically entered
into a namespace. Based on a couple of Rakudo items I've now
come around to the opposite conclusion. Coke suggested opening
a new ticket and referring to the old one.
Currently Parrot automatically places all methods into the class'
namespace. Consider
.namespace ['Foo']
.sub 'abc' :method
...
.end
This creates a method 'abc' for objects of class Foo, but it also
places an entry for 'abc' in the ['Foo'] namespace. This causes
problems for namespace-based lookups (and we had an instance of
this in a Rakudo test program earlier today).
In previous discussions I had proposed that we keep the default
as-is, and use the :anon flag to indicate that a method should
not be entered in a namespace. In RT#48631 Allison suggested
the opposite -- methods aren't in a namespace by default, but
a :namespace flag indicates when they should be (and an optional
parameter specifies a different name).
I now agree with Allison's model, but since I was initially
confused by ":namespace" (and others may be confused also)
I propose :export as a flag name instead.
Regardless of which model is chosen, we need a way to specify
the opposite model in PIR. Otherwise we have to do some
runtime (:load :init) manipulation of namespaces in order to
get the opposite behavior.
Comments, suggestions, patches for the above welcome.
Pm
