From: Mark Hahn <mchahn@...>
Date: 2001-11-01T01:45:11+09:00
Subject: [ruby-talk:23983] Re: Overiding a method in another module


ts> but I'm not really sure that it's a good idea to give
ts> the possibility to have ::Class. Any thought ?

I am not a language design expert.  I can only see a problem that I have and
I think this problem is a valid one.  I think maybe that no current OO
technique can solve my problem.

::Class would help my problem.  Why would ::Class be bad?


ts>   * def Class#method .. end ??
ts>   * def Foo::Bar::baz() .. end ??

Aren't both of these just shortcuts for:

	class Class
	  def method
	  end
	end

	-- and --

	module Foo
	  def Bar::baz
	  end
	end

I cannot give opinion on whether shortcuts are useful or not.  They do not
change what I can do, so I don't care very much.


-----Original Message-----
From: ts [mailto:decoux@moulon.inra.fr]
Sent: Wednesday, October 31, 2001 8:08 AM
To: ruby-talk ML
Cc: ruby-talk@ruby-lang.org
Subject: [ruby-talk:23973] Re: Overiding a method in another module


>>>>> "M" == Mark Hahn <mchahn@facelink.com> writes:

 Well, the response was given by another person, just a small precision

M> module M2
M>   class M1::C1      <=== gives syntax error

 This is in the ToDo

   * class Foo::Bar<Baz .. end, module Boo::Bar .. end

 but in your case, even if implemented, it will not work because it look at
 M2::M1::C1. You must, if one day it's implemented, write it as

   module M2
      class ::M1::C1 # shortly ::C1 in your case
      end
   end

 but I'm not really sure that it's a good idea to give the possibility to
 have ::Class. Any thought ?

pigeon% cat b.rb
#!./ruby
module M1
  class C1
    def meth
      p 'M1.meth'
    end
  end
end
include M1
C1.new.meth

module M2
  class ::C1
    def meth
      p 'M2.meth'
    end
  end
end

C1.new.meth
pigeon%

pigeon% b.rb
"M1.meth"
"M2.meth"
pigeon%

 There is also this in the ToDo

   * def Class#method .. end ??
   * def Foo::Bar::baz() .. end ??

 the first (Class#method) like class A::B, seems usefull and easy to
 implement.

 I've found, but probably I'm wrong, that the second make the parser more
 complex and don't give something usefull. For example, if I'm right

   def Foo::Bar::baz()

 must be interpreted as

   module Foo
      def Bar::baz
      end
   end

 and this mean that this syntax is usefull only if the class Foo::Bar exist
 and I don't see any interest to have this syntax when it's possible to
write

   class Foo::Bar
      def self.baz
      end
   end

 An example

pigeon% cat b.rb
#!./ruby -rii
dump
def A::B#method(a)
end

def A::C::method(b)
end
pigeon%

pigeon% b.rb
eval_tree
BLOCK
  NEWLINE <./b.rb:2>
  VCALL dump
  NEWLINE <./b.rb:3>

  MODCLASS A
    SCOPE
      NEWLINE <./b.rb:3>

      MODCLASS B
        SCOPE
          NEWLINE <./b.rb:3>

          DEFN method
            SCOPE
              ARGS(a)



  NEWLINE <./b.rb:6>

  MODCLASS A
    SCOPE
      NEWLINE <./b.rb:6>

      DEFS
        CONST C method
        SCOPE
          ARGS(b)



./b.rb: uninitialized constant C at A (NameError)
pigeon%

 What others think about these 2 syntax  (def Class#method(), def
 A::B::method()) ? Usefull or not ?



Guy Decoux