Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Florian Hess wrote:
> Ist es nicht so, dass my-deklarierte Paketvariablen so oder so nicht von
> außerhalb desselben Pakets angesprochen werden können? Dies scheinen mir
> auch einfache Tests zu bestätigen. Warum also sind diese Klammern
> "unerlässlich", "vital"? Wie könnte man auf die Objektattribute trotzdem
> zugreifen, wenn sie nicht nochmal extra in einen Block gefasst wären?

#--- test.pl ---#
package Foo;
use strict;
my $foo = 23;

package Bar;
use strict;
print "$foo\n";
#--- --- --- ---#

gibt 23 aus.

..phaylon

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Florian Hess schrieb:
> Robert 'phaylon' Sedlacek schrieb:
>> Florian Hess wrote:
>> package Foo;
>> [..]
>> package Bar;

Wobei ich seltenst -- und wenn, dann fast ausschließlich zu Testzwecken
-- mehrere Packages in einer Datei habe. Und nur in diesem (bei mir
seltenen) Falle sind die Klammern wohl nötig.

*Ausschweif*: Ich fände es sogar gut, wenn die package-Deklaration
optional ist und aus dem Pfad Foo/Bar/Baz.pm des Moduls das Paket
Foo::Bar::Baz impliziert.

Das will ich jedenfalls _viel_ häufiger als mehrere Packages in einer Datei.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: streawkceur@jabber.i-pobox.net

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Thomas Wittek wrote:
> Florian Hess schrieb:
>>Robert 'phaylon' Sedlacek schrieb:
>>
>>>Florian Hess wrote:
>>> package Foo;
>>> [..]
>>> package Bar;
>
> Wobei ich seltenst -- und wenn, dann fast ausschließlich zu Testzwecken
> -- mehrere Packages in einer Datei habe. Und nur in diesem (bei mir
> seltenen) Falle sind die Klammern wohl nötig.

Wirklich nötig sind die Klammern auch dann nicht.
Sie generell zu verwenden, finde ich ein bisschen paranoiamäßig.

> *Ausschweif*: Ich fände es sogar gut, wenn die package-Deklaration
> optional ist und aus dem Pfad Foo/Bar/Baz.pm des Moduls das Paket
> Foo::Bar::Baz impliziert.
>
> Das will ich jedenfalls _viel_ häufiger als mehrere Packages in einer Datei.

Eine Package-Deklaration explizit hinzuschreiben, sollte ansich
nicht der Arbeitsaufwand sein. De facto haben Dateien und Packages
fast garnichts miteinander zu tun: Eine Datei kann mehrere Packages
enthalten, ein Package kann sich über mehrere Dateien erstrecken.
Beide Möglichkeiten zu haben, finde ich wichtig, vor allem letzere.

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: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Thomas Wittek wrote:
> Florian Hess schrieb:
>>Robert 'phaylon' Sedlacek schrieb:
>>>
>>> package Foo;
>>> [..]
>>> package Bar;
>
> Wobei ich seltenst -- und wenn, dann fast ausschließlich zu Testzwecken
> -- mehrere Packages in einer Datei habe. Und nur in diesem (bei mir
> seltenen) Falle sind die Klammern wohl nötig.

Wirklich nötig sind die Klammern auch dann nicht.
Sie generell zu verwenden, finde ich ein bisschen paranoiamäßig.

> *Ausschweif*: Ich fände es sogar gut, wenn die package-Deklaration
> optional ist und aus dem Pfad Foo/Bar/Baz.pm des Moduls das Paket
> Foo::Bar::Baz impliziert.
>
> Das will ich jedenfalls _viel_ häufiger als mehrere Packages in einer Datei.

Eine Package-Deklaration explizit hinzuschreiben, sollte ansich
nicht der Arbeitsaufwand sein. De facto haben Dateien und Packages
fast gar nichts miteinander zu tun: Eine Datei kann mehrere Packages
enthalten, ein Package kann sich über mehrere Dateien erstrecken.
Beide Möglichkeiten zu haben, finde ich wichtig, vor allem letztere.

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

Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Guten Tag,

ich lese gerade die Perl Best Practices von Conway (2005). Darin
irritiert mich in den Abschnitten mit den Inside-Out-Objekten die
Verwendung von -- meines Erachtens -- doch überflüssigen Geschweiften
bei der Klassendefinition:

package Klasse;
{
# Klassendefinition
my %name_of;
# ...
}

1;

Ist es nicht so, dass my-deklarierte Paketvariablen so oder so nicht von
außerhalb desselben Pakets angesprochen werden können? Dies scheinen mir
auch einfache Tests zu bestätigen. Warum also sind diese Klammern
"unerlässlich", "vital"? Wie könnte man auf die Objektattribute trotzdem
zugreifen, wenn sie nicht nochmal extra in einen Block gefasst wären?


Grüße,
Florian Heß.

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Robert 'phaylon' Sedlacek schrieb:
> Florian Hess wrote:
>> Ist es nicht so, dass my-deklarierte Paketvariablen so oder so nicht von
>> außerhalb desselben Pakets angesprochen werden können? Dies scheinen mir
>> auch einfache Tests zu bestätigen. Warum also sind diese Klammern
>> "unerlässlich", "vital"? Wie könnte man auf die Objektattribute trotzdem
>> zugreifen, wenn sie nicht nochmal extra in einen Block gefasst wären?
>
> #--- test.pl ---#
> package Foo;
> use strict;
> my $foo = 23;
>
> package Bar;
> use strict;
> print "$foo\n";
> #--- --- --- ---#
>
> gibt 23 aus.
>

Vielen Dank! In der Beschreibung von my() steht ja auch


A "my" declares the listed variables to be local (lexically) to
the enclosing block, file, or "eval".


Da hat wahrscheinlich mein Gedächtnis frech ein "package" in diesen Satz
gemogelt.

Grüße,
F. H.

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Thomas Wittek:

> *Ausschweif*: Ich fände es sogar gut, wenn die package-Deklaration
> optional ist und aus dem Pfad Foo/Bar/Baz.pm des Moduls das Paket
> Foo::Bar::Baz impliziert.

Der Zusammenhang zwischen Datei- und Packagename ist eine Konvention,
aber kein Erfordernis. Manchmal enthält eine Datei mehrere Packages
oder (der häufigere Fall) Funktionen bzw. Methoden eines Packages
sind über mehrere Dateien verteilt. Das wäre dann nicht mehr bzw. nur
noch über Umwege möglich.

Eine "package"-Deklaration am Beginn einer Datei halte ich schon
deswegen für sinnvoll, weil sie einem Leser auch ohne Kenntnis des
Dateinamens mitteilt, dass der darin enthaltene Code in einem eigenen
Namensraum abläuft - üblicherweise deswegen, weil es sich um
zuladbaren Code handelt. Ich gehe beim Antreffen von Code ohne
einleitendes "package" davon aus, dass er im Package "main"
als Hauptprogramm abläuft, es sich ansonsten aber um Library-
oder Modulcode handelt (auch wenn das nicht notwendigerweise
so sein muss, in 99,9% aller Fälle stimmt es jedoch).

Denkbar wäre eine auf Befehleszeilenebene spezifizierbare Option,
die implizit aus dem Dateinamen eine Packagenamen bildet, etwa
so, wie dies mod_perl oder PersPerl tun, wenn sie Hauptprogramme
als Funktionen kompilieren. Du könntest ja mal anfragen, wie p5p
darüber denken.

LG, Ferry

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

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Frank Seitz:

> Wirklich nötig sind die Klammern auch dann nicht.
> Sie generell zu verwenden, finde ich ein bisschen paranoiamäßig.

Geschwungene Klammern dienen hier zwei Zwecken:

1) Sie legen einen eigenen Scope, d.h., Geltungsbereich an (das
passiert beim Kompilieren). Deklarationsanweisungen, die an
Scopegrenzen gebunden sind (dazu zählen "my", "our", aber eben
auch "package") wirken dann nur innerhalb dieses Scopes,
außerhalb davon sind sie gegenstandlos. Möchte man daher
nur einen bestimmten Codeteil in einen eigenen Namensraum
kompilieren, kann man z.B.

package A;
our $hallo = 'A'; # $A::hallo
{
package B;
our $hallo = 'B'; # $B::hello
print "$hallo\n"; # Gibt "B" aus
}
print "$hallo\n"; # Gibt "A" aus

schreiben. Bis zum Ende des Scopes ist der an dessen
Anfang eingestellte Namensraum gültig, danach wieder der
vorher Eingestellte. Beachte, dass es sich bei "$hallo" um
zwei globale (und nicht etwas lexikalische) Variable handelt;
man könnte das "our" - so man nicht "use strict 'vars'" ver-
wendet - auch weglassen. Beachte auch, dass hier nicht
local-isiert wurde, wir machen uns hier nur den reduzierten
Geltungsbereich von "package" zunutze.

2) Sie repräsentieren einen Codeblock (d.h., eine genau
einmal ausgeführte Schleife). Daher sind innerhalb von {...}
auch Anweisungen wie "last" erlaubt, die dazu führen, dass
der restliche Block nicht mehr ausgeführt wird:

{
open my $IN,'<',$input_file or last;
...
}
die $! if $!;

Geht das open nicht gut, wird mit der dem Blockende
folgenden Anweisung weitergemacht. Das Ganze ist ein
wenig verwandt mit einem Block-eval; allerdings werden
hier Laufzeitfehler, die zu einem Programabbruch führen,
nicht abgefangen (deswegen sind solche Blöcke, soferne
man keine solchen Laufzeitfehler behandeln muss, auch
effizienter als Block-eval's und diesen vorzuziehen).

> Eine Package-Deklaration explizit hinzuschreiben, sollte ansich
> nicht der Arbeitsaufwand sein. De facto haben Dateien und Packages
> fast gar nichts miteinander zu tun: Eine Datei kann mehrere Packages
> enthalten, ein Package kann sich über mehrere Dateien erstrecken.
> Beide Möglichkeiten zu haben, finde ich wichtig, vor allem letztere.

Ich auch. Tatsächlich repräsentieren Dateien auch nur Scopes,
d.h., man kann sich den Code einer Datei von {...} umschlossen
vorstellen.

Florian Hess:

> Ist es nicht so, dass my-deklarierte Paketvariablen so oder so nicht von
> außerhalb desselben Pakets angesprochen werden können?

Hier liegt ein Widerspruch in sich vor - eine mit "my" deklariere
Variable ist keine Paketvariable. "my" Deklarationen wirken
auf Scopes, nicht auf Pakete (bzw. Symboltabellen). Solche
Variable kann man nur innerhalb des Scopes (Blocks), in dem
sie deklariert wurden, ansprechen. Eine "package"-Deklaration
hat nichts damit zu tun:

{
my $hallo = "Hallo";
package A;
print "$hallo\n"; # Gibt "Hallo" aus
package B;
print "$hallo\n"; # Gibt immer noch "Hallo" aus
}
print "$hallo"; # Gibt nichts (bzw. "use of uninitialized value")
aus

Die Verwandtschaft von Scopes und "package" liegt darin,
dass auch "package" an Scopegrenzen gebunden ist. Daraus
resultiert in Zusammenhang mit der bereits erwähnten Tatsache,
dass auch Dateien Scopes repräsentieren, dass "package"
Deklaration immer nur in der Datei, in der sie aufscheinen,
gültig sind. Daran ändert auch nichts, dass "package" den
Namensraum _globaler_ (d.h. aus allen Dateien heraus
ansprechbarer) Variablen festlegt.

Ach, gäbe es "perlscopetut" doch schon!... ;-)

> Warum also sind diese Klammern "unerlässlich", "vital"?

Das sind sie hier nicht. Damian wollte damit nur die
Wirkungsweise von Inside-Out-Objekten hervorheben:
durch die Deklaration einer lexikalischen Variable kann
auf diese nur innerhalb der Datei, in der die Deklaration
erfolgt ist, zugegriffen werden, wodurch das bei Perl-
Objekten sonst nicht vorhandene Prinzip des Kapselung
(man soll auf Objekte und ihre Attribute nur über bereit-
gestellte Methoden zugreifen können) möglich wird.
Damian wollte mit den zusätzlichen Klammern eben das
verdeutlichen, was ich weiter oben schon erwähnt habe:
jede Datei repräsentiert einen eigenen Scope. In dem
von dir gezeigten Beispiel wurde eigentlich zwei Scopes
verschachtelt:

{ # Dateiscope
package Klasse;
{
my %name_of;
....
}
} # Ende des Dateiscopes

Da - abgesehen von der "package" Deklaration - im
äußeren Scope nichts aufscheint, ist der innere Scope
überflüssig.

LG, Ferry

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

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Ferry Bolhar wrote:
>
> Geschwungene Klammern dienen hier zwei Zwecken:
>
> 1) Sie legen einen eigenen Scope, d.h., Geltungsbereich an (das
> passiert beim Kompilieren). Deklarationsanweisungen, die an
> Scopegrenzen gebunden sind (dazu zählen "my", "our", aber eben
> auch "package") wirken dann nur innerhalb dieses Scopes,
> außerhalb davon sind sie gegenstandlos. Möchte man daher
> nur einen bestimmten Codeteil in einen eigenen Namensraum
> kompilieren, kann man z.B.
>
> package A;
> our $hallo = 'A'; # $A::hallo
> {
> package B;
> our $hallo = 'B'; # $B::hello
> print "$hallo\n"; # Gibt "B" aus
> }
> print "$hallo\n"; # Gibt "A" aus
>
> schreiben. Bis zum Ende des Scopes ist der an dessen
> Anfang eingestellte Namensraum gültig, danach wieder der
> vorher Eingestellte. Beachte, dass es sich bei "$hallo" um
> zwei globale (und nicht etwas lexikalische) Variable handelt;
> man könnte das "our" - so man nicht "use strict 'vars'" ver-
> wendet - auch weglassen. Beachte auch, dass hier nicht
> local-isiert wurde, wir machen uns hier nur den reduzierten
> Geltungsbereich von "package" zunutze.

Our ist m.E. nicht so sehr das Problem, da getrennte
our-Deklarationen für verschiedene Packages je Datei möglich sind.
Das Problem sehe ich bei my, da sowas nicht warnungsfrei durchläuft:

use warnings;
package A;
my $a;
package B;
my $a;

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: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Ferry Bolhar wrote:

> Hier liegt ein Widerspruch in sich vor - eine mit "my" deklariere
> Variable ist keine Paketvariable. "my" Deklarationen wirken
> auf Scopes, nicht auf Pakete (bzw. Symboltabellen). Solche
> Variable kann man nur innerhalb des Scopes (Blocks), in dem
> sie deklariert wurden, ansprechen. Eine "package"-Deklaration
> hat nichts damit zu tun:

Der Vollständigkeit halber: our $foo wird zwar an den Namensraum des
jeweiligen Pakets gebunden, der Name '$foo' ist aber auch lexikalisch
gebunden, wie mit 'my'.

..phaylon

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Frank Seitz:

> Our ist m.E. nicht so sehr das Problem, da getrennte
> our-Deklarationen für verschiedene Packages je Datei möglich sind.

Ja. Allerdings kann es aufgrund der Implementierung mit "our" zu
Problemen kommen, wenn die getrennten Packages im selben
Scope verwendet werden:

package A;
our $x = 1;
print $x; # Gibt 1 aus
package B;
our $x = 2;
print $x; # Gibt 2 aus
package A;
print $x; # Gibt wieder 1 aus? Nein, gibt immer noch 2 aus!

Das liegt daran, dass das erste "our" einen lexikalischen Alias
auf die globale Variable $A::x anlegt. Dieser wird durch das
zweite "our" ohne jeden Hinweis (auch nicht mit "use warnings")
mit $B::x überschrieben. Ich meide daher solche Konstrukte.

Ich hatte "our" in meinem Code nur verwendet, damit sich nicht
irgend jemand aufregt, dass ich es nicht tue bzw. nicht "use strict"-
konformen Code in meinen Beispielen verwende... ;-)

LG, Ferry

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

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Thomas Wittek wrote:

> Wobei ich seltenst -- und wenn, dann fast ausschließlich zu Testzwecken
> -- mehrere Packages in einer Datei habe. Und nur in diesem (bei mir
> seltenen) Falle sind die Klammern wohl nötig.

Ich tue das eigentlich nie, weil:

package Foo;
sub import { warn "Foo" }

package Bar;
use Bar;

'Foo.pm' auf der Festplatte sucht. Man müsste

package Foo;
BEGIN { $INC{'Foo.pm'}++ }
sub import { warn "Foo" }

schreiben.

> *Ausschweif*: Ich fände es sogar gut, wenn die package-Deklaration
> optional ist und aus dem Pfad Foo/Bar/Baz.pm des Moduls das Paket
> Foo::Bar::Baz impliziert.

Das wäre mir zu empfindlich :)

..phaylon

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Robert 'phaylon' Sedlacek wrote:
> Thomas Wittek wrote:
>>
>>Wobei ich seltenst -- und wenn, dann fast ausschließlich zu Testzwecken
>>-- mehrere Packages in einer Datei habe. Und nur in diesem (bei mir
>>seltenen) Falle sind die Klammern wohl nötig.
>
> Ich tue das eigentlich nie, weil:
>
> package Foo;
> sub import { warn "Foo" }
>
> package Bar;
> use Bar;
^^^
Da muss wohl "Foo" stehen.

> 'Foo.pm' auf der Festplatte sucht. Man müsste
>
> package Foo;
> BEGIN { $INC{'Foo.pm'}++ }
> sub import { warn "Foo" }

"use Foo" zu schreiben, wenn es Foo.pm nicht gibt,
ist IMO ein Programmierfehler.

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: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Ferry Bolhar wrote:
> Frank Seitz:
>>
>>Our ist m.E. nicht so sehr das Problem, da getrennte
>>our-Deklarationen für verschiedene Packages je Datei möglich sind.
>
> Ja. Allerdings kann es aufgrund der Implementierung mit "our" zu
> Problemen kommen, wenn die getrennten Packages im selben
> Scope verwendet werden:
>
> package A;
> our $x = 1;
> print $x; # Gibt 1 aus
> package B;
> our $x = 2;
> print $x; # Gibt 2 aus
> package A;
> print $x; # Gibt wieder 1 aus? Nein, gibt immer noch 2 aus!
>
> Das liegt daran, dass das erste "our" einen lexikalischen Alias
> auf die globale Variable $A::x anlegt. Dieser wird durch das
> zweite "our" ohne jeden Hinweis (auch nicht mit "use warnings")
> mit $B::x überschrieben. Ich meide daher solche Konstrukte.

Wenn Du geschweifte Klammern um die our-Deklarationen
stetzt, klappt es:

package A;
{ our $x = 1; }
package B;
{ our $x = 2; }
package A;
print $x; # Gibt 1 aus

Meine obigen Aussage nehme ich damit wieder zurück :)

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: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Robert 'phaylon' Sedlacek:

> Der Vollständigkeit halber: our $foo wird zwar an den Namensraum des
> jeweiligen Pakets gebunden, der Name '$foo' ist aber auch lexikalisch
> gebunden, wie mit 'my'.

Das habe ich gemeint, als ich schrieb, dass '"our" einen lexikalischen Alias
anlegt'. Möglicherweise habe ich mich dabei ungenau ausgedrückt, sorry.

Das ist ja auch der Grund, warum innerhalb desselben Scopes dieselbe
Variable nur entweder mit "my" oder mit "our" deklariert werden kann.

LG, Ferry

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

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Frank Seitz wrote:
> Robert 'phaylon' Sedlacek wrote:
>> package Bar;
>> use Bar;
>
> ^^^
> Da muss wohl "Foo" stehen.

Ja.

> "use Foo" zu schreiben, wenn es Foo.pm nicht gibt,
> ist IMO ein Programmierfehler.

Finde ich nicht.

1. Sollte ich mich nicht darum kümmern müssen, wie jemand seine Packages
sortiert. Ich würde es eher als Programmierfehler sehen, ein global
verfügbares Package innerhalb eines anderen zu definieren. Mindestens
aber ist es unguter Stil.

2. @INC kann Code Referenzen enthalten.

3. Ein Paket zu deklarieren es aber in %INC nicht zu vermerken empfinde
ich eher als Programmierfehler.

4. CPAN hat damit Probleme. Wenn ich bei CPAN nach Foo::Bar suche, aber
die Deklaration irgendwo in Foo::Baz steht, und ich Foo::Bar
veröffentliche, können grausliche Probleme auftreten.

Dann am besten gleich sauber.

..phaylon

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>
>>"use Foo" zu schreiben, wenn es Foo.pm nicht gibt,
>>ist IMO ein Programmierfehler.
>
> Finde ich nicht.
>
> 1. Sollte ich mich nicht darum kümmern müssen, wie jemand seine Packages
> sortiert. Ich würde es eher als Programmierfehler sehen, ein global
> verfügbares Package innerhalb eines anderen zu definieren. Mindestens
> aber ist es unguter Stil.

Wie schon gesagt, ist Package != Datei. Zwischen Packages und
Dateien gibt es in Perl keine vorgegebene Beziehung.

> 2. @INC kann Code Referenzen enthalten.

Na und?

> 3. Ein Paket zu deklarieren es aber in %INC nicht zu vermerken empfinde
> ich eher als Programmierfehler.

Schön, aber das ist eine abstruse Ansicht.

> 4. CPAN hat damit Probleme. Wenn ich bei CPAN nach Foo::Bar suche, aber
> die Deklaration irgendwo in Foo::Baz steht, und ich Foo::Bar
> veröffentliche, können grausliche Probleme auftreten.

Es kommt in CPAN-Modulen sicherlich öfter vor, dass mehrere Packages
innerhalb einer Datei definiert werden.

> Dann am besten gleich sauber.

Es kommt, wie meist, darauf an, was man erreichen will.
Ich finde z.B. nichts dabei, wenn mehrere kleinere Packages, die
zusammengehören und entweder alle oder garnicht genutzt werden,
in einer einzelnen Datei definiert sind.

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: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Robert 'phaylon' Sedlacek writes:

> Frank Seitz wrote:
> > Robert 'phaylon' Sedlacek wrote:
> >> package Bar;
> >> use Bar;
> >
> > ^^^
> > Da muss wohl "Foo" stehen.
>
> Ja.
>
> > "use Foo" zu schreiben, wenn es Foo.pm nicht gibt,
> > ist IMO ein Programmierfehler.
>
> Finde ich nicht.
>
[...]
>
> 4. CPAN hat damit Probleme. Wenn ich bei CPAN nach Foo::Bar suche, aber
> die Deklaration irgendwo in Foo::Baz steht, und ich Foo::Bar
> veröffentliche, können grausliche Probleme auftreten.

Welcher Art? Man muss nur vermeiden, dass zwei Dateien, die gleiche
Package-Namen enthalten, vom PAUSE-Indexer gesehen werden. Dazu reicht
es wenn man die Package-Deklaration in einer der beiden Dateien in der
Form

package
My::Module;

schreibt.

Gruß,
Slaven

--
Slaven Rezic - slaven rezic de

need xpm or ppm output from GD?
http://search.cpan.org/search?mode=module&query=GD::Convert

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Frank Seitz:

> Es kommt in CPAN-Modulen sicherlich öfter vor, dass mehrere Packages
> innerhalb einer Datei definiert werden.

Ja. Schau dir mal Parse::RecDescent an.

> Es kommt, wie meist, darauf an, was man erreichen will.
> Ich finde z.B. nichts dabei, wenn mehrere kleinere Packages, die
> zusammengehören und entweder alle oder garnicht genutzt werden,
> in einer einzelnen Datei definiert sind.

Ich auch nicht. Allerdings würde ich hier klar unterscheiden zwischen
den Sachen für den "Hausgebrauch" und solchen Dingen, die ich für
andere bereitstelle bzw. ins CPAN stelle.

LG, Ferry

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

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Ferry Bolhar wrote:
> Frank Seitz:
>>
>>Es kommt in CPAN-Modulen sicherlich öfter vor, dass mehrere Packages
>>innerhalb einer Datei definiert werden.
>
> Ja. Schau dir mal Parse::RecDescent an.

Ich zähle 19 Packages in der Datei.

>>Es kommt, wie meist, darauf an, was man erreichen will.
>>Ich finde z.B. nichts dabei, wenn mehrere kleinere Packages, die
>>zusammengehören und entweder alle oder garnicht genutzt werden,
>>in einer einzelnen Datei definiert sind.
>
> Ich auch nicht. Allerdings würde ich hier klar unterscheiden zwischen
> den Sachen für den "Hausgebrauch" und solchen Dingen, die ich für
> andere bereitstelle bzw. ins CPAN stelle.

Parse::RecDescent fällt sicherlich nicht unter "Hausgebrauch".
Der Punkt ist doch, dass Perl die Art Paketverteilung über Dateien
nicht vorgibt, dies frei entschieden werden kann und eine entsprechende
Vielfalt aus den verschiedensten Gründen real existiert.

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: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Frank Seitz wrote:
> Robert 'phaylon' Sedlacek wrote:
>
>>Frank Seitz wrote:
>>
>>>"use Foo" zu schreiben, wenn es Foo.pm nicht gibt,
>>>ist IMO ein Programmierfehler.
>>
> Wie schon gesagt, ist Package != Datei. Zwischen Packages und
> Dateien gibt es in Perl keine vorgegebene Beziehung.

Du widersprichst dir. Ich darf 'use Foo' nicht schreiben, wenn kein
Foo.pm da ist, aber die Datei hat nichts mit dem Package zu tun?

>>2. @INC kann Code Referenzen enthalten.
>
> Na und?

Foo kann sonstwo herkommen. Es kann sogar on-the-fly erzeugt werden.
Auch keine Foo.pm da.

>>3. Ein Paket zu deklarieren es aber in %INC nicht zu vermerken empfinde
>> ich eher als Programmierfehler.
>
> Schön, aber das ist eine abstruse Ansicht.

Kannst du dies begründen?

>>4. CPAN hat damit Probleme. Wenn ich bei CPAN nach Foo::Bar suche, aber
>> die Deklaration irgendwo in Foo::Baz steht, und ich Foo::Bar
>> veröffentliche, können grausliche Probleme auftreten.
>
> Es kommt in CPAN-Modulen sicherlich öfter vor, dass mehrere Packages
> innerhalb einer Datei definiert werden.

Das macht es nicht besser.

>>Dann am besten gleich sauber.
>
> Es kommt, wie meist, darauf an, was man erreichen will.
> Ich finde z.B. nichts dabei, wenn mehrere kleinere Packages, die
> zusammengehören und entweder alle oder garnicht genutzt werden,
> in einer einzelnen Datei definiert sind.

Ich finde es eben einfach unübersichtlich. Wenn das Paket schon statisch
ist, also nicht zur Laufzeit gebaut wird, kann es auch eine eigene Datei
haben.

..phaylon

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Frank Seitz wrote:

> Parse::RecDescent fällt sicherlich nicht unter "Hausgebrauch".
> Der Punkt ist doch, dass Perl die Art Paketverteilung über Dateien
> nicht vorgibt, dies frei entschieden werden kann und eine entsprechende
> Vielfalt aus den verschiedensten Gründen real existiert.

Dass es möglich ist, ist wohl allen klar. Es geht gerade darum, ob es
sinnvoll ist. Und da bin ich eben der Meinung: Nur mit Ausnahmen, nicht
in der Regel.

..phaylon

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Slaven Rezic wrote:
>>4. CPAN hat damit Probleme. Wenn ich bei CPAN nach Foo::Bar suche, aber
>> die Deklaration irgendwo in Foo::Baz steht, und ich Foo::Bar
>> veröffentliche, können grausliche Probleme auftreten.
>
> Welcher Art? Man muss nur vermeiden, dass zwei Dateien, die gleiche
> Package-Namen enthalten, vom PAUSE-Indexer gesehen werden. Dazu reicht
> es wenn man die Package-Deklaration in einer der beiden Dateien in der
> Form [...]

Ich rede nicht vom Indexer. Man nehme an, ich lade Foo-Bar auf CPAN
hoch. Diese enthält 'Foo::Bar,' und darin gleich mit 'Foo::Bar::Baz.'
Letzteres sieht der Indexer nicht, und ich sehe es auch nicht, ausser
ich suche danach. Wenn jetzt jemand aus dieser Unwissenheit eine
Abwandlung von 'Foo::Bar' namens 'Foo::Bar::Baz' hochlädt, und ich beide
lade, sind Konflikte quasi vorprogrammiert.

Es gibt Dinge, von denen braucht der Indexer nichts zu wissen. Aber das
ist IMO eher eine Ausnahme als die Regel.

..phaylon

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>Robert 'phaylon' Sedlacek wrote:
>>>Frank Seitz wrote:
>>>>
>>>>"use Foo" zu schreiben, wenn es Foo.pm nicht gibt,
>>>>ist IMO ein Programmierfehler.
>>>
>>Wie schon gesagt, ist Package != Datei. Zwischen Packages und
>>Dateien gibt es in Perl keine vorgegebene Beziehung.
>
> Du widersprichst dir. Ich darf 'use Foo' nicht schreiben, wenn kein
> Foo.pm da ist, aber die Datei hat nichts mit dem Package zu tun?

Hm, ich kann einen Gedankengang, der zu einem Widerspruch
führen soll, nicht erkennen. Den Text, auf den ich mich bezog,
hast Du rausgelöscht.

>>>2. @INC kann Code Referenzen enthalten.
>>
>>Na und?
>
> Foo kann sonstwo herkommen. Es kann sogar on-the-fly erzeugt werden.
> Auch keine Foo.pm da.

Na schön, es sollte etwas Ladbares da sein. In Deinem Beispiel
war nichts Ladbares da.

>>>3. Ein Paket zu deklarieren es aber in %INC nicht zu vermerken empfinde
>>> ich eher als Programmierfehler.
>>
>>Schön, aber das ist eine abstruse Ansicht.
>
> Kannst du dies begründen?

Aus perlvar:

%INC The hash %INC contains entries for each filename included via
the "do", "require", or "use" operators. The key is the
filename you specified (with module names converted to
pathnames), and the value is the location of the file found.
The "require" operator uses this hash to determine whether a
particular file has already been included.

If the file was loaded via a hook (e.g. a subroutine reference,
see "require" in perlfunc for a description of these hooks),
this hook is by default inserted into %INC in place of a
filename. Note, however, that the hook may have set the %INC
entry by itself to provide some more specific info.

In der Erklärung kommt das Wort "package" nicht vor,
das sagt doch eigentlich alles.

> Ich finde es eben einfach unübersichtlich. Wenn das Paket schon statisch
> ist, also nicht zur Laufzeit gebaut wird, kann es auch eine eigene Datei
> haben.

Ja, kann. Muss aber nicht.

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: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>
>>Parse::RecDescent fällt sicherlich nicht unter "Hausgebrauch".
>>Der Punkt ist doch, dass Perl die Art Paketverteilung über Dateien
>>nicht vorgibt, dies frei entschieden werden kann und eine entsprechende
>>Vielfalt aus den verschiedensten Gründen real existiert.
>
> Dass es möglich ist, ist wohl allen klar. Es geht gerade darum, ob es
> sinnvoll ist. Und da bin ich eben der Meinung: Nur mit Ausnahmen, nicht
> in der Regel.

Gründe für das Zusammenfassen mehrerer Packages in einer
Datei dürften sein: 1) vom Entwickler einfacher zu handhaben,
2) vom Interpreter schneller zu laden.

Ob jeder das als "sinnvolle Gründe" anerkennt, sei dahingestellt.

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: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Frank Seitz schrieb:
> Gründe für das Zusammenfassen mehrerer Packages in einer
> Datei dürften sein:
> 1) vom Entwickler einfacher zu handhaben,

Ich find's nicht besonders schwer, eine neue Datei anzulegen.

Allerdings finde ich es höchst sinnvoll, da man normalerweise mehrere
Packages erstellt, weil sie irgendwie voneinander abgrenzbar sind.
Dann macht es um so mehr Sinn, den Code in verschiedene Dateien zu packen.

> 2) vom Interpreter schneller zu laden.

Ich halte den Aufwand des Öffnens einer Datei im Vergleich zum
Parsen/Compilieren/Ausführen für vernachlässigbar.

--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: streawkceur@jabber.i-pobox.net

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Robert 'phaylon' Sedlacek writes:

> Slaven Rezic wrote:
> >>4. CPAN hat damit Probleme. Wenn ich bei CPAN nach Foo::Bar suche, aber
> >> die Deklaration irgendwo in Foo::Baz steht, und ich Foo::Bar
> >> veröffentliche, können grausliche Probleme auftreten.
> >
> > Welcher Art? Man muss nur vermeiden, dass zwei Dateien, die gleiche
> > Package-Namen enthalten, vom PAUSE-Indexer gesehen werden. Dazu reicht
> > es wenn man die Package-Deklaration in einer der beiden Dateien in der
> > Form [...]
>
> Ich rede nicht vom Indexer. Man nehme an, ich lade Foo-Bar auf CPAN
> hoch. Diese enthält 'Foo::Bar,' und darin gleich mit 'Foo::Bar::Baz.'
> Letzteres sieht der Indexer nicht, und ich sehe es auch nicht, ausser
> ich suche danach. Wenn jetzt jemand aus dieser Unwissenheit eine
> Abwandlung von 'Foo::Bar' namens 'Foo::Bar::Baz' hochlädt, und ich beide
> lade, sind Konflikte quasi vorprogrammiert.

Bist du sicher, dass es so ist? Auf meiner Pause-Seite sehe ich
z.B.folgendes:

Tk::WidgetDump SREZIC first-come
Tk::WidgetDump::Anchor SREZIC first-come
Tk::WidgetDump::Background SREZIC first-come
Tk::WidgetDump::Bitmap SREZIC first-come
Tk::WidgetDump::Bool SREZIC first-come
Tk::WidgetDump::BorderWidth SREZIC first-come
Tk::WidgetDump::BrowseEntry SREZIC first-come
Tk::WidgetDump::Color SREZIC first-come
Tk::WidgetDump::Command SREZIC first-come
Tk::WidgetDump::Cursor SREZIC first-come
Tk::WidgetDump::Entry SREZIC first-come
Tk::WidgetDump::Font SREZIC first-come
Tk::WidgetDump::Foreground SREZIC first-come
Tk::WidgetDump::Height SREZIC first-come
Tk::WidgetDump::HighlightBackground SREZIC first-come
Tk::WidgetDump::HighlightColor SREZIC first-come
Tk::WidgetDump::HighlightThickness SREZIC first-come
Tk::WidgetDump::Image SREZIC first-come
Tk::WidgetDump::Justify SREZIC first-come
Tk::WidgetDump::NumEntry SREZIC first-come
Tk::WidgetDump::Pad SREZIC first-come
Tk::WidgetDump::Pixels SREZIC first-come
Tk::WidgetDump::Relief SREZIC first-come
Tk::WidgetDump::Tile SREZIC first-come
Tk::WidgetDump::Underline SREZIC first-come
Tk::WidgetDump::Width SREZIC first-come
Tk::WidgetDump::_MyNumEntry SREZIC first-come

Es existiert aber nur die Datei Tk/WidgetDump.pm

>
> Es gibt Dinge, von denen braucht der Indexer nichts zu wissen. Aber das
> ist IMO eher eine Ausnahme als die Regel.
>

Gruß,
Slaven

--
Slaven Rezic - slaven rezic de

Start a WWW browser - OS independent:
http://user.cs.tu-berlin.de/~eserte/src/perl/WWWBrowser/

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Thomas Wittek writes:

> Frank Seitz schrieb:
> > Gründe für das Zusammenfassen mehrerer Packages in einer
> > Datei dürften sein:
> > 1) vom Entwickler einfacher zu handhaben,
>
> Ich find's nicht besonders schwer, eine neue Datei anzulegen.
>
> Allerdings finde ich es höchst sinnvoll, da man normalerweise mehrere
> Packages erstellt, weil sie irgendwie voneinander abgrenzbar sind.

Nun ja. Es gibt auch die Fälle, wo man viele "Mini"-Packages erzeugt,
die nur drei-vier Zeilen lang sind und alle von einem anderen Klasse
erben, also irgendwie miteinander verwandt sind. Da möchte ich nicht
viele Dateien erzeugen.

> Dann macht es um so mehr Sinn, den Code in verschiedene Dateien zu packen.
>
> > 2) vom Interpreter schneller zu laden.
>
> Ich halte den Aufwand des Öffnens einer Datei im Vergleich zum
> Parsen/Compilieren/Ausführen für vernachlässigbar.
>

Gruß,
Slaven

--
Slaven Rezic - slaven rezic de

Berlin Perl Mongers - http://berlin.pm.org

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Frank Seitz wrote:
> Robert 'phaylon' Sedlacek wrote:
>
>>Du widersprichst dir. Ich darf 'use Foo' nicht schreiben, wenn kein
>>Foo.pm da ist, aber die Datei hat nichts mit dem Package zu tun?
>
> Hm, ich kann einen Gedankengang, der zu einem Widerspruch
> führen soll, nicht erkennen. Den Text, auf den ich mich bezog,
> hast Du rausgelöscht.

Dann hier etwas detaillierter:

Aussage A) "use Foo" zu schreiben, wenn es Foo.pm nicht gibt, ist IMO
ein Programmierfehler.

Aussage B) Zwischen Packages und Dateien gibt es in Perl keine
vorgegebene Beziehung.

>>Foo kann sonstwo herkommen. Es kann sogar on-the-fly erzeugt werden.
>>Auch keine Foo.pm da.
>
> Na schön, es sollte etwas Ladbares da sein. In Deinem Beispiel
> war nichts Ladbares da.

In welchem?

>>>>3. Ein Paket zu deklarieren es aber in %INC nicht zu vermerken empfinde
>>>> ich eher als Programmierfehler.
>>>
>>>Schön, aber das ist eine abstruse Ansicht.
>>
>>Kannst du dies begründen?
>
>
> Aus perlvar:
>
> %INC The hash %INC contains entries for each filename included via
> the "do", "require", or "use" operators. The key is the
> filename you specified (with module names converted to
> pathnames), and the value is the location of the file found.
> The "require" operator uses this hash to determine whether a
> particular file has already been included.
>
> If the file was loaded via a hook (e.g. a subroutine reference,
> see "require" in perlfunc for a description of these hooks),
> this hook is by default inserted into %INC in place of a
> filename. Note, however, that the hook may have set the %INC
> entry by itself to provide some more specific info.
>
> In der Erklärung kommt das Wort "package" nicht vor,
> das sagt doch eigentlich alles.

Nein, tut es nicht. Da steht aber, dass %INC bei Code Referenzen gesetzt
wird, und dass diese selbst auch mehr Informationen da reinsetzen
können. 'require' definiert auch, wie es %INC verwendet. In Anbetracht
dieser Informationen finde ich es nur sinnvoll, %INC korrekt anzupassen,
wenn man ein package direkt deklariert.

>>Ich finde es eben einfach unübersichtlich. Wenn das Paket schon statisch
>>ist, also nicht zur Laufzeit gebaut wird, kann es auch eine eigene Datei
>>haben.
>
> Ja, kann. Muss aber nicht.

Natürlich muss es nicht, darum ging es mir aber auch garnicht.

..phaylon

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Slaven Rezic wrote:

> Bist du sicher, dass es so ist? Auf meiner Pause-Seite sehe ich
> z.B.folgendes:

Gut, ich fühle mich mal korrigiert :) Ich dachte, der Indexer scannt den
Rest der Datei nicht. Aber die meisten meiner on-the-fly packages werden
sowieso dynamisch erzeugt, darum fiel mir das wohl nicht auf.

..phaylon

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>Robert 'phaylon' Sedlacek wrote:
>>>
>>>Du widersprichst dir. Ich darf 'use Foo' nicht schreiben, wenn kein
>>>Foo.pm da ist, aber die Datei hat nichts mit dem Package zu tun?
>>
>>Hm, ich kann einen Gedankengang, der zu einem Widerspruch
>>führen soll, nicht erkennen. Den Text, auf den ich mich bezog,
>>hast Du rausgelöscht.
>
> Dann hier etwas detaillierter:
>
> Aussage A) "use Foo" zu schreiben, wenn es Foo.pm nicht gibt, ist IMO
> ein Programmierfehler.
>
> Aussage B) Zwischen Packages und Dateien gibt es in Perl keine
> vorgegebene Beziehung.

Und wo ist der Widerspruch?

>>>Foo kann sonstwo herkommen. Es kann sogar on-the-fly erzeugt werden.
>>>Auch keine Foo.pm da.
>>
>>Na schön, es sollte etwas Ladbares da sein. In Deinem Beispiel
>>war nichts Ladbares da.
>
> In welchem?

<46237b72$0$23131$9b4e6d93@newsspool1.arcor-online.net>

>>>>>3. Ein Paket zu deklarieren es aber in %INC nicht zu vermerken empfinde
>>>>>ich eher als Programmierfehler.
>>>>
>>>>Schön, aber das ist eine abstruse Ansicht.
>>>
>>>Kannst du dies begründen?
>>
>>Aus perlvar:
>>
>>%INC The hash %INC contains entries for each filename included via
>> the "do", "require", or "use" operators. The key is the
>> filename you specified (with module names converted to
>> pathnames), and the value is the location of the file found.
>> The "require" operator uses this hash to determine whether a
>> particular file has already been included.
>>
>> If the file was loaded via a hook (e.g. a subroutine reference,
>> see "require" in perlfunc for a description of these hooks),
>> this hook is by default inserted into %INC in place of a
>> filename. Note, however, that the hook may have set the %INC
>> entry by itself to provide some more specific info.
>>
>>In der Erklärung kommt das Wort "package" nicht vor,
>>das sagt doch eigentlich alles.
>
> Nein, tut es nicht. Da steht aber, dass %INC bei Code Referenzen gesetzt
> wird, und dass diese selbst auch mehr Informationen da reinsetzen
> können. 'require' definiert auch, wie es %INC verwendet. In Anbetracht
> dieser Informationen finde ich es nur sinnvoll, %INC korrekt anzupassen,
> wenn man ein package direkt deklariert.

Das sagtest Du schon. Packages sind in %INC nur nicht verzeichnet,
sondern Modulnamen (oder - geschenkt - Codereferenzen). %INC dient dazu,
erfolgte Ladevorgänge zu protokollieren, um diese nicht unnötig zu
wiederholen. Welche Packages existieren, ergibt sich
aus der Hierarchie der Stashes, nicht aus %INC.

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: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Frank Seitz wrote:
> Robert 'phaylon' Sedlacek wrote:
>
>>Aussage A) "use Foo" zu schreiben, wenn es Foo.pm nicht gibt, ist IMO
>>ein Programmierfehler.
>>
>>Aussage B) Zwischen Packages und Dateien gibt es in Perl keine
>>vorgegebene Beziehung.
>
>
> Und wo ist der Widerspruch?

Offensichtlich besteht doch eine vorgegebene Beziehung. Und zwar dass
'use Foo::Bar' nach 'Foo/Bar.pm' sucht. Daher setzt das 'use' die Datei
_oder_ einen entsprechenden %INC Eintrag voraus.

> <46237b72$0$23131$9b4e6d93@newsspool1.arcor-online.net>

Ich suche mir das später nochmal raus.

> Das sagtest Du schon. Packages sind in %INC nur nicht verzeichnet,
> sondern Modulnamen (oder - geschenkt - Codereferenzen). %INC dient dazu,
> erfolgte Ladevorgänge zu protokollieren, um diese nicht unnötig zu
> wiederholen. Welche Packages existieren, ergibt sich
> aus der Hierarchie der Stashes, nicht aus %INC.

Die Hooks liegen in @INC, nicht in %INC. %INC enthält auch keine
Modulnamen sondern die Dateinamen, über die die Module geladen werden.
Welche Packages existieren mag man aus dem Stash ablesen können, 'use'
schert sich aber nicht darum, und darum geht es. Wenn ich garantieren
möchte, dass use Foo::Bar qw(baz); funktioniert, was _ich_ eben als
guten Stil betrachte, muss man eben %INC auch setzen. Du kannst es ja auf

'Dynamically created by Foo::Bar'

oder ähnliches setzen.

..phaylon

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

On 2007-05-01 16:33, Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>> Robert 'phaylon' Sedlacek wrote:
>>>Aussage A) "use Foo" zu schreiben, wenn es Foo.pm nicht gibt, ist IMO
>>>ein Programmierfehler.
>>>
>>>Aussage B) Zwischen Packages und Dateien gibt es in Perl keine
>>>vorgegebene Beziehung.
>>
>>
>> Und wo ist der Widerspruch?
>
> Offensichtlich besteht doch eine vorgegebene Beziehung. Und zwar dass
> 'use Foo::Bar' nach 'Foo/Bar.pm' sucht.

Ja. Aber in dem Satz kommt nirgends ein Package vor. Es gibt eine
Beziehung zwischen "use Foo::Bar" und "Foo/Bar.pm", aber keine zwischen
einem von beidem und einem Package Foo::Bar.

"use Foo::Bar" versucht die Datei "Foo/Bar.pm" zu laden und ruft
anschließend Foo::Bar::import auf, sofern dieses existiert.

Ein erfolgreiches "use Foo::Bar" impliziert nicht, dass danach ein
Package Foo::Bar existiert. Das ist nur Konvention.

hp


--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Robert 'phaylon' Sedlacek wrote:
> Frank Seitz wrote:
>>
>><46237b72$0$23131$9b4e6d93@newsspool1.arcor-online.net>
>
> Ich suche mir das später nochmal raus.

Das hättest Du Dir als erstes raussuchen sollen.
Denn in diesem Code (von Dir) steht der Kokolores,
über den wir hier diskutieren.

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: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Peter J. Holzer:

> Ein erfolgreiches "use Foo::Bar" impliziert nicht, dass danach ein
> Package Foo::Bar existiert. Das ist nur Konvention.

Ja, ich vermute, dass das Package (dh., der Stash) erst durch die
"package" Direktive beim Kompilieren eingerichtet wird. Fehlt
diese, gibt es das Package auch nicht. Natürlich kann man das
Einrichten des Packages auch durch direktes Ansprechen einer
entsprechend benannten Variable (zB. "$Foo::Bar::hello") erzwingen.

Und je nachdem, wieviele "package" Direktiven in der eingebundenen
Datei vorkommen, können trotz nur einem "use" etliche Packages
eingerichtet werden. Theoretisch müsste man aus dem Typeglob
des jeweiligen Stashes erkennen können, in welcher Datei & Zeile
der Typeglob (und somit der Stash/das Package) eingerichtet wurde.
Ich nehme an, dass z.B. B::Xref seine Weisheiten daraus bezieht.

LG, Ferry

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

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Peter J. Holzer wrote:
> Ja. Aber in dem Satz kommt nirgends ein Package vor. Es gibt eine
> Beziehung zwischen "use Foo::Bar" und "Foo/Bar.pm", aber keine zwischen
> einem von beidem und einem Package Foo::Bar.
>
> "use Foo::Bar" versucht die Datei "Foo/Bar.pm" zu laden und ruft
> anschließend Foo::Bar::import auf, sofern dieses existiert.
>
> Ein erfolgreiches "use Foo::Bar" impliziert nicht, dass danach ein
> Package Foo::Bar existiert. Das ist nur Konvention.

Stimmt. Und eben eine sinnvolle IMO. Ich meinte natürlich die soziale Ebene.

..phaylon

Re: Warum Geschweifte um Klassendefinition von Inside-Out-Objekten?

Frank Seitz wrote:
> Das hättest Du Dir als erstes raussuchen sollen.
> Denn in diesem Code (von Dir) steht der Kokolores,
> über den wir hier diskutieren.

Nun mal sachte. Ich sehe in dem Beispiel nichtmal Relevanz. Natürlich
ist nichts ladbares da, das package wurde ja schon definiert. Das sollte
man dem Rest des Programmes eventuell mitteilen. Ausnahmen bestätigen
natürlich die Regel.

..phaylon