From: "Berger, Daniel" <Daniel.Berger@...>
Date: 2007-01-26T05:02:57+09:00
Subject: Re: new method dispatch rule (matz' proposal)

> -----Original Message-----
> From: Yukihiro Matsumoto [mailto:matz@ruby-lang.org] 
> Sent: Thursday, January 25, 2007 12:06 PM
> To: ruby-core@ruby-lang.org
> Subject: Re: new method dispatch rule (matz' proposal)
> 
> 
> 
> In message "Re: new method dispatch rule (matz' proposal)"
>     on Fri, 26 Jan 2007 03:40:28 +0900, Joshua Haberman 
> <joshua@reverberate.org> writes:
> 
> |Could you also summarize the intent behind these schemes?  Rules are 
> |just the means for achieving a goal -- what is the goal 
> itself?  What 
> |deficiencies of the status quo will these proposals address?
> 
> It's in [ruby-core:10022].  To rephrase:
> 
>   The point is that, as Ruby grows, the requirement for managing name
>   conflict is raising.  I think we need something that can safely used
>   to define utility _functions_, without affecting public method set,
>   nor worrying about name conflict.  But the current "private" nor one
>   you've described above cannot address this issue.
> 
> Does this make sense?

If naming conflicts really are a concern as Ruby grows, then we need to
think past private methods, and look at modules and mixin rules as well.

Is it time for Traits?

http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf

Perl 6 will have Traits (which they're calling "Roles"). Fortress also
implemented traits. I'm personally not a fan of them, but I'll try to
keep an open mind. :)

Regards,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.