---

Ich hätte mal eine Frage, wie es die Profis lösen mit Subroutinen zu hantieren.
In meinem Fall, starten 2 Programme, die die gleiche Unterfunktion hernehmen, ABER mit unterschiedlich vielen Argumenten bestückt werden. D.h. im eigentlichen Sinn es sind zwei unterschiedlich Routinen mit dem gleichen Namen.
Klar ist, wenn die 2 Programme geladen werden, die Subroutines mit der letzt geladenen überschrieben werden.

Einfach wäre, die Subroutine umzunennen, gibt es noch einen anderen Weg ausser jetzt mal mit lambda?

------------------
Gruss Dirk

http://cadplayerlounge.blogspot.se

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

...überladen geht in Lisp nicht.

Ich hab mir angewöhnt, die Funktionen lokal zu definieren ... z.B. so

(defun C:MACHWAS(/ SUB1 VAR)
  (defun SUB1( VAR1 )
      (princ VAR1)
  )
  (setq VAR "BLA")
  (SUB1 VAR)
  (princ)
)
 

damit umgehe ich solche Namenskonflikte ... bei Eigennutzung von Programmen und Routinen mag man mit Namen ja noch hinkommen, aber wenn man Sachen rausgibt, weiß man nie, was andere noch alles am Laufen haben ....

------------------
Also ich finde Unities gut ... und andere sicher auch
---------------------------------------
  - Thomas -          
"Bei 99% aller Probleme ist die umfassende Beschreibung des Problems bereits mehr als die Hälfte der Lösung desselben."

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Danke Thomas, einfach und simpel, warum bin ich nicht selbst drauf gekommen!
10 points

------------------
Gruss Dirk

http://cadplayerlounge.blogspot.se

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,
das Problem besteht bei mir auch immer mal wieder, wenn ich Funktionen um Argumente erweitern muss, aber gleichzeitig sicherstellen muß, das diese Funktionen dann auch mit den Aufrufen aus alten Programmen noch funktionieren.

Ein Argument wird dann einfach als Liste zusammengefasst und in der Funktion wird das Argument mit der Funktion TYPE geprüft. Wenn es eine Liste ist, dann kann die Liste auseinandergenommen werden, wenn nicht, dann werden z.B. fehlende Argumente einfach gesetzt.

Beispiel:

Code:

---

;;;alte Funktion ohne Flag
;;;(defun Message (MSG / )
;;;  (alert MSG)
;;;  )

;;;aktualisierte Funktion mit Flag
(defun Message (MSG / Flag)
  ;;;abfragen welcher Typ die Variable ist
  (if (=(type MSG)'STR)
    (setq Flag 'T)
    (setq Flag (cadr MSG)
          MSG (car MSG)))
  (if Flag
    (alert MSG)
    (alert "heute keine Meldung"))
  )

(defun c:AlterAufruf ( / )
  (Message "Schreib was")
  )

(defun c:NeuerAufruf ( / )
  (Message (list "Schreib was" 'T))
  )
 

---

In dem Beispiel wurde ursprünglich ein String übergeben. Dann erfolgte eine Änderung die ein zusätzliches Flag erforderlich gemacht hat. Wenn jetzt ein "alter" Funktionsaufruf nur mit dem String stattfindet, dann wird das Flag automatisch gesetzt, wenn ein "neuer" Funktionsaufruf stattfindet, dann wird das Flag in der Liste übergeben. Vom Prinzip entspricht das einer überladenen Funktion, wenn auch ziemlich mit der Holzhammermethode und ein wenig unelegant, aber es funzt.

------------------
viele Grüße

Jörn
http://www.bosse-engineering.com

Kordinaten einlesen Youtube

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von CADmium:
...überladen geht in Lisp nicht.

Ich hab mir angewöhnt, die Funktionen lokal zu definieren ... z.B. so

(defun C:MACHWAS(/ SUB1 VAR)
   (defun SUB1( VAR1 )
       (princ VAR1)
   )
   (setq VAR "BLA")
   (SUB1 VAR)
   (princ)
)
  

damit umgehe ich solche Namenskonflikte ...

---

Naja, der Sinn von benannten Funktionen ist ja gerade der, dass man sie nur einmal definiert und dann beliebig oft verwendet. Wenn man's nur einmal braucht, dann tut's auch eine anonyme Funktion. Wenn man sowas wie da oben öfter macht, dann kann man so ein Programm später praktisch gar nicht mehr pflegen ...

Dass ich es für den zweitgrößten Nachteil von VisualLisp halte, dass man Funktionen nicht überladen kann, hab' ich ja schon öfter gesagt (der größte Nachteil ist, dass man keine Makros programmieren kann). Irgendwo hab' ich doch auch mal ein bißchen Code gezeigt, wie man das Überladen ansatzweise nachbilden kann. Es wäre für Autodesk ein Klacks, Makros und Überladen einzubauen. Die wollen halt nicht.

Ab einer gewissen Komplexität der Applikation ist es sinnvoll, solche Lisp-Funktionen in C# zu programmieren. Und dabei kann man natürlich auch die schon eingebauten Funktionen umdefinieren. Beispielsweise addiert bei mir die +-Funktion nicht nur Zahlen, sondern auch Koordinatenpunkte. Sowas kann man in VisualLisp alleine leider nicht umdefinieren, weil man da keine Funktionen mit beliebig vielen Argumenten definieren kann.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von archtools:
... Ab einer gewissen Komplexität der Applikation ist es sinnvoll, solche Lisp-Funktionen in C# zu programmieren. Und dabei kann man natürlich auch die schon eingebauten Funktionen umdefinieren. Beispielsweise addiert bei mir die +-Funktion nicht nur Zahlen, sondern auch Koordinatenpunkte. Sowas kann man in VisualLisp alleine leider nicht umdefinieren, weil man da keine Funktionen mit beliebig vielen Argumenten definieren kann.

---

jupp, ich liebe es. Für die eigene Verwendung bzw für meine Kunden, die Funktionen mit verschiedenen Eingangsparametern benötigen, greife ich sehr gern auf die Definition Lisp-Funktionen in C# zurück und bin so sehr froh, dass die Funktionen überladen werden können. Das Überladen findet, intern betrachtet  dann tatsächlich so statt, wie es Jörn beschrieben hat. die Parameter kommen als Liste mit unterschiedlicher Elementanzahl an.

Grüße!
Holger

------------------
Holger Brischke
Freier C#.NET-Workshop Ende Oktober geplant. Bei Interesse bitte melden!
CAD on demand GmbH
Individuelle Lösungen von Heute auf Morgen.

defun-tools Das Download-Portal für AutoCAD-Zusatzprogramme!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Brischke:

jupp, ich liebe es. Für die eigene Verwendung bzw für meine Kunden, die Funktionen mit verschiedenen Eingangsparametern benötigen, greife ich sehr gern auf die Definition Lisp-Funktionen in C# zurück und bin so sehr froh, dass die Funktionen überladen werden können. Das Überladen findet, intern betrachtet  dann tatsächlich so statt, wie es Jörn beschrieben hat. die Parameter kommen als Liste mit unterschiedlicher Elementanzahl an.

Grüße!
Holger

---

Eine Funktion, die verschieden oder gar beliebig viele Parameter zulässt (die dann in der aufgerufenen Funktion als Parameterliste abgreifbar sind), ist keine überladene Funktion. Das ist nur der Fall, wenn man tatsächlich verschiedene Funktionen mit gleichem Namen, aber mit unterschiedlicher Parameterzahl definiert. Das macht man in der Regel natürlich nicht, wenn da, beispielsweise bei der + Funktion, immer dasselbe passiert. Überladene Funktionen zeichnen sich in der Regel dadurch aus, dass sie tatsächlich auch unterschiedliche Funktionalität haben.

In einem "richtigen" Lisp-System kann man Makros definieren. Beispiele für Makros wären etwa die SETQ und die DEFUN Funktion. Das ist eigentlich ziemlich simpel: in einem Makro legt man hauptsächlich fest, welche Parameter wann evaluiert werden. Man kann sowas wie SETQ in VisualLisp nicht programmieren, weil beim Aufruf der erste Parameter nicht, der zweite aber schon evaluiert werden soll.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP