mit eval zum vorläufigen ziel

[Beat]

kann ich dir echt nicht sagen...

Ich benutze solche Konstrukte öfters und die Skripte erzeugen keine Warnungen oder Fehler.

Möglicherweise geschah jener 'unknown error' weil die require Routine gleich zweimal ausgeführt wurde.

Habe mein Konzept geändert bis Lektüre und Können zusammenfallen.
Ist schliesslich mein erstes wirkliches Modul.

Mir scheint dein Konzept nicht optimal zu sein. our verwende ich selten, aber mir ist nicht so ganz klar was du vor hast.

Mal sehen, ob sich das bewährt. Die Bausteine zum hauptmodul sind ja keine vollen Module sondern nur Sammlungen von Datenhashes die auch anonyme subs enthalten.

Ich muss noch überlegen ob das eine gute Lösung ist.
Letztlich will ich ja den Inhalt von %ex in Object Hashes kopieren.
Ich muss nicht mit den eingebundenen Funktionen in ihren ursprünglichen Files/packages arbeiten.

Das muss ja kein Nachteil sein, ich finde z.b. ganz praktisch das bei use automatisch die import Funktion aufgerufen wird.

Also ich erzähl mal.

Ich habe einen Parser im Sinn der Sprache nach der Syntax [p:c] verarbeitet.
Der kern des ganzen (für Perl) ist ein parser mit ein paar notwendigen grundfunktionen.
Während der Parser nur die Objectmethoden $obj->new()$obj->parse() und $obj->(init) zulässt (Der Initalisierungscode ist selbst in [p:c]), sollen Mdoule mit weiteren [p:c] Funktionen geladen werden können.
Hier soll es zwei Arten von [p:c] Mdule geben. Reine Textdateien die [p:c] Code enthalten und eben Perlmodule.

Nun möchte ich also, dass man Perlmodule schreiben kann und diese dann via obj->init() durch eine [p:c] Syntax einbinden kann. Das heisst, ich kann diese Module erst während der Laufzeit einbinden.

Nun möchte ich die API für diese Module möglichst einfach halten.
In dieser API gibt es eine Methode $PC->() um an verschiedene Daten zu gelangen, die vom Kern bereitgestellt werden.

Nur das problem: $PC existiert im Coremodul. Es nützt mir nichts, ein solches zu deklarieren in den Modulen.

Hier ein beispiel einer Funktion, wie sie in einem Modul geschrieben sein könnte.

  
our %ex = (  
  
    #   Hier wird eine Funktione für [title:] deklariert  
    #   Es gibt die funktion und defaultwerte.  
  
   title => {  
      function => sub {  
          ${$_[0]} = '<h2';  
          $PC->('children', 'class') and ${$_[0]} .= ' class="' . $PC->('children', 'class') . '"';  
          ${$_[0]} .= '>'. parser( $PC->('children', 'c') ) .'</h2>';  
      },  
  
      default => { element => 'h2', class => 'title', },  
  
   },  
  
);  

Die obige Funktion läuft, wenn ich sie in analoger Stelle im Hauptmodul schreibe den anderen Corefunktionen notiere.
Sie bastelt
aus [title:Beispiel] ein <h2>Beispiel</h2>
aus [title+[class=spezial][c:Beispiel]] ein <h2 class="spezial">Beispiel</h2>
wobei der content "Beispiel" nochmals durch den Parser gejagd wird.

Das ist mein Vorhaben.
Mit dem Hauptmodul komme ich gut zurecht, aber mit dem Erweiterungen, das sehe ich, kann das so nicht gehen.

Update
______________
Jetzt red ich so daher, korrigiere einen Fehler, und es funzt ganz funzig....
Sowas aber auch.

Jetzt muss ich testen.....
Morgen gibts Bericht und eventuell auch eine Gesamtdarstellung zum Modulstand.

Ich brauche nämlich Kritik über das ganze Konzept.
Aber wehe... da ist viel Lektüre für die Kritiker.

mfg Beat