Portée d'une fonction

[ascoge]

Bonjour,

 

Piochant régulièrement dans ce forum, la moindre des choses est d'abord d'en remercier tous ses acteurs.

Grâce à vous j'ai pu assez rapidement pondre quelques Lisp bien utiles. Débutant averti,je constate que le cheminement de mes questions passe toujours par ici.

 

Voilà mon problème:

Je charge 2 Lisp différents dans un même dessin, chacun possède une sous-fonction avec un nom identique "Dialog1_verification". Parfois l'un d'eux plante avec un "stringp nil", on dirait qu'il y a une interférence entre ces 2 sous-routines puisque je vois apparaitre une alert qui appartient à l'autre Lisp.

C'est comme si mes deux Lisp étaient mis bout à bout et que je me retrouve avec deux sous-fonctions ayant le même nom.

 

Structure du Lisp A (le B est pareil) :

 

(defun c:LispA (/)

...

...appel de Dialog1_verification ...

)

...

(defun Dialog1_verification (/)

...blabla...

)

 

Ma solution a été de renommer les "Dialog1_verification" différemment. Peut-être que je pourrais aussi les déclarer comme variable local..

 

Mon interprétation du problème vous paraît-elle possible? Peut-on considérer une fonction comme une variable globale au dessin ET à tous ses Lisp chargés?

 

Tous ça est un peu flou pour moi.

 

Merci d'avance.

[bryce]

Bonjour,

 

Ce n'est pas si flou, puisque tu as bien compris ce qui se passe ! ;)

 

Si tu charge dans le même dessin un 1er fichier qui contient

(defun c:LispA (/)
 ...
)

(defun Dialog1_verification (/)
 ...
) 

puis un 2nd fichier qui contient

(defun c:LispB (/)
 ...
)

(defun Dialog1_verification (/)
 ...
) 

alors la fonction Dialog1_verification chargée avec le 2nd fichier va forcément écraser et remplacer la 1ère.

 

Tu peux donc effectivement soit les nommer différemment, soit les déclarer en fonctions locales:

(defun c:LispA (/ Dialog1_verification )
 (defun Dialog1_verification (/)
   ...
 )
 ...
)

(defun c:LispB (/ Dialog1_verification )
 (defun Dialog1_verification (/)
   ...
 )
 ...
)

[ascoge]

OK, ç'est beaucoup plus clair maintenant. Merci.

[(gile)]

Salut,

 

Voir ce sujet (particulièrement la réponse #12)

 

En LISP (comme dans la plupart des langages dits fonctionnels) les fonctions sont des valeurs de première classe, ce qui veut dire qu'il faut considérer une fonction comme tout autre type de variable.

 

Pour preuve, on peut définir une fonction avec setq comme avec defun :

 

(setq sqr (lambda (x) (* x x)))

est équivalent à

(defun sqr (x) (* x x))

[ascoge]

Ouhla! c'est tu post de haute volée où tu me renvoie là. Mais bon à chaque relecture j'en comprend un peu plus. La réponse #8 sur *error* m'a beaucoup intéressé, j'ai donc tout intérêt à toujours déclaré *error* comme variable locale quand je la redéfinie. En gros mon application devrait ressembler à ça:

 

(defun c:AssRegard (/ *error* Sortie ... )

   (defun Sortie ()       ; sortie normale
     (ai_sysvar nil)      ; rétablissement des valeurs d'origine
     (princ)
   )
   (defun *error* ( msg)       ; si abandon au cours de l'application, on efface les entités en cours et appelle de (Sortie)
     (if (ssname ssCana 0)     ; ssCana est un jeu de séléction des entités en cours de création
  (command "effacer" ssCana "")
     )
     (princ (strcat "\n*Abandon* " msg))
     (Sortie)
   )
   (ai_sysvar '(("OSMODE" . 0)
                ...
               )
   ) 

   ... corps du programme ...

   (Sortie)
)

 

 

La structure vous paraît-elle bonne?

Est-ce que l'emplacement de la définition de Sortie et de *error* par rapport au corps du programme (avant ou après) a une importance?

[(gile)]

Salut,

 

La structure est bonne.

On peut améliorer en fusionnant Sortie et *error*

 

(defun c:AssRegard (/ *error* ... )

   (defun *error* ( msg) 
     (if msg ; s'il y a une erreur, il y a forcément un message 
       (progn  
         (if (ssname ssCana 0)
           (command "effacer" ssCana "")
         )
         (princ (strcat "\n*Abandon* " msg))
       )
     )
     (ai_sysvar nil)
     (princ)
   )

   (ai_sysvar '(("OSMODE" . 0)
                ...
               )
   ) 

   ... corps du programme ...

   (*error* nil) ; on appelle *error* sans message
)

[ascoge]

Simple et efficace, c'est adopté. Merci.