Protecting Function Names

When loading multiple .LSP (or .VLX) files within the ACAD.LSP file, there is the potential for the functions inside the various .LSP (or .VLX) files to "overwrite" each other. When a program is run that has the same function name [Example: "defun Get_Tiles ()"] as another .lsp file that was loaded, I've observed that the last file loaded with the same function name is used. For obvious reasons, this is not good.

I figured compiling the .LSP files to .VLX in a separate namespace would solve this conflict. However, most of my routines utilize DosLib2005.arx and programs in their separate namespace do not appear to work with externalized commands like the ones I'm referencing in external .arx files. As far as I know, there is no way to compiled the .arx file with the .vlx.

Does anyone have a reasonable solution to this problem of function names stomping over each other - without having to rename these functions to *unique* names that won't conflict?

Thanks for any info!

David Lister
Mikron Industries

 

Jason, (for the benifit of the OP) I'm assuming you mean with respect to
importing Doslib functions into a seperate namespace VLX?

David,

All 1,085 of my Defined Functions (defun) have unique names. I wouldn't
know what to do otherwise.

jb

 

Yep, that is what I was referring to. Sorry if that
wasn't clear.

FWIW, recently I've been getting into the habit of
using the separate namespace vlx for some of the
small applications we use here just to avoid some
of the function name collisions.

Now, all my toolbox function are named uniquely
so there isn't a problem there but I often find it to
be much easier to use the same application-specific
function name from one to the next

(defun getNames ().........)

instead of

(defun mySpecialApplicationPrefix-getNames ().........)

I figure if each application is wrapped up into it's
own namespace, who cares?

 

if you have sub-functions used by that main program only, localize the sub
function


(defun c:MAINPROGRAM (/ SUBFUN1)
(defun SUBFUN1 ()
(do something)
)
(main program code)
)

this will keep them from stepping on each other. also this loads the
sub-function each time it runs. a little overkill i suppose, but unless your
programs are HUGE, you won't notice a difference in speed.

another way if you don't want to do the above, add a prefix to the sub
function names.
(defun MP1-SUBFUN1 ()
(do something)
)
(defun c:MP1 ()
(main program code (MP1-SUBFUN) )
)

the sub functions will always have a unique name.

hth
daron

is the potential for the functions inside the various .LSP (or .VLX) files
to "overwrite" each other. When a program is run that has the same function
name [Example: "defun Get_Tiles ()"] as another .lsp file that was loaded,
I've observed that the last file loaded with the same function name is used.
For obvious reasons, this is not good.

 

I like the sub-function method in that it is rather elegant. Unfortunately, I admit that I'm not very disciplined with localizing variables, let alone sub-functions.

Like James, I'm dealing with thousands of sub functions and it would take quite a bit of time to prefix them all, not to mention future projects.

I also like using the same common function names as Jason was suggesting. In many instances, I'm directly pasting functions from one program to another with no changes because the function works well.

What I've done in the past is actual *load* the function within the function. Example:

(defun clotMe ()
(load "PlotMe")
[Insert Code Here]
(princ)
)

This assures me that the functions in my program were the last ones loaded and will be the correct ones used as the program runs... ...but it is kinda cheesy.

Jason, I tried the vl-arx-import function with doslib2005.arx and it worked great when compiling my function in a separate namespace. I just put the following line at the top of the program:

(vl-arx-import "doslib2005.arx")

The function allows you to load individual functions inside the .arx file in question, or you can just load the whole library of functions inside the .arx file as I did in the command above.

Thanks for the suggestion!

David Lister
Mikron Industries

 

to add to this a bit, i like to have three types of sub functions for our
system
1) localized (used by that function only)
2) used a functions not frequently used
3) used by functions used almost every edit session


2) in this case, i would load as you do. but this is rare.


3) in this case, i have an additional support .vlx loaded automatically
which has many sub functions in it. i know functions are going to need it,
so just load it. it's over 100k, and you can't feel it load. this is also
nice for updating - tweak something in one place... done.

my $0.02 )
daron

 

errr...

used BY functions... <)

 

Thanks for the tip, I learned something today.

Gary

 

Just so it is clear, I wasn't suggesting cutting/pasting the
same function from one application to the next. Any
function that is generic enough to be used by multiple
applications is placed in my 'toolbox'.

I have all my toolbox functions (which is one function
per file, stored in a specific directory structure to help
identify that functions purpose/category) compiled into
their own .vlx which loads on startup. When writing a
new application I just call any toolbox function that is
required without having to worry about it being loaded
during development.

When it comes time to compile the new application, I
add any toolbox functions to the new .vlx application
properties (given the fact that my toolbox is organized
on a one function per file basis there are no un-needed
functions compiled with each application).

This method Works really slick for me, no complaints at all.


PS: Glad the vl-arx-import was what you were looking for.