ruby 1.8: Merkwürdiger Fehler mit require

Eventuell gibt es noch einen anderes "TestModule" was da kollidiert?

Ich habs mit verschiedenen Namen und auch vollständiger Pfadangabe bei 
require versucht - immer derselbe Mist.

Die einzige Variable bisher ist die Fehlermeldung selbst:

Dort, wo ich erstmals darüber gestolpert bin, meint Ruby,
  undefined method
während es in der Testumgebung
  private method called
heißt.

> private method `test' called for TestModule:Module

da steht "private"

musst wohl public definieren.. (wie auch immer das geht)

Robert L. schrieb:
> nachtrag: wobei es ausschaut als hättest du immer noch probleme mit
> "instancen und klassen"

Dafür, daß du nicht die Spur von einer Ahnung hast, nimmst du den Mund 
ganz schön voll...

Hallo Uhu,

ändere die Methoden-Deklaration:

1

  def self.test

2

    puts 'test'

3

  end

Sollte dann eigentlich funktionieren - mit/ohne include

mfg

O. Brecht

Olaf Brecht schrieb:
> ändere die Methoden-Deklaration:
>   def self.test
>     puts 'test'
>   end

Interessanter Vorschlag.

def self.test macht sowas ähnliches, wie eine Klassenmethode bei einer 
Klasse daraus. Nur was ist das genau? Eine Modul-Methode? Ein Modul hat 
doch keine Eigenklasse? Oder doch?

Was ist der Unterschied zwischen test2 und test2:

1

module Test

2

   def test1

3

   end

4

5

   def self.test2

6

   end

7

end

D. I. schrieb:
> Schlagmichtot, aber soweit ich weiß sind Module nicht instantiierbar und
> deswegen macht man die Methoden da drin statisch durch self.bla, so dass
> es dann klappt.

Nach meinen Erfahrungen mit den @@-Variablen in Klassen halte ich es 
doch für wünschenswert, dahinter zu kommen, was da genau passiert.

Der Effekt, auf den dieser Thread zurück geht, scheint wohl ein Bug zu 
sein.

> Warum verwendest du noch Ruby 1.8 statt 1.9 oder nun 2.0?

Das ist der kleinste gemeinsame Nenner auf Ubuntu 10.04 LTS und 12.04 
LTS.

D. I. schrieb:
> Achso du verwendest kein rvm, oder?

Doch, aber das Skript soll auch auf einem "nackten" System laufen.

Hallo Uhu

schau bitte mal hier:
  1. http://wiki.ruby-portal.de/Modul oder
  2. http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html

mfg

O. Brecht

Uhu Uhuhu schrieb:
> Dafür, daß du nicht die Spur von einer Ahnung hast, nimmst du den Mund
> ganz schön voll...

oha...


>Mehrfachvererbung: Mixins

>....

>module Foo
>
>  def bar
>    "bar"
>  end
>
>end

>puts Foo.bar #=> NoMethodError


>Das Problem ist hier offensichtlich, dass bar keine Modulmethode von Foo
>ist, sondern eine Instanzmethode.


ist witzig, obwohl ich tatsächlich keine ahnung hab von ruby...
war ich also mit meiner Vermutung, dass das (immer noch) dein 
Instanzen/Klassen "problem" ist, nicht ganz so weit entfernt...

Olaf Brecht schrieb:
> schau bitte mal hier:
>   1. http://wiki.ruby-portal.de/Modul oder
>   2. http://www.ruby-doc.org/docs/ProgrammingRuby/html/...

Ok, man kann das Ganze mit irb/pry explorieren:

1

module M

2

   def self.m

3

     puts 'm'

4

   end  

5

   def mm

6

     puts 'mm'

7

   end  

8

end

9

10

M.instance_methods

11

=> ["mm"]

12

M.singleton_methods

13

=> ["m"]

Die Singleton-Methoden nutzen den Modul als Namespace,
die Instanz-Methoden - weil Module nicht instantiiert werden können - 
können nur in ein anderes Objekt eingemischt werden.

Sind die Instanz-Methoden ungebundene Methoden, ähnlich wie sie 
Method::unbind liefert?

1

"test".method(:inspect).unbind

2

=> #<UnboundMethod: String#inspect>

3

String.method(:inspect).unbind

4

=> #<UnboundMethod: Class(Kernel)#inspect>

Ok, die Instanz-Methoden in einem Modul muß man sich als "Sack von 
UnboundMethods" vorstellen:

1

M.instance_method(:mm)

2

=> #<UnboundMethod: M#mm>