[#11439] comments needed for Random class — "NAKAMURA, Hiroshi" <nakahiro@...>

-----BEGIN PGP SIGNED MESSAGE-----

15 messages 2007/06/12

[#11450] Re: new method dispatch rule (matz' proposal) — David Flanagan <david@...>

This is a late response to the very long thread that started back in

17 messages 2007/06/13

[#11482] Ruby Changes Its Mind About Non-Word Characters — James Edward Gray II <james@...>

Does this look like a bug to anyone else?

10 messages 2007/06/16

[#11505] Question about the patchlevel release cycle — Sylvain Joyeux <sylvain.joyeux@...4x.org>

1.8.6 thread support was broken in bad ways. It stayed for three months

20 messages 2007/06/20
[#11512] Re: Question about the patchlevel release cycle — Urabe Shyouhei <shyouhei@...> 2007/06/20

Hi, I'm the 1.8.6 branch manager.

[#11543] Re: Apple reportedly to ship with ruby 1.8.6-p36 unless informed what to patch — James Edward Gray II <james@...>

On Jun 27, 2007, at 4:47 PM, Bill Kelly wrote:

10 messages 2007/06/27

Re: new method dispatch rule (matz' proposal)

From: TRANS <transfire@...>
Date: 2007-06-16 23:53:12 UTC
List: ruby-core #11490
On 6/16/07, Steven Lumos <steven@lumos.us> wrote:
> David Flanagan <david@davidflanagan.com> writes:
> > Daniel DeLorme wrote:
> >> How is this hidden from subclasses? Or did I miss something?
> >>
> >
> > Sorry, everyone!  As Daniel and others have pointed out my analogy of
> > non-inheritable local methods to instance variables makes no sense
> > since instance variables are inheritable.  I'm feeling pretty
> > embarassed by that.
> >
> > However, I do stand by my argument that it would be good to have some
> > kind of non-inheritable really-private kind of method in Ruby.  And I
> > think that distinguishing those methods with punctuation in their
> > names would be an easy way to get there without having to jigger with
> > the existing method dispatch rules.
> >
> >       David
>
> Maybe I'm confused, which of these are you talking about?
>
> class A
>   def m; @f(); end
>   def @f; true; end
> end
>
> class B < A
> end
>
> B.new.m  #=> Error: The mighty class author requires that you
>              reimplement @f.
>
> or
>
> class B < A
>   def @f; false; end
>   #=> Error: The mighty class author forbids you to reimplement @f
> end
>
> Steve

I think what is meant is:

   #=> Error: The mighty class author forbids you to reimplement @f.

I was thinking about this some more. While I understand the argument
that no instance method should truly be untouchable, it seems to me
that these local-private methods have an even stronger use case in
mixins. For example, right now I'm working on a Package class. It has
lots of attributes. I would like to add a #build method to it,
however, there is a lot of support structure that goes with #build,
such as the inclusion of FileUtils. While I could probably get away
with it, I feel skittish about adding that many more methods to
Package. It's just getting to be too much. So I made a Builder class
and have elected to delegate. That works, but its a bit more work. If
instead I could make those support methods local-private to the
module, than I could just include the module and achieve the same
effect much more easily.

T.

In This Thread