Difference between revisions of "Talk:ProposalLibraryDependencies"

Latest revision as of 22:32, 29 January 2007

--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.

--manus 07:41, 16 November 2006 (CET) The good thing with URL is that they cannot be 2 entities using the same url, however you can have 2 companies called EiffelSoftware. Using the url we would be safer. Note that the url is just used in libraries, it is not like in java where it appears in the source code.

--Paulb 17:21, 16 November 2006 (CET) My concern was for EiffelEnvision users that use libraries but I guess this really doesn't matter because Eiffel for .NET doesn't use namespaces and C#, ..., users don't use Eiffel libraries.

--Greg C 11:17 PM 29 January 2007(PST) Does it make sense to allow two versions of the same library to be accessed from one application? For example, I don't think it would be sensible or possible for an app to use two versions of Vision2 at the same time. If libraries are assumed to always be exclusive, then does this simplify the problem?

How large is the user base for Eiffel .Net? If a breaking change would have a long-term advantage for all Eiffel users, then perhaps the Eiffel .Net users would be willing to suffer through the change for the greater good. In fact, Eiffel .Net users might welcome a significant change, or for direct support of namespaces within the language, since it seems there's a lot of confusion and frustration with the way things sort-of-work now, with prefixes that come and go that may or may not be meaningful, etc.