On Wed, 2003-11-12 at 07:09, Kazimir wrote:
> I used Image procedure recently; there are at least two similar
> procedures in IPL, ximage and fullimage, beside built-in image.
> Furthermore, I can imagine few new procedures with similar
> functionality. Lack of the naming system in IPL is (1) minor aesthetical
> problem, but also (2) possible name collisions require checking, in
> users programs, and if potential new additions to the library. Finally
> (3) contributors to IPL naturally tend to take most attractive names,
> making less space for users and other contributions.
>
> Problem originates from illusion that one procedure can be solution for
> all times, hence most attractive name can be safely taken. It is better
> to suppose that newer (not necessarily better, just different) versions
> will be written indefinitely. That problem can be solved only by naming
> conventions (same problem exist for class/object/module names.) Inspired
> by human reference systems (there is no only one book named "physics"
> trademarked by Aristotle) I propose similar naming convention. For
> example, instead of mentioned Image, ximage, fullimage,
> even_fuller_image it could be used:
>
> RG95_image
> BP98_image
> KW99_image
>
> Prefix is initial of author and year; or something like that; Those
> names are more complicated (if one uses particular function a lot, he
> can always $define image for himself) but drawbacks are outweighed by
> benefits: (1) there is a system, (2) name collisions are impossible (3)
> attractive names (without prefix) are left for users; (4) it is easier
> to combine procedures from different files (one might want
> WP78_linear_fit, but prefer MM88_exponential_fit over
> WP78_exponential_fit); Furthermore, (5) extension are encouraged
> because there is no backward compatibility or name collisions issues, so
> even very small variations can easily find their place.
Would it be equally acceptable to encourage people to move such
libraries into packages? Packages were added to Unicon to help
address this very issue.
--
Steve Wampler -- [EMAIL PROTECTED]
Quantum materiae materietur marmota monax si marmota
monax materiam possit materiari?
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
