Topic: STDLib

[LE]

It’s a good point Luis,
I disliked the idea “having” to use a third party utility such as Owens VCBuildHook. That was until I understood that it was only invoking an already needed compiler to make the build and was in no way stopping me from building the old fashion way. Granted it took learning how to use it. But now I think it’s a must have tool for doing ARX.

Other than that, I am not even close to being qualified to critique Owens code.
Dan

It was just an example....

I never had try Owen utility and I am sure must be very good and it will be available for a long time.

In my case, I only write routines for my own use, and it is very simple to write everything using the VS2005 and being able to use the same files and code, in VS2002, not a big deal.


Going back, to an standard library..... it is a good idea, the std one as you can see, it is not too popular per see.....


PS. and no I am in no way qualified at all to critique master Owen's work.

[TimSpangler]

I am sure that most of the coders here have a STDLib of there own.  I do, but until recently they have all been in text format and when I need something I copy/paste into my program, (mainly to avoid the dependency issues)  A few months ago I started taking those text files and turning them into STD procedures not dependent on other procedures.

I had thought about bringing this up to the group, maybe a swamp library??

All my functions are called with my developers sig-  (defun TGS:CreateLayer for example)

Maybe a folder for the individual files but also a .fas with all of the files? (well documented of course)

Just a thought...Anyone

[Keith™]

I have no issues with something being dependent upon another routine in a library ... but after a while, when a library becomes so interdependent upon other files, you are left with an all or none proposition ... and to top it off, when the code for one routine is updated (as has been done in the past) you either have to change the calling function to work with the new version, or you have to ensure the user has the old version of the library.

[Kerry]

From my perspective,
Updating files in a library should never be an issue for concern. It all comes down to your design philosophy. If the coder is disciplined, (and who among us isn't), changing the code in a library should have no repercussions provided the basic rules are followed ... Don't change a method signature and don't change any side affects ; if either of these NEED to be changed then the function gets a new name, and documented accordingly.

[Keith™]

I concur with that assessment .. unfortunately, many coders lack that ability ... and I do not mean Reini .. I have found him to be a very capable codesmith

[MP]

From my perspective,
Updating files in a library should never be an issue for concern. It all comes down to your design philosophy. If the coder is disciplined, (and who among us isn't), changing the code in a library should have no repercussions provided the basic rules are followed ...

Well said.

Don't change a method signature and don't change any side affects ; if either of these NEED to be changed then the function gets a new name, and documented accordingly.

... and leave the existing function in place. If invoked prints out a "Note: Function Deprecated, See replacement function: XXX" type notification.

[It's Alive!]

... and leave the existing function in place. If invoked prints out a "Note: Function Deprecated, See replacement function: XXX" type notification.

Interesting, I know that a compiler’s pre-processor generally gives out these types of warnings.
But would not a warning upon invocation of a depreciated method break code in lisp?

[Kerry]

... and leave the existing function in place. If invoked prints out a "Note: Function Deprecated, See replacement function: XXX" type notification.

Interesting, I know that a compiler’s pre-processor generally gives out these types of warnings.
But would not a warning upon invocation of a depreciated method break code in lisp?

The message could be added as a simple prompt to the command-line without affecting the functional integrity of the routine ..

[MP]

Code: [Select]

(defun _Foo ( arg1 )

    (princ
        (strcat
            "Note: _Foo function is deprecated, see "
            "replacement function _FooNew.\n"
        )   
    )

    ;;  All the former stuff _Foo did it still does, after
    ;;  printing out the prompt above ...   
   
)

Code: [Select]

(defun _FooNew ( arg1 arg2 )

    ;;  New signature, new definition ...

)
If _Foo is invoked it still works, but it prints out the deprecated message, which refers to _FooNew.

Clear as mud?

[It's Alive!]

Hmm, I think that it would force a rebuild of all prior “working” applications upon deployment of a new library.
Call me a snot but., I don’t want my users seeing these messages.

[Kerry]

Ahhhhh ... there are 2 issues here primarily concerned with definition of terms.

By 'Library'

do we mean

a) A collection of functions I maintain for my own use

or b) A collection of functions released to the public for inclusion/reference in the work of others.

[MP]

Hmm, I think that it would force a rebuild of all prior “working” applications upon deployment of a new library.

Exactly.

Call me a snot but., I don’t want my users seeing these messages.

What's the alternative?

It might be important to note that if you are the only one using your library than you needn't use this strategy if you update all reliant code if / when you change a function's signature.

However, if you're the author of a library like StdLib that is utilized by multiple developers, you have an obligation to inform them of changes to the library. Aside from headers etc. how would you ensure consumers of a LISP library be advised of deprecated functions etc?

[It's Alive!]

or b) A collection of functions released to the public for inclusion/reference in the work of others.

B

What's the alternative?

A new function name as Kerry suggested.

[MP]

A new function name as Kerry suggested.

I guess we agree on that, because I subscribe to the same strategy.

Where we disagree is that I believe consumers of said library should be notified when they invoke antiquated / deprecated functions.

But hey, we are entitled to our opinions / styles. Thank goodness for that.

[It's Alive!]

... I believe consumers of said library should be notified when they invoke antiquated / deprecated functions.

Just think if Microsoft did this, what would you see?