Calocybe: Probleme mit Zeitzonen

Beitrag lesen

Hi again!

der Benutzer kann ja auch die (bald erscheinende ;) Anleitung lesen *g*

Muesste es nicht "Anleitung[tm]" heissen? ;-)

(genau wie er die von World::Redefine lesen sollte...)
ich habs gern kurz und buendig. Wenn ich dem Programm sage, ich moechte die deutsche Zeit benutzen, moechte ich einfach sagen:

»»

use Time::German; # und fertig.

Kann ich ja verstehen, aber s.u. *g*

[...] weitere Moeglichkeiten dazufuegst und dann ploetzlich eine Funktion des Hauptprogramms ueberschrieben wird, weil der Benutzer gezwungenermassen den Inhalt von @EXPORT zulassen musste?

»»

muessen muss er gar nix (s.o.). Fuer sowas (also Viel-Funktions-Export) biete ich dann meistens gruppierende EXPORT_TAGS an, bzw. beschraenke mich dann auch auf eine EXPORT_OK-Liste.

Was ich meinte war, wenn das Mosul so wie jetzt verwendet wird, dann muss man eben doch die Default-Imports zulassen, weil Du ja @EXPORT_OK nicht belegt hast. Es sei dann natuerlich, man schreibt immer Time::German::localtime, aber wollen wir ja auch nicht. Wenn Du nun in beliebig naher oder ferner Zukunft nun vielleicht auch eine Funktion timelocal hinzufuegst, die man ja auch aus dem Standardmodul Time::Local beziehen kann, dann wird die dann ploetzlich auch mit importiert, wenn man auf die neue Modulversion updatet. Und dann gibt's echten Matsch. (Zugegeben, es waere wohl kaum sinnvoll, localtime von Deinem Modul zusammen mit dem timelocal von Time::Local zu verwenden, aber das ist ja nur ein Beispiel.)

So long