The question is, can I create a method on a class with a different scope than
the class itself has?  Put another way, it seems like

module ArrayMath;

sub sum(Array $this){
    $this.reduce(operator::+, 0);
}

method Array::sum(;){
    .reduce(operator::+, 0);
}


(modulo syntax errors) then both should have the same visibility (ie, module
level only, unless they're somehow exported (what's that in perl6, "is
public"?)).  So the question of namespace becomes moot, because just because
it's a method on Array doesn't mean it's accessible anywhere a similar sub
wouldn't be.  Either could be exported and made globally available, but I don't
see why they should have to be.  Or am I missing something?

> On Tue, Jan 21, 2003 at 09:20:04AM -0800, Michael Lazzaro wrote:
> > 
> > On Tuesday, January 21, 2003, at 02:04  AM, Graham Barr wrote:
> > > If the function form of map/grep were to be removed, which has been 
> > > suggested,
> > > and the <~ form maps to methods. How would you go about defining a 
> > > utility
> > > module similar to List::Util that uses the same syntax as map/grep but
> > > without making the subs methods on the global ARRAY package ?
> > 
> > If you want the method to be available everywhere,
> 
> But I don't
> 
> > you probably 
> > _should_ make it a method of the global Array class.
> 
> Thats like trying to wite a whole perl5 application in main
> without any packages
> 
> >  More typically, 
> > perhaps, you'd only be using your new method to operate on certain 
> > arrays that you use, in which case you would make a new class for those 
> > particular arrays, so your new method would work only on the specific 
> > arrays you intended it to:
> 
> Thats not always possible. Those Arrays may be passed to me from
> somewhere else, so I have no control over thier class.
> 
> > I don't see any problem (other than maybe a philosophical objection) 
> > with making them methods of Array, though, if they're valuable enough.  
> > That certainly would seem the common Perl thing to do.
> 
> No, namespaces were invented for a reason.
> 
> Graham.
> 

-- 
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/

All of our customer service representatives are on vacation.  Please hold for
the next available representative.

Reply via email to