# 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