Difference between revisions of "Talk:ProposalLibraryDependencies"

Line 15: Line 15:
  
 
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).
 
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.

Revision as of 12:39, 14 November 2006

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