From: Benoit Daloze <eregontp@...>
Date: 2012-05-12T04:32:37+09:00
Subject: [ruby-core:45000] Re: [ruby-trunk - Feature #5632] Attempt to open included class shades it instead.

On 9 May 2012 13:49, boris_stitnicky (Boris Stitnicky)
<boris@iis.sinica.edu.tw> wrote:
>
> Issue #5632 has been updated by boris_stitnicky (Boris Stitnicky).
>
>
> Back to the original issue, having
> module A; class X; def hello; puts 'hello' end end end
> module B; include A end
>
> then using "class X" statement inside B module does not behave as you say,
> "X = defined?(X) ? X : Class.new", but as
> "X = self.constants(false).include?(:X) ? X : Class.new",

Indeed, that's what I wanted to say, thanks for finding my error.

> From retrospective, there are 3 logically justified behaviors for "class Transition"
> statement in this situation:
>
> 1. Opening the ancestor's class, explicitly:
> class Petri::Transition; # do modifications
> end
> This is most "logical", because Transition constant is already there, but
> opening ancestor's assets in offspring modules is hardly a good habit.
> 2. Creation of a brand new class, explicitly:
> Transition = Class.new; class Transition; # do modifications
> end
> Less logical, but justifiable behavior, encouraging bad habits less.
> 3. Operation on a subclass, explicitly:
> class Transition < Transition; # do modifications
> end
> Perhaps least logical, but I suspect that most frequently needed behavior.

I would not want the class keyword without "< ParentClass" to inherit
from anything else than Object.

The main class keyword use is to create a class, so it makes sense to
me it reopens only if it is in the strictly same context
(self.constants(false)).
But I'll agree with you "class X < X" is rather confusing. I would
rather write it "class Transition < Petri::Transition" in your case,
to be clear on the intention.

I believe a good documentation on constants would be a great addition.