Objektmethoden auflisten/Frage zu SUPER

Hallo,

gegeben sei ein Objekt $obj. Ich möchte eine Liste aller von
diesem Objekt unterstützten Methoden, auch solche, die es
geerbt hat (mittels ISA und/oder UNIVERSAL, mit Angabe
der jeweilige Klasse, von der die Methode geerbt wurde).

Hat jemand Code dafür bzw. gibt es ein Modul, das diese
Funktionalität bereitstellt?

In diesem Zusammenhang auch noch eine (hoffentlich nicht
allzu blöde) Frage:

Wenn in einer Klasse

package ClassC;

@ISA = qw(ClassA ClassB);

eingetragen ist, und diese beiden Klassen jeweils eine Methode
'Meth' unterstützen, welche Methode wird dann mit folgender
Anweisung aufgerufen?

$obj->SUPER::Meth();

Sehe ich es richtig, dass

$obj->Meth(); und
$obj->SUPER::Meth();

identisch sind, wenn die Klasse von $obj keine Methode 'Meth'
vorsieht?

Danke für eure Antworten,

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Objektmethoden auflisten/Frage zu SUPER

Ferry Bolhar wrote:

> gegeben sei ein Objekt $obj. Ich möchte eine Liste aller von
> diesem Objekt unterstützten Methoden, auch solche, die es
> geerbt hat (mittels ISA und/oder UNIVERSAL, mit Angabe
> der jeweilige Klasse, von der die Methode geerbt wurde).
>
> Hat jemand Code dafür bzw. gibt es ein Modul, das diese
> Funktionalität bereitstellt?

Ich habe das mal implementiert. Ob es ein Modul
dafür gibt, weiß ich nicht.

> In diesem Zusammenhang auch noch eine (hoffentlich nicht
> allzu blöde) Frage:
>
> Wenn in einer Klasse
>
> package ClassC;
>
> @ISA = qw(ClassA ClassB);
>
> eingetragen ist, und diese beiden Klassen jeweils eine Methode
> 'Meth' unterstützen, welche Methode wird dann mit folgender
> Anweisung aufgerufen?
>
> $obj->SUPER::Meth();

Perl macht eine Tiefensuche, links nach rechts. Es
wird also abgeklappert: ClassA, die Basisklassen von
ClassA, ClassB, die Basisklassen von ClassB.

> Sehe ich es richtig, dass
>
> $obj->Meth(); und
> $obj->SUPER::Meth();
>
> identisch sind, wenn die Klasse von $obj keine Methode 'Meth'
> vorsieht?

Ja.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Ferry Bolhar schrieb:
> Hallo,
>
> gegeben sei ein Objekt $obj. Ich möchte eine Liste aller von
> diesem Objekt unterstützten Methoden, auch solche, die es
> geerbt hat (mittels ISA und/oder UNIVERSAL, mit Angabe
> der jeweilige Klasse, von der die Methode geerbt wurde).
>
> Hat jemand Code dafür bzw. gibt es ein Modul, das diese
> Funktionalität bereitstellt?

Hallo,

schau dir mal Tk::PerlInheritanceTree und Tk::PerlMethodList an.
Vielleicht geht das in die Richtung.

Christoph



--
use Tk;use Tk::GraphItems;$c=tkinit->Canvas->pack;push@i,Tk::GraphItems ->
TextBox(text=>$_,canvas=>$c,x=>$x+=70,y=>100)for(Just=>anoth er=>Perl=>Hacker);
Tk::GraphItems->Connector(source=>$i[$_],target=>$i[$_+1])fo r(0..2);
$c->repeat(30,sub{$_->move(0,4*cos($d+=3.16))for(@i)});MainL oop

Re: Objektmethoden auflisten/Frage zu SUPER

Ferry Bolhar wrote:
> gegeben sei ein Objekt $obj. Ich möchte eine Liste aller von
> diesem Objekt unterstützten Methoden, auch solche, die es
> geerbt hat (mittels ISA und/oder UNIVERSAL, mit Angabe
> der jeweilige Klasse, von der die Methode geerbt wurde).
>
> Hat jemand Code dafür bzw. gibt es ein Modul, das diese
> Funktionalität bereitstellt?

Class::Inspector[1]. Sei dir aber bewusst, dass es immer Möglichkeiten
gibt auf Methoden zu reagieren, die nicht da sind, zB via AUTOLOAD.

[1] http://search.cpan.org/dist/Class-Inspector

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:
> Ferry Bolhar wrote:
>
>>gegeben sei ein Objekt $obj. Ich möchte eine Liste aller von
>>diesem Objekt unterstützten Methoden, auch solche, die es
>>geerbt hat (mittels ISA und/oder UNIVERSAL, mit Angabe
>>der jeweilige Klasse, von der die Methode geerbt wurde).
>>
>>Hat jemand Code dafür bzw. gibt es ein Modul, das diese
>>Funktionalität bereitstellt?
>
> Class::Inspector[1]. Sei dir aber bewusst, dass es immer Möglichkeiten
> gibt auf Methoden zu reagieren, die nicht da sind, zB via AUTOLOAD.

Aufgrund der dynamischen Natur von Perl ist der Vererbungsbaum
nicht unbedingt statisch - sowieso. Wenn AUTOLOAD im Spiel
ist, taucht diese Methode zumindest irgendwo im Vererbungsbaum auf.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Robert Sedlacek:

>> Hat jemand Code dafür bzw. gibt es ein Modul, das diese
>> Funktionalität bereitstellt?
>
> Class::Inspector[1]. Sei dir aber bewusst, dass es immer Möglichkeiten
> gibt auf Methoden zu reagieren, die nicht da sind, zB via AUTOLOAD.

Vielen Dank! Genau das habe ich gesucht.

Es geht darum, die von einem Modul bereitgestellten Methoden in
verschiedenen Versionen zu vergleichen. Das ist damit möglich.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:

> Aufgrund der dynamischen Natur von Perl ist der Vererbungsbaum
> nicht unbedingt statisch - sowieso. Wenn AUTOLOAD im Spiel
> ist, taucht diese Methode zumindest irgendwo im Vererbungsbaum auf.

Jep. Das hilft nur leider nicht bei der ursprünglichen Frage ;)

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>
>>Aufgrund der dynamischen Natur von Perl ist der Vererbungsbaum
>>nicht unbedingt statisch - sowieso. Wenn AUTOLOAD im Spiel
>>ist, taucht diese Methode zumindest irgendwo im Vererbungsbaum auf.
>
> Jep. Das hilft nur leider nicht bei der ursprünglichen Frage ;)

Naja, es ist dadurch ersichtlich, dass mit Methodenaufrufen
von nicht im Vererbungsbaum vorkommenden Methoden in irgendeiner Form
dynamisch umgegangen wird. Das ist doch immerhin was.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:

> Naja, es ist dadurch ersichtlich, dass mit Methodenaufrufen
> von nicht im Vererbungsbaum vorkommenden Methoden in irgendeiner Form
> dynamisch umgegangen wird. Das ist doch immerhin was.

Ich stehe da eher bei "Traue dem nicht." Daher verwende ich so etwas
höchstens für Introspection um andere Dinge zu erreichen. Ich versuche
die Namen der betroffenen Symbole meist einfach vorher zu erfahren oder
definieren/konfigurieren zu lassen.

Abgesehen davon, dass ich den Symbol Table zur Runtime beackern kann wie
es mir beliebt, ist ja AUTOLOAD zB kein unbedingter Indikator für
Methoden. Das könnte genausogut für Funktionen exportiert worden sein:

use warnings;
use strict;
sub AUTOLOAD { print our($AUTOLOAD), "\n" }
hello() and world();

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>
>>Naja, es ist dadurch ersichtlich, dass mit Methodenaufrufen
>>von nicht im Vererbungsbaum vorkommenden Methoden in irgendeiner Form
>>dynamisch umgegangen wird. Das ist doch immerhin was.
>
> Ich stehe da eher bei "Traue dem nicht." Daher verwende ich so etwas
> höchstens für Introspection um andere Dinge zu erreichen. Ich versuche
> die Namen der betroffenen Symbole meist einfach vorher zu erfahren oder
> definieren/konfigurieren zu lassen.

Inwieweit man AUTOLOAD selbst nutzt, ist natürlich dem persönlichen
Geschmack überlassen. Auf jeden Fall ist es ein sehr mächtiges
Mittel, um eine Klassen-Schnittstelle dynamisch zu erweitern,
z.B. um Akzessoren passend zu vorab nicht bekannten Daten zu generieren
oder Methodenaufrufe an andere Klassen zu delegieren oder
Code nachzuladen oder oder oder...

> Abgesehen davon, dass ich den Symbol Table zur Runtime beackern kann wie
> es mir beliebt, ist ja AUTOLOAD zB kein unbedingter Indikator für
> Methoden. Das könnte genausogut für Funktionen exportiert worden sein:
>
> use warnings;
> use strict;
> sub AUTOLOAD { print our($AUTOLOAD), "\n" }
> hello() and world();

Da Perl keine wirkliche Unterscheidung zwischen Funktionen und
Methoden machen, schert AUTOLOAD sich auch nicht um diesen Unterschied.
Auf jedem Fall verhält es sich objektorientiert, wenn es
objektorientiert genutzt wird.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:

> Inwieweit man AUTOLOAD selbst nutzt, ist natürlich dem persönlichen
> Geschmack überlassen. Auf jeden Fall ist es ein sehr mächtiges
> Mittel, um eine Klassen-Schnittstelle dynamisch zu erweitern,
> z.B. um Akzessoren passend zu vorab nicht bekannten Daten zu generieren
> oder Methodenaufrufe an andere Klassen zu delegieren oder
> Code nachzuladen oder oder oder...

Nunja, ich hab meine API gern strikt. Klassen die sämtliche
Methodenaufrufe akzeptieren designe ich daher recht selten. Und für
alles andere kann ich immernoch einen Accessor direkt im Namespace erzeugen.

> Da Perl keine wirkliche Unterscheidung zwischen Funktionen und
> Methoden machen, schert AUTOLOAD sich auch nicht um diesen Unterschied.
> Auf jedem Fall verhält es sich objektorientiert, wenn es
> objektorientiert genutzt wird.

Das habe ich auch nie bezweifelt. Btw, meine Funktionen und Imports sind
in Zukunft nicht mehr als Methoden aufrufbar :)

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>
>>Inwieweit man AUTOLOAD selbst nutzt, ist natürlich dem persönlichen
>>Geschmack überlassen. Auf jeden Fall ist es ein sehr mächtiges
>>Mittel, um eine Klassen-Schnittstelle dynamisch zu erweitern,
>>z.B. um Akzessoren passend zu vorab nicht bekannten Daten zu generieren
>>oder Methodenaufrufe an andere Klassen zu delegieren oder
>>Code nachzuladen oder oder oder...
>
> Nunja, ich hab meine API gern strikt. Klassen die sämtliche
> Methodenaufrufe akzeptieren designe ich daher recht selten.

Irgendwo ist natürlich immer ein Prüfung beteiligt, ob
der dynamisch aufgelöste Methodenaufruf korrekt war.
Wenn nicht, führt das (in meinem Code) zu einer Exception.

> Und für alles andere kann ich immernoch einen Accessor
> direkt im Namespace erzeugen.

Nicht, wenn vorab unbekannt ist (oder man sich schlicht nicht
drum kümmern möchte), welche Acessoren benötigt werden.

>>Da Perl keine wirkliche Unterscheidung zwischen Funktionen und
>>Methoden machen, schert AUTOLOAD sich auch nicht um diesen Unterschied.
>>Auf jedem Fall verhält es sich objektorientiert, wenn es
>>objektorientiert genutzt wird.
>
> Das habe ich auch nie bezweifelt. Btw, meine Funktionen und Imports sind
> in Zukunft nicht mehr als Methoden aufrufbar :)

Bei mir ist ein Package entweder eine Klasse (meistens) oder
eine Funktionssammlung (selten), aber nie beides. Insofern habe ich
dieses Bedürfnis bislang noch nicht gehabt. Dennoch interessehalber
gefragt: Wie erreichst Du das?

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:

> Irgendwo ist natürlich immer ein Prüfung beteiligt, ob
> der dynamisch aufgelöste Methodenaufruf korrekt war.
> Wenn nicht, führt das (in meinem Code) zu einer Exception.

Gut, ich nehme an, du überlädst auch brav 'can'? :) Für mich war das
einfach immer zuviel Aufwand. Ein

*{ $class . '::' . $name } = sub { ... };

fand ich meist einfacher, vor allem, weil ich in 95% der Fälle auch
einen eigenen Wrapper drumrum möchte. Aber gut, die Techniken sind
natürlich alle vom Einsatzzweck abhängig.

>> Und für alles andere kann ich immernoch einen Accessor
>> direkt im Namespace erzeugen.
>
> Nicht, wenn vorab unbekannt ist (oder man sich schlicht nicht
> drum kümmern möchte), welche Acessoren benötigt werden.

Da ist der Unterschied. Wenn ich vorher nicht weiss, welche Methoden
gültig sind, fange ich an mir Sorgen zu machen. :)

> Bei mir ist ein Package entweder eine Klasse (meistens) oder
> eine Funktionssammlung (selten), aber nie beides. Insofern habe ich
> dieses Bedürfnis bislang noch nicht gehabt. Dennoch interessehalber
> gefragt: Wie erreichst Du das?

Mit L. Das ist aber alles gerade erst im entstehen. Es
wäre damit genauso gut möglich soetwas zu machen:

sub foo: method {
my ($self, $x) = @_;
return bar($x, 2);
}

sub bar: method {
my ($self, $x, $y) = @_;
return $x + $y;
}
...
my $four = $object->foo(2);

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>
>>Irgendwo ist natürlich immer ein Prüfung beteiligt, ob
>>der dynamisch aufgelöste Methodenaufruf korrekt war.
>>Wenn nicht, führt das (in meinem Code) zu einer Exception.
>
> Gut, ich nehme an, du überlädst auch brav 'can'? :)

Offen gestanden: nein. Es ist aber sauberer
das zu tun, zugegeben.

> Für mich war das einfach immer zuviel Aufwand.

Es sollte nicht schwer sein, das hinzuzufügen.

> Ein
>
> *{ $class . '::' . $name } = sub { ... };
>
> fand ich meist einfacher,

Das kann man AUTOLOAD machen lassen.

> vor allem, weil ich in 95% der Fälle auch
> einen eigenen Wrapper drumrum möchte.

Dann schreibst Du keinen Wrapper, sondern implementierst
die Methode - und schwupps - fühlt AUTOLOAD sich
nicht angesprochen.

>>>Und für alles andere kann ich immernoch einen Accessor
>>>direkt im Namespace erzeugen.
>>
>>Nicht, wenn vorab unbekannt ist (oder man sich schlicht nicht
>>drum kümmern möchte), welche Acessoren benötigt werden.
>
> Da ist der Unterschied. Wenn ich vorher nicht weiss, welche Methoden
> gültig sind, fange ich an mir Sorgen zu machen. :)

Dann machst Du Dir zu viele Sorgen :)

>>Bei mir ist ein Package entweder eine Klasse (meistens) oder
>>eine Funktionssammlung (selten), aber nie beides. Insofern habe ich
>>dieses Bedürfnis bislang noch nicht gehabt. Dennoch interessehalber
>>gefragt: Wie erreichst Du das?
>
> Mit L. Das ist aber alles gerade erst im entstehen. Es
> wäre damit genauso gut möglich soetwas zu machen:
>
> sub foo: method {
> my ($self, $x) = @_;
> return bar($x, 2);
> }
>
> sub bar: method {
> my ($self, $x, $y) = @_;
> return $x + $y;
> }
> ...
> my $four = $object->foo(2);

Objektmethoden, die ohne Objekt auskommen, finde ich merkwürdig.
Da gehe ich erstmal von einem verfehlten Design aus.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:
> Robert 'phaylon' Sedlacek wrote:
>
>> Für mich war das einfach immer zuviel Aufwand.
>
> Es sollte nicht schwer sein, das hinzuzufügen.

Ich meinte eher das generelle Sicherstellen, dass die Methoden auch
wirklich OO sind, inklusive Vererbung etc.

>> Ein
>>
>> *{ $class . '::' . $name } = sub { ... };
>>
>> fand ich meist einfacher,
>
> Das kann man AUTOLOAD machen lassen.

Natürlich, ich kann's aber auch gleich machen :)

>> vor allem, weil ich in 95% der Fälle auch
>> einen eigenen Wrapper drumrum möchte.
>
> Dann schreibst Du keinen Wrapper, sondern implementierst
> die Methode - und schwupps - fühlt AUTOLOAD sich
> nicht angesprochen.

Siehe oben.

>> Da ist der Unterschied. Wenn ich vorher nicht weiss, welche Methoden
>> gültig sind, fange ich an mir Sorgen zu machen. :)
>
> Dann machst Du Dir zu viele Sorgen :)

Bisher hat sich's ausgezahlt :)

>> Mit L. Das ist aber alles gerade erst im entstehen. Es
>> wäre damit genauso gut möglich soetwas zu machen:
>>
>> sub foo: method {
>> my ($self, $x) = @_;
>> return bar($x, 2);
>> }
>>
>> sub bar: method {
>> my ($self, $x, $y) = @_;
>> return $x + $y;
>> }
>> ...
>> my $four = $object->foo(2);
>
> Objektmethoden, die ohne Objekt auskommen, finde ich merkwürdig.
> Da gehe ich erstmal von einem verfehlten Design aus.

Das war auch nur eine Erläuterung. Siehe "Es _wäre_...". Die normale
Funktionsweise von namespace::clean ist einfach, dass die Einträge aus
der Symboltabelle deleted werden, die davor importiert und definiert
wurden, wenn die Compile-Time vorüber ist. Damit sind Funktionen lokal
im Package gebunden und Aufrufe via foo() funktionieren noch, per
Methoden-Lookup sind sie aber nicht mehr zu finden.

Die Funktionen sind natürlich auch nicht per Foo::bar() aufrufbar, also
vollständig private. Gedacht war das ursprünglich um dieses Problem zu
beheben:

package Foo;
use Carp 'croak';

sub bar { croak 'bar' }

Foo->croak;

1;

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:
>
> Ich meinte eher das generelle Sicherstellen, dass die Methoden auch
> wirklich OO sind, inklusive Vererbung etc.

Das funktioniert alles wie gewohnt und erwartet, dafür
brauchst Du nichts besonderes zu tun. D.h. Basisklassen-Methoden
werden genutzt, wenn vorhanden, auch wenn AUTOLOAD definiert
ist, und in Subklassen kann alles überschrieben werden.

>>>Mit L. Das ist aber alles gerade erst im entstehen. Es
>>>wäre damit genauso gut möglich soetwas zu machen:
>>>
>>> sub foo: method {
>>> my ($self, $x) = @_;
>>> return bar($x, 2);
>>> }
>>>
>>> sub bar: method {
>>> my ($self, $x, $y) = @_;
>>> return $x + $y;
>>> }
>>> ...
>>> my $four = $object->foo(2);
>>
>>Objektmethoden, die ohne Objekt auskommen, finde ich merkwürdig.
>>Da gehe ich erstmal von einem verfehlten Design aus.
>
> Das war auch nur eine Erläuterung. Siehe "Es _wäre_...". Die normale
> Funktionsweise von namespace::clean ist einfach, dass die Einträge aus
> der Symboltabelle deleted werden, die davor importiert und definiert
> wurden, wenn die Compile-Time vorüber ist. Damit sind Funktionen lokal
> im Package gebunden und Aufrufe via foo() funktionieren noch, per
> Methoden-Lookup sind sie aber nicht mehr zu finden.
>
> Die Funktionen sind natürlich auch nicht per Foo::bar() aufrufbar, also
> vollständig private. Gedacht war das ursprünglich um dieses Problem zu
> beheben:
>
> package Foo;
> use Carp 'croak';
>
> sub bar { croak 'bar' }
>
> Foo->croak;
>
> 1;

Ich habe das Prinzip Deines Pragmas verstanden, es adressiert das
Namensraum-Verschmutzungs-Problem, das durch Symbolimport entsteht
und mich auch sehr stört. Ich löse es aber anders: Ich importiere
grundsätzlich keine Symbole.

Bei mir sähe der obiger Code so aus:

package Foo;
use Carp ();

sub bar { Carp::croak 'bar' }

1;

Ein von Aufruf Foo->croak() ist dann von vornherein ausgeschlossen.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:
> Robert 'phaylon' Sedlacek wrote:
>> Ich meinte eher das generelle Sicherstellen, dass die Methoden auch
>> wirklich OO sind, inklusive Vererbung etc.
>
> Das funktioniert alles wie gewohnt und erwartet, dafür
> brauchst Du nichts besonderes zu tun. D.h. Basisklassen-Methoden
> werden genutzt, wenn vorhanden, auch wenn AUTOLOAD definiert
> ist, und in Subklassen kann alles überschrieben werden.

"Wie gewohnt" setzt voraus, dass ich AUTOLOAD häufiger verwende, "wie
erwartet" setzt voraus, dass meine Erwartung deiner entspricht :) Ich
fände es zB hübscher, wenn AUTOLOAD überladen könnte und perl Zeiger
(ich sage absichtlich nicht Pointer) zurückgibt, und das Ganze dann noch
mit C3, NEXT, etc. funktioniert :)

> Ich habe das Prinzip Deines Pragmas verstanden, es adressiert das
> Namensraum-Verschmutzungs-Problem, das durch Symbolimport entsteht
> und mich auch sehr stört. Ich löse es aber anders: Ich importiere
> grundsätzlich keine Symbole.
>
> Bei mir sähe der obiger Code so aus:
>
> package Foo;
> use Carp ();
>
> sub bar { Carp::croak 'bar' }
>
> 1;
>
> Ein von Aufruf Foo->croak() ist dann von vornherein ausgeschlossen.

So habe ich's bisher auch gemacht. Allerdings ist mir

use aliased 'Catalyst::Base::Controller::Something::Action';
sub bar { Action->new }

lieber als das Ganze auszuschreiben. Genauso mit zB. CLASS, den Helper
Methoden die Moose beispielsweise exportiert, etc. In meinem momentanen
Projekt könnte ich Foo::bar() nichtmal verwenden, da sämtliche Exports
dynamisch generiert werden.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>Robert 'phaylon' Sedlacek wrote:
>>
>>>Ich meinte eher das generelle Sicherstellen, dass die Methoden auch
>>>wirklich OO sind, inklusive Vererbung etc.
>>
>>Das funktioniert alles wie gewohnt und erwartet, dafür
>>brauchst Du nichts besonderes zu tun. D.h. Basisklassen-Methoden
>>werden genutzt, wenn vorhanden, auch wenn AUTOLOAD definiert
>>ist, und in Subklassen kann alles überschrieben werden.
>
> "Wie gewohnt" setzt voraus, dass ich AUTOLOAD häufiger verwende, "wie
> erwartet" setzt voraus, dass meine Erwartung deiner entspricht :)

Ich meinte damit die Vererbung. Ich gehe mal davon aus, dass
wir da das gleiche erwarten.

> Ich fände es zB hübscher, wenn AUTOLOAD überladen könnte

Tja, da besteht ein Zielkonflikt. Dass AUTOLOAD erst nach
den Basisklassenmethoden drankommt, ist IMO ein besseres
Defaultverhalten, möglicherweise wäre es anders aber mächtiger.
Ich habe es bislang noch nicht gebraucht, dass AUTOLOAD Methoden
überschreiben müsste.

> und perl Zeiger
> (ich sage absichtlich nicht Pointer) zurückgibt, und das Ganze dann noch
> mit C3, NEXT, etc. funktioniert :)

Vielleicht tut es das?
Perl und Pointer kenne ich eigentlich nicht. AUTOLOAD liefert den Wert
der gerufenen Subroutine zurück, denn es vertritt diese.

>>Bei mir sähe der obiger Code so aus:
>>
>> package Foo;
>> use Carp ();
>>
>> sub bar { Carp::croak 'bar' }
>>
>> 1;
>>
>>Ein von Aufruf Foo->croak() ist dann von vornherein ausgeschlossen.
>
> So habe ich's bisher auch gemacht. Allerdings ist mir
>
> use aliased 'Catalyst::Base::Controller::Something::Action';
> sub bar { Action->new }
>
> lieber als das Ganze auszuschreiben. Genauso mit zB. CLASS, den Helper
> Methoden die Moose beispielsweise exportiert, etc. In meinem momentanen
> Projekt könnte ich Foo::bar() nichtmal verwenden, da sämtliche Exports
> dynamisch generiert werden.

Ok, sehe ich ein.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:
> Robert 'phaylon' Sedlacek wrote:
>
>> "Wie gewohnt" setzt voraus, dass ich AUTOLOAD häufiger verwende, "wie
>> erwartet" setzt voraus, dass meine Erwartung deiner entspricht :)
>
> Ich meinte damit die Vererbung. Ich gehe mal davon aus, dass
> wir da das gleiche erwarten.

Ich erwarte es, weil ich die Dokumentation gelesen habe, und meide es
daher ;) Insofern aber: Ja.

>> Ich fände es zB hübscher, wenn AUTOLOAD überladen könnte
>
> Tja, da besteht ein Zielkonflikt. Dass AUTOLOAD erst nach
> den Basisklassenmethoden drankommt, ist IMO ein besseres
> Defaultverhalten, möglicherweise wäre es anders aber mächtiger.
> Ich habe es bislang noch nicht gebraucht, dass AUTOLOAD Methoden
> überschreiben müsste.

Ich habe AUTOLOAD noch nicht gebraucht ;) Eigentlich ist es so wie es
jetzt ist auch sinnvoller, aber es müsste eben andere Dinge können,
damit ich es verwenden würde.

>> und perl Zeiger
>> (ich sage absichtlich nicht Pointer) zurückgibt, und das Ganze dann noch
>> mit C3, NEXT, etc. funktioniert :)
>
> Vielleicht tut es das?
> Perl und Pointer kenne ich eigentlich nicht. AUTOLOAD liefert den Wert
> der gerufenen Subroutine zurück, denn es vertritt diese.

Deswegen schrieb ich ja eben _nicht_ Pointer. Ich bin mir bewusst, wie
AUTOLOAD funktioniert, das ist ja das Problem. Beispielsweise würde
AUTOLOAD statt der ersetzten Methode im Caller auftauchen, damit hätten
MI-Redispatcher wie C3 wahrscheinlich Probleme, abgesehen davon, dass es
momentan nicht gehen kann, weil AUTOLOAD nicht aktiv wird, wenn irgendwo
im Vererbungsbaum eine solche Methode existiert.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert Sedlacek:

> sub foo: method {
> my ($self, $x) = @_;
> return bar($x, 2);
> }
>
> sub bar: method {
> my ($self, $x, $y) = @_;
> return $x + $y;
> }

Was bewirkt die Deklaration mit dem "method" Attribut?

Man kann doch _jede_ Funktion als Methode und auch
umgekehrt aufrufen, es ist - in Perl - ja nur eine Frage
der Aufrufkonvention.

Ich hielt "method" für ein aus der Mode gekommenes
Attribut für das Threading unter Perl 5.005. Aber scheinbar
doch nicht. Welche Bedeutung hat es hier?

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Objektmethoden auflisten/Frage zu SUPER

Ferry Bolhar wrote:

> Man kann doch _jede_ Funktion als Methode und auch
> umgekehrt aufrufen, es ist - in Perl - ja nur eine Frage
> der Aufrufkonvention.

Deswegen ja namespace::clean, damit das nicht mehr passiert.

> Ich hielt "method" für ein aus der Mode gekommenes
> Attribut für das Threading unter Perl 5.005. Aber scheinbar
> doch nicht. Welche Bedeutung hat es hier?

Die Bedeutung eines Beispiels.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:

> Ich habe AUTOLOAD noch nicht gebraucht ;) Eigentlich ist es so wie es
> jetzt ist auch sinnvoller, aber es müsste eben andere Dinge können,
> damit ich es verwenden würde.

Na gut. Vielleicht tauchen noch andere Anwendungsfälle auf.

>>>und perl Zeiger
>>>(ich sage absichtlich nicht Pointer) zurückgibt, und das Ganze dann noch
>>>mit C3, NEXT, etc. funktioniert :)
>>
>>Vielleicht tut es das?
>>Perl und Pointer kenne ich eigentlich nicht. AUTOLOAD liefert den Wert
>>der gerufenen Subroutine zurück, denn es vertritt diese.
>
> Deswegen schrieb ich ja eben _nicht_ Pointer.

"Zeiger" und "Pointer" bezeichnet für mich das gleiche.
Ich verstehe nicht, was Du meinst.

> Ich bin mir bewusst, wie
> AUTOLOAD funktioniert, das ist ja das Problem. Beispielsweise würde
> AUTOLOAD statt der ersetzten Methode im Caller auftauchen, damit hätten
> MI-Redispatcher wie C3 wahrscheinlich Probleme, abgesehen davon, dass es
> momentan nicht gehen kann, weil AUTOLOAD nicht aktiv wird, wenn irgendwo
> im Vererbungsbaum eine solche Methode existiert.

Keine Ahnung, wie NEXT und Class::C3 verhalten, wenn
AUTOLOAD-Methoden vorhanden sind. Ich kenne die Module nicht näher.
Wenn sie gut gemacht sind, sollte es keine Schwierigkeiten geben.
Ich würde sagen: NEXT müsste AUTOLOAD übergehen, wenn der Aufruf
mindestens einmal durch eine reale Methode aufgelöst werden konnte,
Class::C3 sollte AUTOLOAD ganz normal am Ende der Methodensuche einreihen.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:

> "Zeiger" und "Pointer" bezeichnet für mich das gleiche.
> Ich verstehe nicht, was Du meinst.

Ein Pfeil. "Auf etwas hindeuten/zeigen". Ein Etwas mit einem Bezug zu
einem Ding das eigentlich ausgeführt werden soll.

Deswegen stand da ja, dass ich extra _nicht_ Pointer schreibe, sondern
ein normales deutsches Wort verwende. Pointer haben wir in Perl ja eben
garnicht, aber ich schreibe es schon immer dazu, weil jedesmal wenn das
Wort "Pointer" auftaucht, die Leute mit C ankommen und verwirrt sind.

> Keine Ahnung, wie NEXT und Class::C3 verhalten, wenn
> AUTOLOAD-Methoden vorhanden sind. Ich kenne die Module nicht näher.

Weisst du was? Vergessen wir's. Ich verbringe hier 99% meiner Zeichen
damit, dir zu erklären was ich eigentlich im vorigen Post ausdrücken
wollte, das bringt nichts.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>
>>"Zeiger" und "Pointer" bezeichnet für mich das gleiche.
>>Ich verstehe nicht, was Du meinst.
>
> Ein Pfeil. "Auf etwas hindeuten/zeigen". Ein Etwas mit einem Bezug zu
> einem Ding das eigentlich ausgeführt werden soll.
>
> Deswegen stand da ja, dass ich extra _nicht_ Pointer schreibe, sondern
> ein normales deutsches Wort verwende. Pointer haben wir in Perl ja eben
> garnicht, aber ich schreibe es schon immer dazu, weil jedesmal wenn das
> Wort "Pointer" auftaucht, die Leute mit C ankommen und verwirrt sind.

Im Perl-Kontext gibt es das Wort/das Konzept "Referenz",
da ist einigermaßen klar, was gemeint ist.

>>Keine Ahnung, wie NEXT und Class::C3 verhalten, wenn
>>AUTOLOAD-Methoden vorhanden sind. Ich kenne die Module nicht näher.
>
> Weisst du was? Vergessen wir's. Ich verbringe hier 99% meiner Zeichen
> damit, dir zu erklären was ich eigentlich im vorigen Post ausdrücken
> wollte, das bringt nichts.

Wenn Du das so siehst, brauchen wir das nicht weiter zu
diskutieren. Ich sehe das zwar anders, aber kein Problem.
Vielleicht haben wir bei den Perl-Mongers mal die
Gelegenheit, das zuende zu führen.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:
> Im Perl-Kontext gibt es das Wort/das Konzept "Referenz",
> da ist einigermaßen klar, was gemeint ist.

Ja. Und _genau davon_ sprach ich nicht.

> Wenn Du das so siehst, brauchen wir das nicht weiter zu
> diskutieren. Ich sehe das zwar anders, aber kein Problem.
> Vielleicht haben wir bei den Perl-Mongers mal die
> Gelegenheit, das zuende zu führen.

Jep.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert Sedlacek:

> Deswegen ja namespace::clean, damit das nicht mehr passiert.

Ich kenne das Modul, du löscht damit Stashes in der jeweiligen
Symboltabelle, deren Typeglobs im CODE-Slot einen Eintrag
haben (führt das übrigens nicht zu Problemen, wenn ein Symbol
sowohl als Funktionsname als auch für einen anderen Werttyp
verwendet wird?).

Mir ist dennoch nicht ganz klar, was du mit dem ":method"
Attribut in deinem Beispiel verdeutlichen willst. Auch wenn
man eine Funktion mit ":method" deklariert, bleibt es eine
Funktion, die man auch als solche aufrufen kann. Das
Attribut ändert nichts daran. Willst du das damit ausdrücken?

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Objektmethoden auflisten/Frage zu SUPER

Ferry Bolhar wrote:

> Ich kenne das Modul, du löscht damit Stashes in der jeweiligen
> Symboltabelle, deren Typeglobs im CODE-Slot einen Eintrag
> haben (führt das übrigens nicht zu Problemen, wenn ein Symbol
> sowohl als Funktionsname als auch für einen anderen Werttyp
> verwendet wird?).

Das kann momentan noch passieren, in der SVN Version ist ein Versuch der
das nicht tut.

> Mir ist dennoch nicht ganz klar, was du mit dem ":method"
> Attribut in deinem Beispiel verdeutlichen willst. Auch wenn
> man eine Funktion mit ":method" deklariert, bleibt es eine
> Funktion, die man auch als solche aufrufen kann. Das
> Attribut ändert nichts daran. Willst du das damit ausdrücken?

Was damit passiert, hängt davon ab, wer :method abfängt und etwas damit
anfängt. Aber nehmen wir statt dessen eben einfach ':Method'.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert Sedlakcek:

>> Führt das übrigens nicht zu Problemen, wenn ein Symbol
>> sowohl als Funktionsname als auch für einen anderen Werttyp
>> verwendet wird?).
>
> Das kann momentan noch passieren, in der SVN Version ist
> ein Versuch der das nicht tut.

Man könnte ja statt dem Löschen der jeweiligen Stashelemente
nur den betreffenden CODE-Slot des Typeglobs auf undef
setzen?

> Was damit passiert, hängt davon ab, wer :method abfängt und etwas damit
> anfängt. Aber nehmen wir statt dessen eben einfach ':Method'.

OK, jetzt ist es mir klar. Es ging nur um die Deklaration
einer Funktion als Methode ansich. Ich verstehe, was du
gemeint hast.

Der Knackpunkt ist nämlich, dass ausgerechnet "method"
eines der (ab Perl 5.6 obsoleten) Built-In Attribute ist. Ein
selbstgeschriebener Attributhandler würde bei der Angabe
dieses Attributes gar nicht aufgerufen werden, da es der
Core selbst verarbeitet (er setzt im entsprechenden CV ein
Bit, das aber später nie mehr verwendet wird).

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Objektmethoden auflisten/Frage zu SUPER

Ferry Bolhar wrote:

> Man könnte ja statt dem Löschen der jeweiligen Stashelemente
> nur den betreffenden CODE-Slot des Typeglobs auf undef
> setzen?

Leider nein:

perl -wle'sub foo {} *{ $main::{foo} }{CODE} = undef'
Can't modify glob elem in scalar assignment at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

perl -wle'sub foo {} undef *{ $main::{foo} }{CODE}'
Can't modify glob elem in undef operator at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

> OK, jetzt ist es mir klar. Es ging nur um die Deklaration
> einer Funktion als Methode ansich. Ich verstehe, was du
> gemeint hast.

Genau :)

> Der Knackpunkt ist nämlich, dass ausgerechnet "method"
> eines der (ab Perl 5.6 obsoleten) Built-In Attribute ist. Ein
> selbstgeschriebener Attributhandler würde bei der Angabe
> dieses Attributes gar nicht aufgerufen werden, da es der
> Core selbst verarbeitet (er setzt im entsprechenden CV ein
> Bit, das aber später nie mehr verwendet wird).

Ach, wer verwendet denn heutzutage noch Threads ;) *scnr* Im Ernst: Fiel
mir vorhin dann auch auf, danke.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:
> Ferry Bolhar wrote:
>>
>>Man könnte ja statt dem Löschen der jeweiligen Stashelemente
>>nur den betreffenden CODE-Slot des Typeglobs auf undef
>>setzen?
>
> Leider nein:
>
> perl -wle'sub foo {} *{ $main::{foo} }{CODE} = undef'
> Can't modify glob elem in scalar assignment at -e line 1, at EOF
> Execution of -e aborted due to compilation errors.
>
> perl -wle'sub foo {} undef *{ $main::{foo} }{CODE}'
> Can't modify glob elem in undef operator at -e line 1, at EOF
> Execution of -e aborted due to compilation errors.

Workaround:

*x = *foo{SCALAR};
*x = *foo{ARRAY};
*x = *foo{HASH};
# *x = *foo{CODE}; den nicht
*x = *foo{IO};
*foo = *x;

(ungetestet)

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:

> Workaround:
>
> *x = *foo{SCALAR};
> *x = *foo{ARRAY};
> *x = *foo{HASH};
> # *x = *foo{CODE}; den nicht
> *x = *foo{IO};
> *foo = *x;
>
> (ungetestet)

Logisch, aber unschön. Zumindest blead hat übrigens noch 'FORMAT.'

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>
>>Workaround:
>>
>>*x = *foo{SCALAR};
>>*x = *foo{ARRAY};
>>*x = *foo{HASH};
>># *x = *foo{CODE}; den nicht
>>*x = *foo{IO};
>>*foo = *x;
>>
>>(ungetestet)
>
> Logisch, aber unschön.

Weniger unschön immerhin, als per Seiteneffekt Symbole zu plätten.

> Zumindest blead hat übrigens noch 'FORMAT.'

Das überlasse ich Dir als Übungsaufgabe :-)

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Robert Sedlacek:

> perl -wle'sub foo {} *{ $main::{foo} }{CODE} = undef'
> Can't modify glob elem in scalar assignment at -e line 1, at EOF

Naja, es ginge vielleicht (nicht besonders elegant, aber immerhin):

*x = *foo;
undef *foo;
*foo = *x{$_} foreach qw(SCALAR ARRAY HASH IO FORMAT);
undef *x;

Ein Option wäre es natürlich auch, den CODE-Slot des Typeglobs
mittels XS-Code auf 0 zu setzen. Interessanterweise scheint Perl
selbst keine solche Möglichkeit bereitzustellen, ein

undef &foo;

setzt zwar den CV auf undef, beläßt aber den CODE-Slot
unverändert. Ich muss gestehen, dass mir momentan nicht klar
ist, was dies im Falle von Methoden-Vererbung bedeutet.

Wie hast du das Problem in der SVN Version gelöst?

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:

> Weniger unschön immerhin, als per Seiteneffekt Symbole zu plätten.

Dass es Schlimmeres gibt, war immerschon ein schlechter Grund etwas zu
tun :) So wie du es beschreibst, wird es im SVN ja auch schon lange
gemacht. Trotzdem suche ich lieber noch etwas weiter, bevor ich das auf
CPAN schiebe.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Ferry Bolhar wrote:

> Naja, es ginge vielleicht (nicht besonders elegant, aber immerhin):
>
> *x = *foo;
> undef *foo;
> *foo = *x{$_} foreach qw(SCALAR ARRAY HASH IO FORMAT);
> undef *x;

Genau das tue ich momentan. Ausser natürlich, dass ich noch undefinierte
Werte hinausfiltere. Da muss ich auch noch ein paar Tests in die Suite
bzgl. Skalaren aufnehmen.

> Ein Option wäre es natürlich auch, den CODE-Slot des Typeglobs
> mittels XS-Code auf 0 zu setzen. Interessanterweise scheint Perl
> selbst keine solche Möglichkeit bereitzustellen, ein
>
> undef &foo;
>
> setzt zwar den CV auf undef, beläßt aber den CODE-Slot
> unverändert. Ich muss gestehen, dass mir momentan nicht klar
> ist, was dies im Falle von Methoden-Vererbung bedeutet.

Sie wird noch gefunden, ist aber nicht ausführbar.

perl -wle'sub foo {} undef &foo; print foo()'
Undefined subroutine &main::foo called at -e line 1.

perl -wle'sub foo {} undef &foo; print main->can("foo")->()'
Undefined subroutine &main::foo called at -e line 1.

perl -wle'sub foo {} undef &foo; print main->can("foo")'
CODE(0x81605c4)

Also genau das gleiche Ergebnis wie deklarierte aber nicht definierte subs:

sub foo;
print main->can('foo') ? "Yes\n" : "No\n";
print main->can('foo')->();

gibt

Yes
Undefined subroutine &main::foo called at - line 3.

> Wie hast du das Problem in der SVN Version gelöst?

Siehe oben. Es gibt wohl momentan noch keinen Weg da drumrum, jedenfalls
ist mir noch keiner aufgefallen. Momentan versuche ich rauszufinden, ob
ich sämtliche (schreibbaren) Typeglob Schlüssel zur aktuellen
Perl-Version ermitteln kann, oder einfach immer die komplette Liste
mitliefere.

Wenigstens testet sich das Ganze angenehm und in kleinen Happen.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert Sedlacek:

> Momentan versuche ich rauszufinden, ob
> ich sämtliche (schreibbaren) Typeglob Schlüssel zur aktuellen
> Perl-Version ermitteln kann, oder einfach immer die komplette Liste
> mitliefere.

Was meinst du mit "schreibbaren Typeglob Schlüssel"? Soviel
ich weiß, gibt es die nicht. Schon beim Kompilieren wird die

Can't modify glob elem in ...

Meldung ausgespuckt, wenn der Compiler einen Ausdruck wie
*GLOB{KEY} als lvalue entdeckt, egal, was man für KEY
einsetzt. Das heißt, schon der Parser stört sich daran, es wird
überhaupt nicht mehr geschaut, ob KEY zur Laufzeit beschreib-
bar sein könnte.

Oder verstehe ich "schreibbar" falsch?

Die Schlüssel selbst sind in der Funktion pp_gelem (in pp.c)
kodiert. Ich wüßte nicht, wie du die zur Laufzeit herausbekommen
könntest. Oder worum geht es dir dabei?

Schöne Grüße,

Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Objektmethoden auflisten/Frage zu SUPER

Ferry Bolhar wrote:

> Was meinst du mit "schreibbaren Typeglob Schlüssel"? Soviel
> ich weiß, gibt es die nicht. Schon beim Kompilieren wird die
>
> Can't modify glob elem in ...
> ...
> Oder verstehe ich "schreibbar" falsch?

Jep :) Ich kann die üblichen Verdächtigen via

*__tmp = \%foo;

also via Referenz setzen. Typeglobs scheinen jedoch auch Schlüssel zu
haben, die rein für die Erhaltung der Daten nicht erforderlich sind (ich
glaube einer hiess GLOB, zum Beispiel, und liefert the die
Glob-Referenz). Die brauche ich natürlich nicht.

> Die Schlüssel selbst sind in der Funktion pp_gelem (in pp.c)
> kodiert. Ich wüßte nicht, wie du die zur Laufzeit herausbekommen
> könntest. Oder worum geht es dir dabei?

Ja, darum. Aber eine einfache Liste (nicht gesetztes ist nicht
definiert, und wird übersprungen) die up-to-date gehalten wird in den
nächsten 200 Jahren wird's wohl auch tun. Soviele Elemente sind es ja
schliesslich nicht.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:

> Trotzdem suche ich lieber noch etwas weiter, bevor ich das auf
> CPAN schiebe.

Für das, was Du möchtest, stellt Perl keine anderen
Sprachmittel zur Verfügung als die genannten. Da bin ich
mir ziemlich sicher.

Bleibt die Frage, warum das so ist. Hat jemand eine Idee?

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:

> Für das, was Du möchtest, stellt Perl keine anderen
> Sprachmittel zur Verfügung als die genannten. Da bin ich
> mir ziemlich sicher.

Ich mir auch. Gut Ding braucht trotzdem Weile.

> Bleibt die Frage, warum das so ist. Hat jemand eine Idee?

Weil's wohl noch niemand vorher benötigt hat, nehme ich an.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>
>>Bleibt die Frage, warum das so ist. Hat jemand eine Idee?
>
> Weil's wohl noch niemand vorher benötigt hat, nehme ich an.

Nach 12 Jahren Perl5 und den vielen professionllen Nutzern
eher unwahrscheinlich. An *foo{THING} keine Zuweisung
zu erlauben, sieht mir nach einer bewussten Entscheidung aus.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:

>> Weil's wohl noch niemand vorher benötigt hat, nehme ich an.
>
> Nach 12 Jahren Perl5 und den vielen professionllen Nutzern
> eher unwahrscheinlich. An *foo{THING} keine Zuweisung
> zu erlauben, sieht mir nach einer bewussten Entscheidung aus.

Auch "es hatte noch keiner einen Grund, es wirklich zu wollen" kann eine
bewusste Entscheidung sein.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }

Re: Objektmethoden auflisten/Frage zu SUPER

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>
>>Nach 12 Jahren Perl5 und den vielen professionllen Nutzern
>>eher unwahrscheinlich. An *foo{THING} keine Zuweisung
>>zu erlauben, sieht mir nach einer bewussten Entscheidung aus.
>
> Auch "es hatte noch keiner einen Grund, es wirklich zu wollen" kann eine
> bewusste Entscheidung sein.

Theoretisch, ja. Praktisch ist es eher unwahrscheinlich, dass jemand
aus so einer Annahme/Überlegung heraus eine Sache nur zur
Hälfte implementiert, wenn kein zusätzlicher Grund dafür vorliegt.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Objektmethoden auflisten/Frage zu SUPER

Frank Seitz wrote:
> Theoretisch, ja. Praktisch ist es eher unwahrscheinlich, dass jemand
> aus so einer Annahme/Überlegung heraus eine Sache nur zur
> Hälfte implementiert, wenn kein zusätzlicher Grund dafür vorliegt.

Dann frag doch in p5p einfach mal nach.

--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail => ' rs@474.at ', Web => ' http://474.at ' }