Talk:Library Categorization - Revision history

Paulb at 19:16, 27 October 2009

2009-10-27T19:16:48Z

Jfiat at 11:26, 27 October 2009

2009-10-27T11:26:34Z

Jfiat at 11:26, 27 October 2009

2009-10-27T11:26:00Z

Ericb at 07:54, 26 August 2009

2009-08-26T07:54:15Z

Manus at 15:48, 25 August 2009

2009-08-25T15:48:30Z

Ericb at 21:13, 24 August 2009

2009-08-24T21:13:29Z

Alexander Kogtenkov: Suggested replacements for language_interface

2009-08-24T07:54:19Z

Suggested replacements for language_interface

Alexander Kogtenkov: Suggested a replacement for data_structure

2009-08-24T07:39:20Z

Suggested a replacement for data_structure

Manus at 17:09, 22 August 2009

2009-08-22T17:09:38Z

Ericb at 07:19, 21 August 2009

2009-08-21T07:19:58Z

← Older revision		Revision as of 19:16, 27 October 2009
Line 190:		Line 190:

	--[[User:Jfiat\|Jocelyn]] 11:26, 27 October 2009 (UTC)		--[[User:Jfiat\|Jocelyn]] 11:26, 27 October 2009 (UTC)
		+
		+	----
		+	I have to say, I hate the word "execution". We have a habit of using alternative names for things so people coming to Eiffel have no idea where to find things. I would stick with runtime for somethings and add another category.
		+
		+	*runtime
		+	**concurrency
		+	**memory
		+	**reflection
		+
		+	*application
		+	**argument_parser
		+
		+	I don't know where the ''process'' library really belongs. I think we need an '''application''' category for application frameworks. I would be fine with putting ''argument_parser'' under '''parser''' but it might not be found.
		+
		+	Really we need a tag system instead of a tree, which is something integrated into the heart of the library repository idea.
		+
		+	p.s. I like Eric's idea about segregating aspects of a library; source, documentation, examples, and tests. It would be useful to have a dedicated layout for tools and just consistency in general.
		+	--[[User:Paulb\|paulb]] 19:16, 27 October 2009 (UTC)

@@ Line 175: / Line 175: @@
 --[[User:Ericb|Ericb]] 07:54, 26 August 2009 (UTC): My proposal is not about having an automatic package distribution. It's about having everything related to the library (or the tool) located in one single place. When I want to use a library, it is much more practical to see whether there are examples or tests available for this library if they are in directories next to the library's code rather than having to browse through parallel directory hierarchies. I'm sorry, I'm not thinking like the Unix layout way. I'm thinking like I would like it to be as a user.
 It looks weird to have "runtime" as category. I know it means "at run time", but in our Eiffel world, we are used to talk about the "runtime", as the underlying C library.
 What about replacing "runtime" by "execution" ?

← Older revision		Revision as of 11:26, 27 October 2009
Line 174:		Line 174:

	--[[User:Ericb\|Ericb]] 07:54, 26 August 2009 (UTC): My proposal is not about having an automatic package distribution. It's about having everything related to the library (or the tool) located in one single place. When I want to use a library, it is much more practical to see whether there are examples or tests available for this library if they are in directories next to the library's code rather than having to browse through parallel directory hierarchies. I'm sorry, I'm not thinking like the Unix layout way. I'm thinking like I would like it to be as a user.		--[[User:Ericb\|Ericb]] 07:54, 26 August 2009 (UTC): My proposal is not about having an automatic package distribution. It's about having everything related to the library (or the tool) located in one single place. When I want to use a library, it is much more practical to see whether there are examples or tests available for this library if they are in directories next to the library's code rather than having to browse through parallel directory hierarchies. I'm sorry, I'm not thinking like the Unix layout way. I'm thinking like I would like it to be as a user.
		+
		+	It looks weird to have "runtime" as category. I know it means "at run time", but in our Eiffel world, we are used to talk about the "runtime", as the underlying C library.
		+	What about replacing "runtime" by "execution" ?
		+	This way, we would have
		+	*execution
		+	**memory
		+	**process
		+	**reflection
		+	**concurrency
		+	And I am still unconfortable with having "argument parser" under this "runtime/process" (Or even "execution/process"). It might go under "parser". Even if It is more than just a parser, since it also include the source of argument.
		+
		+	Or we could create an "application" category...
		+	any idea?
		+
		+	--[[User:Jfiat\|Jocelyn]] 11:26, 27 October 2009 (UTC)

← Older revision		Revision as of 07:54, 26 August 2009
Line 172:		Line 172:

	'''--[[User:Manus\|manus]] 15:48, 25 August 2009 (UTC)''': I had thought about that but forgot to add `tool' under my proposal. I think this is better this way as an automatic package distribution will know exactly where to put things. I'm definitely thinking like the Unix layout way.		'''--[[User:Manus\|manus]] 15:48, 25 August 2009 (UTC)''': I had thought about that but forgot to add `tool' under my proposal. I think this is better this way as an automatic package distribution will know exactly where to put things. I'm definitely thinking like the Unix layout way.
		+
		+	--[[User:Ericb\|Ericb]] 07:54, 26 August 2009 (UTC): My proposal is not about having an automatic package distribution. It's about having everything related to the library (or the tool) located in one single place. When I want to use a library, it is much more practical to see whether there are examples or tests available for this library if they are in directories next to the library's code rather than having to browse through parallel directory hierarchies. I'm sorry, I'm not thinking like the Unix layout way. I'm thinking like I would like it to be as a user.

← Older revision		Revision as of 15:48, 25 August 2009
Line 169:		Line 169:

	is that this directory structure could be used not only for libraries but also for tools.		is that this directory structure could be used not only for libraries but also for tools.
		+
		+
		+	'''--[[User:Manus\|manus]] 15:48, 25 August 2009 (UTC)''': I had thought about that but forgot to add `tool' under my proposal. I think this is better this way as an automatic package distribution will know exactly where to put things. I'm definitely thinking like the Unix layout way.

← Older revision		Revision as of 21:13, 24 August 2009
Line 148:		Line 148:
	* '''platform''' (most suitable from my point of view)		* '''platform''' (most suitable from my point of view)
	--[[User:Alexander Kogtenkov\|Alexander Kogtenkov]] 07:54, 24 August 2009 (UTC)		--[[User:Alexander Kogtenkov\|Alexander Kogtenkov]] 07:54, 24 August 2009 (UTC)
		+
		+
		+	----
		+
		+	--[[User:Ericb\|Ericb]] 21:13, 24 August 2009 (UTC): The reason why I suggested:
		+
		+	<library_name>/
		+	code (or src, or source)
		+	doc
		+	example
		+	test
		+
		+	and not:
		+
		+	<library_name>/
		+	library
		+	doc
		+	example
		+	test
		+
		+	is that this directory structure could be used not only for libraries but also for tools.

← Older revision		Revision as of 07:54, 24 August 2009
Line 141:		Line 141:
	If '''data_structure''' is replaced by '''concept''', the subnodes could be '''adt''' and '''pattern''' (the latter for the libraries that provide the patterns, e.g. ''event'' could go to this category). Probably, the term '''concept''' is too generic, but otherwise it perfectly matches its subnodes.		If '''data_structure''' is replaced by '''concept''', the subnodes could be '''adt''' and '''pattern''' (the latter for the libraries that provide the patterns, e.g. ''event'' could go to this category). Probably, the term '''concept''' is too generic, but otherwise it perfectly matches its subnodes.

−	--[[User:Alexander Kogtenkov\|Alexander Kogtenkov]] 07:39, 24 August 2009 (UTC)	+	The other variants are '''abstraction''', '''structure'''.
		+
		+	For '''language_interface''' the following category names could fit:
		+	* '''bridge''' (unfortunately could be misinterpreted as a pattern name)
		+	* '''invocation'''
		+	* '''platform''' (most suitable from my point of view)
		+	--[[User:Alexander Kogtenkov\|Alexander Kogtenkov]] 07:54, 24 August 2009 (UTC)

@@ Line 136: / Line 136: @@
        example
        test
+----
 '''--[[User:Manus|manus]] 17:09, 22 August 2009 (UTC)''': I've taken most of the non-controversial suggestions. Let me know what you think. There are two categories that deserves a better name '''language_interface''' and '''data_structure'''.

← Older revision		Revision as of 17:09, 22 August 2009
Line 136:		Line 136:
	example		example
	test		test
		+
		+	'''--[[User:Manus\|manus]] 17:09, 22 August 2009 (UTC)''': I've taken most of the non-controversial suggestions. Let me know what you think. There are two categories that deserves a better name '''language_interface''' and '''data_structure'''.

← Older revision		Revision as of 07:19, 21 August 2009
Line 125:		Line 125:

	--[[User:Jfiat\|Jocelyn]] 06:04, 21 August 2009 (UTC)		--[[User:Jfiat\|Jocelyn]] 06:04, 21 August 2009 (UTC)
		+
		+
		+	----
		+
		+	--[[User:Ericb\|Ericb]] 07:19, 21 August 2009 (UTC): That's what I had planed to do with the Gobo libraries. But using singular names of course! I'm currently considering moving the Gobo repository to git. While doing that, I'm also considering creating a single repository per library and tool. That way people won't have to get the whole XML library if they are only interested in the Decimal library for example. If I do that, of course the libraries will have to be self-contained. Their tests, examples and docs should come along. It would be nice if ISE's and Gobo's (and other's) libraries and tools could follow the same pattern. That way people would be in known ground when they download and use a new library. The directory structure that I have in mind is something like that:
		+
		+	<library_name>/
		+	code (or src, or source)
		+	doc
		+	example
		+	test