[#9869] a block argument within a block which argument has the same name leaks — <noreply@...>

Bugs item #7680, was opened at 2007-01-08 22:53

34 messages 2007/01/08
[#9871] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/08

Hi,

[#9872] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Evan Webb <evan@...> 2007/01/08

On Jan 8, 2007, at 2:30 PM, Yukihiro Matsumoto wrote:

[#9873] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/08

Hi,

[#9876] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — dblack@... 2007/01/09

Hi --

[#9878] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/09

Hi,

[#9879] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — dblack@... 2007/01/09

Hi --

[#9880] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/09

Hi,

[#9882] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Evan Phoenix <evan@...> 2007/01/09

[#9885] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/09

Hi,

[#9887] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Evan Phoenix <evan@...> 2007/01/09

[#9888] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Charles Oliver Nutter <charles.nutter@...> 2007/01/09

Evan Phoenix wrote:

[#9892] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/09

Hi,

[#9899] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Charles Oliver Nutter <charles.nutter@...> 2007/01/10

Yukihiro Matsumoto wrote:

[#9904] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/10

Hi,

[#9960] Scoping and locating definitions — Jos Backus <jos@...>

Consider the following:

17 messages 2007/01/18
[#9964] Re: Scoping and locating definitions — Pit Capitain <pit@...> 2007/01/19

Jos Backus schrieb:

[#9966] Re: Scoping and locating definitions — Jos Backus <jos@...> 2007/01/19

On Fri, Jan 19, 2007 at 06:40:03PM +0900, Pit Capitain wrote:

[#9972] Re: Scoping and locating definitions — Jos Backus <jos@...> 2007/01/19

On Sat, Jan 20, 2007 at 02:18:19AM +0900, Jos Backus wrote:

[#9996] new method dispatch rule (matz' proposal) — SASADA Koichi <ko1@...>

Hi,

50 messages 2007/01/23
[#10002] Re: new method dispatch rule (matz' proposal) — Daniel DeLorme <dan-ml@...42.com> 2007/01/23

SASADA Koichi wrote:

[#10003] Re: new method dispatch rule (matz' proposal) — Yukihiro Matsumoto <matz@...> 2007/01/23

Hi,

[#10004] Re: new method dispatch rule (matz' proposal) — James Edward Gray II <james@...> 2007/01/23

On Jan 23, 2007, at 7:41 AM, Yukihiro Matsumoto wrote:

[#10017] Re: new method dispatch rule (matz' proposal) — Daniel DeLorme <dan-ml@...42.com> 2007/01/24

Yukihiro Matsumoto wrote:

[#10018] Re: new method dispatch rule (matz' proposal) — Yukihiro Matsumoto <matz@...> 2007/01/24

Hi,

[#10024] Re: new method dispatch rule (matz' proposal) — Daniel DeLorme <dan-ml@...42.com> 2007/01/24

Yukihiro Matsumoto wrote:

[#10027] Re: new method dispatch rule (matz' proposal) — Yukihiro Matsumoto <matz@...> 2007/01/24

Hi,

[#10048] Re: new method dispatch rule (matz' proposal) — Evan Phoenix <evan@...> 2007/01/25

The more this discussion goes on, the more I worry that Joe Q Public

[#10019] stable branch policy & schedule for 1.8.6 — "Akinori MUSHA" <knu@...>

Core developers,

29 messages 2007/01/24
[#10021] Re: stable branch policy & schedule for 1.8.6 — Charles Oliver Nutter <charles.nutter@...> 2007/01/24

Akinori MUSHA wrote:

[#10032] Re: stable branch policy & schedule for 1.8.6 — Joel VanderWerf <vjoel@...> 2007/01/24

Charles Oliver Nutter wrote:

[#10085] Collaborative Ruby Language Specification — "John Lam (CLR)" <jflam@...>

Hi Everyone,

36 messages 2007/01/28
[#10108] Re: Collaborative Ruby Language Specification — Charles Oliver Nutter <charles.nutter@...> 2007/01/29

M. Edward (Ed) Borasky wrote:

[#10112] Re: Collaborative Ruby Language Specification — "Eustaquio Rangel de Oliveira Jr." <eustaquiorangel@...> 2007/01/30

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

[#10114] add usage of uri.userinfo to open-uri.rb — <noreply@...>

Patches item #8309, was opened at 2007-01-30 15:25

16 messages 2007/01/30
[#10131] Re: [ ruby-Patches-8309 ] add usage of uri.userinfo to open-uri.rb — Yukihiro Matsumoto <matz@...> 2007/01/31

[#10132] Re: [ ruby-Patches-8309 ] add usage of uri.userinfo to open-uri.rb — Paulo Kh <paulo.koch@...> 2007/01/31

On 2007/01/31, at 06:07, Yukihiro Matsumoto wrote:

[#10137] Re: [ ruby-Patches-8309 ] add usage of uri.userinfo to open-uri.rb — Yukihiro Matsumoto <matz@...> 2007/01/31

Hi,

[#10139] Re: [ ruby-Patches-8309 ] add usage of uri.userinfo to open-uri.rb — Sam Roberts <sroberts@...> 2007/01/31

On Thu, Feb 01, 2007 at 01:19:34AM +0900, Yukihiro Matsumoto wrote:

[#10143] Re: [ ruby-Patches-8309 ] add usage of uri.userinfo to open-uri.rb — Yukihiro Matsumoto <matz@...> 2007/02/01

Hi,

Re: new method dispatch rule (matz' proposal)

From: Hugh Sasse <hgs@...>
Date: 2007-01-23 15:22:54 UTC
List: ruby-core #10008
On Tue, 23 Jan 2007, Yukihiro Matsumoto wrote:

> Hi,
> 
> In message "Re: new method dispatch rule (matz' proposal)"
>     on Tue, 23 Jan 2007 23:26:17 +0900, Hugh Sasse <hgs@dmu.ac.uk> writes:
> 
> |Interesting.  Doesn't this mean more care will be needed to develop
> |private interfaces prior to them becoming public?
> 
> I don't think so.  Polymorphism wouldn't happen for private methods by
> the new look-up scheme, so that we need less care for method name
> conflict.  We have to care only for methods tried to share same name
> in the same class/module.
> 
> |Also, to get the redefined bar method in a call to foo in the above
> |example, class B would have to have its own implementation of foo.
> |I see this as leading to code duplication, which breaks DRY.
> 
> I am not sure what you meant.  Do you want private AND overridable

Aha!  I see what you mean now.  For B to 'know' that bar must be 
overridden breaks encapsulation anyway.  So the unifying idea I
sought is "proper privacy".   

What I meant was that since foo calls A's private method bar, when B
redefines bar, in order to get B#foo to call B's bar, one needs a
re-definition of foo. Otherwise B#foo will always call A#bar.  Thus
one has to write a foo method for B which is a textual copy of A's
foo method (in order to get the *same* behaviour, but calling B#bar).
That seems to be duplicated code, rather than re-use.  But I can 
now squash my argument, because such duplication is only known to 
be duplication if encapsulation is broken, invading A's privacy.

However, I can see that this proposal means defining private methods
in a subclass won't break existing methods of parent classes, without
the child class having to avoid name clashes.  And that is a
simplification.

> methods?  I am vaguely thinking of changing protected for that

Yes, that would override [:-)] my remaining discomfort.

> purpose (or introducing a new visibility).

> 
> 							matz.
> 

Thank you.  I think you've helped me argue myself round to your
position :-)

        Hugh

In This Thread