[#5563] Non-overridable and non-redefinable methods — Eric Mahurin <eric_mahurin@...>

Lately, I've been thinking about the future of ruby

44 messages 2005/08/19
[#5564] Re: Non-overridable and non-redefinable methods — Austin Ziegler <halostatue@...> 2005/08/19

On 8/19/05, Eric Mahurin <eric_mahurin@yahoo.com> wrote:

[#5571] Re: Non-overridable and non-redefinable methods — Eric Mahurin <eric_mahurin@...> 2005/08/19

--- Austin Ziegler <halostatue@gmail.com> wrote:

[#5574] Re: Non-overridable and non-redefinable methods — TRANS <transfire@...> 2005/08/20

Just wanted to add a few things.

[#5581] Re: Non-overridable and non-redefinable methods — Austin Ziegler <halostatue@...> 2005/08/20

On 8/19/05, TRANS <transfire@gmail.com> wrote:

[#5583] Re: Non-overridable and non-redefinable methods — "David A. Black" <dblack@...> 2005/08/20

Hi --

[#5585] Re: Non-overridable and non-redefinable methods — Eric Mahurin <eric_mahurin@...> 2005/08/20

--- "David A. Black" <dblack@wobblini.net> wrote:

[#5609] Pathname#walk for traversing path nodes (patch) — ES <ruby-ml@...>

Here is a small addition to Pathname against 1.9, probably suited

20 messages 2005/08/22

Re: Pathname#walk for traversing path nodes (patch)

From: "daz" <dooby@...10.karoo.co.uk>
Date: 2005-08-23 13:05:32 UTC
List: ruby-core #5646
David A. Black

>
> On Tue, 23 Aug 2005, daz wrote:
>
> >
> > Tanaka Akira wrote:
> >
> >> David A. Black writes:
> >>
> >>> Maybe "scan".
> >>
> >
> > I've followed the recent protests that a Pathname is not
> > a String and, here, the name of a String method is
> > suggested.  An understanding of the operation of either
> > #scan method would provide no clue to the operation of
> > the other.
> > This, IMHO, is what leads to dilution of meaning,
> > then dilution of understanding.  I object strongly.
>
> I don't think any given class can monopolize a method name, unless
> there's a really close connection.  (And in that case it would be
> monopolization by default, since no other objects would want the
> name.)
>

Perhaps - but I think the name "scan" should be reserved for
methods which are doing some kind of scanning (i.e. discovery)
rather that iterating over components which are invariant and
well understood by the class.


daz





In This Thread