Talk:ProposalLibraryDependencies
--Paulb 21:23, 14 November 2006 (CET)
I don't know if the Examples are going to turn into anything concrete. I don't like a useless "com." prefix. "eiffel." is useless also because it's an Eiffel library. I'm assuming you meant "eiffelsoftware."
My suggestions for naming conventions should be:
<company>.<type>.<name>
- For EiffelBase: eiffelsoftware.library.base
- For a utility framework: eiffelsoftware.framework.utilities
- For the Eiffel parser: eiffelsoftware.eiffel.parser
- For the Eiffel compiler: eiffelsoftware.eiffel.compiler
--Patrickr 22:37, 14 November 2006 (CET)
My idea was to use the url of the "company" producing the library to be sure that the name is unique, from most general to more specific. So for base from eiffel.com the idea was com.eiffel.base, gobo could then for example be net.sourceforge.gobo.base (basically the same schema that is used in the java world). I would not put the type into the name, as there are no clear borders between a framework and a library and it's possible that a library can later turn into a framework.
--Paulb 22:55, 14 November 2006 (CET)
I suppose it would make sense to use a URL namespace given that it would be the source, I just don't like it and there is an increasing number of people being turned off Java. Imagine a Gobo Eiffel compiler parser library - net.sourceforge.gobo.eiffel.compiler.parser - That's a little too long for my liking. But it's whatever the majority vote calls for. Whatever we have it better than a path.
It's not a solid argument that a library can turn into a framework. If it does, it's no longer a library and no longer usable in the way someone consuming the library had based their implementation on. By the by, it doesn't matter. It was a distinction about where it came from and what purpose the library served; library meant it came from our library repository, eiffel is related to the Eiffel language, and so on.
My idea was also based on the default namespaces that are assigned to libraries for use with .NET. We already have products out there that use namespaces like EiffelSoftware.Library.Base and EiffelSoftware.Library.Vision2. It's going to be confusing for those .NET users that see a namespace for a library yet the library name is very different. It's too late to change namespaces now because of user that use Eiffel for .NET assemblies from other languages, it would break a lot of code. Basing a namespace system of a language that we don't even support fully and have no user base for might not be the best idea. Using URL is a sound convention but not if it leads to confusion. Eiffel for .NET has been out there for the last six years, why not base it on something established and used. We have a solid source, a company name. It's been working for billions of lines of code so far...
That's my two + two cents.
