Schrift
Wiki:Tipp zum Debugging: use Data::Dumper; local $Data::Dumper::Useqq = 1; print Dumper \@var;
[thread]11549[/thread]

OOP und Klassenvariablen

Tags: Ähnliche Threads

Leser: 2


<< |< 1 2 >| >> 13 Einträge, 2 Seiten
pktm
 2008-03-31 19:24
#107673 #107673
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
Hallo!

Ich habe mir da das eine oder andere Modul geschrieben und da verwende ich so globale Variablen, die ich mittels use vars qw/$VAR/; definiere. Zum Beispiel $DEBUG oder $VERSION.
Wie kann ich die vererben?

Wenn ich nämlich so ein Modul als Superklasse angebe, und dann die Variablen benutzen will gibts einen Fehler.

Eine Lösung wäre, für die Variablen Zugriffsmethoden zu schreiben (meine ich doch zumindest -.-). Geht es auch anders?

Grüße, pktm
http://www.intergastro-service.de (mein erstes CMS :) )
pq
 2008-03-31 19:28
#107674 #107674
User since
2003-08-04
12208 Artikel
Admin1
[Homepage]
user image
zugriffsmethoden wären wohl das beste. und das sauberste.
$VERSION solltest du aber eh über die universelle methode VERSION bekommen können.
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:Wie frage ich & perlintro Wiki:brian's Leitfaden für jedes Perl-Problem
pktm
 2008-03-31 19:40
#107676 #107676
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
pq+2008-03-31 17:28:10--
zugriffsmethoden wären wohl das beste. und das sauberste.
$VERSION solltest du aber eh über die universelle methode VERSION bekommen können.


Huh? Was für eine universelle Methode? [Erzähl mir mehr :)]
http://www.intergastro-service.de (mein erstes CMS :) )
moritz
 2008-03-31 19:51
#107677 #107677
User since
2007-05-11
923 Artikel
HausmeisterIn
[Homepage]
user image
Da steht was in perlobj dazu:

Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
       VERSION( [NEED] )
"VERSION" returns the version number of the class (package). If
the NEED argument is given then it will check that the current ver&#8208;
sion (as defined by the $VERSION variable in the given package) not
less than NEED; it will die if this is not the case. This method
is normally called as a class method. This method is called auto&#8208;
matically by the "VERSION" form of "use".

use A 1.2 qw(some imported subs);
# implies:
A->VERSION(1.2);
KurtZ
 2008-03-31 19:53
#107678 #107678
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
Wenn du sie wie hier als Packetvariablen definierst kannst du doch über den Namenraum darauf zugreifen. (Deswegen mache ich sie meistens auch lexikalisch.)
TMTOWTDYOG (there's more than one way to dig your own grave)
sid burn
 2008-04-01 02:19
#107687 #107687
User since
2006-03-29
1520 Artikel
BenutzerIn

user image
Also wenn du wirklich OOP Programmierst, dann machst du meiner meinung anch etwas falsch wenn du Package Variablen verwendest.

$VERSION ist aber übrigens eine spezielle Variable die du auch als Package Variable definieren solltest.
Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
Strat
 2008-04-01 14:40
#107700 #107700
User since
2003-08-04
5246 Artikel
ModeratorIn
[Homepage] [default_avatar]
Warum willst du $VERSION "vererben"?
perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/
pktm
 2008-04-01 21:17
#107705 #107705
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
$VERSION will ich eigentlich garnicht vererben, sondern $DEBUG.
Habs aber jetzt über eine Methode gemacht:
debug(0) => off
debug(1) => on
$state = debug() => liest den Status aus (0|1).

Allerdings wird die Sache immernoch über eine Paketvariable realisiert. Was wäre besser? Und vor allem warum?

Data::Dumper benutzt solche Variablen z.B. um die Einrückung zu steuern.

Grüße, pktm
http://www.intergastro-service.de (mein erstes CMS :) )
KurtZ
 2008-04-02 06:40
#107723 #107723
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
pktm+2008-04-01 19:17:24--
Allerdings wird die Sache immernoch über eine Paketvariable realisiert. Was wäre besser? Und vor allem warum?


Naja das kommt drauf an, der Scope einer lexikalische Variable kann maximal die Datei sein inder sie steht. Wenn man also verhindern will dass eine Klassenvariable von außen manipuliert wird, steckt man sie in eine lexikalische.

Der Grund könnte sein, dass man den Usern nicht vertraut oder dass es im Entwicklungsprozess später irgendwelche Änderungen an der Variable geben könnte und du müsstest qualvoll alle stellen in allen Dateien raussuchen wo die Variable direkt manipuliert wurde.

Hast du aber getter und setter Methoden für diese Variable , kannst du viel relaxter mit Änderungen umgehen, weil du die Methoden einfach dahingehend erweiterst, dass sie trotz altem Aufruf die Variable auf neue Werte setzen.

Wurden die Variablen lexikalisch definiert, kannst du dir selbst vertrauen, dass du IMMER die Mutatoren benutzt hast, du kannst dich nicht selbst (aus Eile/Faulheit/...) bescheißen.


Beispiel: du hast $DEBUG=0 oder 1 für nein und ja.

Später entscheidest du dich lieber die Zustände "on", "off", "partial" , "devel" und "wasweißich" einzutragen. Statt jetzt alle $MODUL::DEBUG=0 Aufrufe rauszusuchen, änderst du einfach das Verhalten von setDebug() dahingehend bei 0 "off" einzutragen.

Hinkt vielleicht, aber konnte ichs einigermaßen verständlich rüberbringen?

TMTOWTDYOG (there's more than one way to dig your own grave)
pktm
 2008-04-02 16:01
#107737 #107737
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
Hm ja, die Gründe leuchten ein.
Dann wäre es wohl noch ein Stück besser, wenn ich anstatt $DEBUG in der Instanz ein Feld anlege, welches diese Information trägt, also im Konstruktor sowas schreibe wie:
Code: (dl )
1
2
    # init debug state (0 = off, 1 = on), default=off
$self->{'__DEBUG'} = 0;


und dann in der Methode debug() auf dieses Feld zugreife.

Grüße, pktm
http://www.intergastro-service.de (mein erstes CMS :) )
<< |< 1 2 >| >> 13 Einträge, 2 Seiten



View all threads created 2008-03-31 19:24.