Talk:Library Categorization

Revision as of 23:51, 18 August 2009 by Ericb (Talk | contribs)

Instead of gui_design, gui_graph, ... I would prefer

  • gui
    • design
    • graph
    • ..

argument_parser would be better as

  • parse
    • argument

About Gobo, it could be exploded into kernel, structure, time, parse, lexical, xml, ... But we can not do that, so what about adding a category "Package", or "Framework"

--Jocelyn 08:12, 13 August 2009 (UTC)

I would suggest the following 2-layer structure (if there is a new name, the old one is written in parentheses, in particular, something_extension is not very meaningful):

  • base: Kernel library classes, data structure, reflection, I/O
  • concurrency
    • process: Facility to start and follow processes
    • thread: Threading in Eiffel
    • cgi (web): CGI facility for Eiffel
  • external: interface to the external software
    •  ? (api_wrapper): Make it easy to call C routines from dynamically loaded shared libraries
    • com: COM technology
    • java (Eiffel2Java): Calling Java from Eiffel
  • gobo: Gobo
  • gui
    • docking: Facility to have a customizable UI.
    • event: Low level mechanism to receive a UI event when a file/pipe has something new.
    • graph: Representation of graph in UI (See diagram tool in Eiffel Studio).
    • vision2: Platform independent UI toolkit
    •  ? (vision2_extension): Extension to Vision2
    • wel: UI toolkit for Windows
  • storage
    • memory (memory_analyzer): Memory analysis
    • preferences: Facility to store user preferences
    • store: Relational database access
  • text
    • argument (argument_parser): Parsing the command line arguments of a program
    • diff: Diff and patch facilities
    • encoding: Transforming text in one encoding to another encoding
    • i18n: Internationalization library:
    • lex: lexical analysis
    • parse: Parsing:
    • uuid: UUID generation facility
  • util
    •  ? (gobo_extension): ISE gobo extensions
    • net: Networking library
    • testing: Testing facility
    • time: Time facility

--Alexander Kogtenkov 15:52, 18 August 2009 (UTC)

Instead of how about Interop?

--paulb 23:29, 18 August 2009 (UTC)

To comment Alexander's message: Given the importance of the internet today, it sounds weird to have EiffelNet under "Utils" Let's add a "Network" category ... Then, we could add twitter, jabber, eventually Eiffel Web?

--Jocelyn 05:59, 19 August 2009 (UTC)

"Preferences" under UI/interface looks weird to me. If I were looking for preferences lib, I would search under "data" or "database" or "storage", but not in "ui". However, the pref lib also has Graphical components. In final, ... we should allow more than one category for a lib.

--Jocelyn 06:24, 19 August 2009 (UTC)

Language Interfaces looks too long for me as well. In fact here we are talking more about interfacing to the external software, not to the particular language, as, for example, COM is a technology and not a specific language. Interop is associated for me with .NET... Just a few other possibilities:

  • software
  • call

Also, api_loader sounds too generic. Shall it be library_loader or even library_accessor instead?

Would it make sense to merge data and data_structures into data with subnodes database and adt? If not, it might make sense to rename data into persistency or something like that. Also, does event library belong to ADT? According to the description it's more about GUI and IO, so it could be moved to ui section.

There is some inconsistency in naming as both singular and plural nouns are used. Probably it's better to stick to the same naming convention and use (as in Eiffel) only singular forms (utility instead of utilities, etc.).

--Alexander Kogtenkov 06:59, 19 August 2009 (UTC)

--Ericb 07:51, 19 August 2009 (UTC): For the event library, what about the category pattern?

About singular vs. plural, I'm all for singular names as well. I noticed in the some libraries that there are folders example. That's good. But in some others we can find tests. In order to be consistent, everything should be singular.