Libraries - Revision history

Bmeyer at 00:34, 27 January 2010

2010-01-27T00:34:13Z

@@ Line 107: / Line 107: @@
 The idea is that a library can never be "broken" from the outside: it always works independently of existing usage.
 == Implementation ==
@@ Line 117: / Line 124: @@
 * Making sure that renaming (prefixing) classes of a library A in a library B does not affect other parts of the application, including other libraries.

Bmeyer: /* How to perform a renaming */

2010-01-27T00:33:27Z

How to perform a renaming

← Older revision		Revision as of 00:33, 27 January 2010
Line 119:		Line 119:

	=== How to perform a renaming ===		=== How to perform a renaming ===
	Under EiffelStudio, select Project Settings, then Libraries under Groups, and the desired library. Under "~~Advanced~~", ~~double-click~~ Renaming; enter the old ~~names (e.g. MONEY)~~ and ~~corresponding~~ new ~~names (e.g. CH_MONEY)~~.		Under EiffelStudio, select Project Settings, then Libraries under Groups, and the desired library. Under Advanced,go to Prefix and enter a prefix, such as "CH_" in the above example. That's it.

			If instead of choosing a single prefix for all classes of the library you want to define new names for some of them, select Renaming instead of Prefix; click the right column, then for affected classes enter the old name and the new name.

Bmeyer at 00:17, 27 January 2010

2010-01-27T00:17:31Z

← Older revision		Revision as of 00:17, 27 January 2010
Line 30:		Line 30:

	=== Name Clash Example ===		=== Name Clash Example ===
	==== ~~Library swiss_bank~~ ====		==== Swiss_bank library ====
	Provided by a Swiss bank		Provided by a Swiss bank

Line 38:		Line 38:
	* EUROCARD		* EUROCARD

	==== ~~Library us_bank~~ ====		==== Us_bank library ====
	Provided by a US bank		Provided by a US bank

Line 73:		Line 73:

	==== International Application ====		==== International Application ====
	~~Uses~~ both ~~swiss_bank~~ and ~~us_bank~~ to transfer money from a ~~swiss~~ bank to a ~~us_bank~~. MONEY and ACCOUNT conflict. To solve the name clash, the ~~user~~ adds a prefix CH_ ~~on the usage of the swiss_bank library~~ and a prefix of ~~US_ on the us_bank library~~.		An international application needs to use both Swiss_bank and Us_bank, for example to transfer money from a Swiss bank to a US bank. MONEY and ACCOUNT conflict. To solve the name clash, the author of the international application adds a prefix CH_ when using Swiss_bank classes and, similarly, a prefix US_ for those of US_bank.

	<code>[eiffel, N]		<code>[eiffel, N]
Line 102:		Line 102:
	end		end
	</code>		</code>
	As the renaming is done on the ~~usage~~ of ~~the~~ library, ~~this~~ does not break the ~~Local Swiss Application~~. ~~This allows~~ also ~~to have situations where we use~~ a library ~~directly~~ and ~~use another~~ library ~~that in its implementation~~ uses ~~the same library~~ and ~~we may have to do a~~ renaming~~, then this still works~~. The idea is that a library can ~~not~~ be "broken" from the outside~~. A library~~ always works independently of ~~what the~~ usage ~~of the library is~~.		As the renaming is done on the the side of library usage, it does not break any local applications that use only one of the libraries.

			The scheme also supports an application that uses both a library A and a library B which itself uses A, and some renaming is needed.

			The idea is that a library can never be "broken" from the outside: it always works independently of existing usage.

	== Implementation ==		== Implementation ==
	=== ~~UUID~~ ===		=== Unique library identifiers ===
	To decide if two libraries ~~that are~~ referenced in an application are the same ~~we use~~ a UUID. ~~This solves~~ problems that ~~occur~~ if the same library is referenced ~~with~~ different paths (for example with ~~symlinks~~). ~~This allows~~ to compile each library only once even if ~~it is referenced~~ multiple ~~times by~~ other libraries. ~~Renamings are handled in a way~~ that renaming/prefixing a library in a library does not ~~effect~~ other libraries or the ~~application itself~~.		To decide if two libraries referenced in an application are the same, the EiffelStudio scheme uses a UUID (unique identifier). Two problems this technique addresses are:

			* Any error that could result if the same library is referenced through different paths (for example with symbolic links).

			* Making it possible to compile each library only once even if multiple parts of the applications (including other libraries) refer to it.

			* Making sure that renaming (prefixing) classes of a library A in a library B does not affect other parts of the application, including other libraries.

			=== How to perform a renaming ===
			Under EiffelStudio, select Project Settings, then Libraries under Groups, and the desired library. Under "Advanced", double-click Renaming; enter the old names (e.g. MONEY) and corresponding new names (e.g. CH_MONEY).

Bmeyer: /* Local Swiss Application */

2010-01-26T23:59:26Z

Local Swiss Application

← Older revision		Revision as of 23:59, 26 January 2010
Line 46:		Line 46:
	* CHECK		* CHECK

	==== Local Swiss ~~Application~~ ====		==== Local applications (Swiss and US) ====
	~~Uses~~ only the ~~swiss_bank~~ library and does not have any conflicts.		The local Swiss application uses only the Swiss_bank library and does not have any conflicts.
	<code>[eiffel, N]		<code>[eiffel, N]
	class		class
Line 70:		Line 70:
	</code>		</code>

			The local US application is similar, using only the US_bank library.

	==== International Application ====		==== International Application ====

Manus: /* UUID */

2010-01-26T23:53:01Z

UUID

← Older revision		Revision as of 23:53, 26 January 2010
Line 105:		Line 105:
	== Implementation ==		== Implementation ==
	=== UUID ===		=== UUID ===
	To decide if two libraries that are ~~somewhere~~ referenced in an application ~~every library has~~ a UUID. This solves ~~the~~ problems that occur if the same library is referenced with different paths (for example with symlinks). This allows to compile each library only once even if it is referenced multiple times by other libraries. Renamings are handled in a way that renaming/prefixing a library in a library does not effect other libraries or the application itself.		To decide if two libraries that are referenced in an application are the same we use a UUID. This solves problems that occur if the same library is referenced with different paths (for example with symlinks). This allows to compile each library only once even if it is referenced multiple times by other libraries. Renamings are handled in a way that renaming/prefixing a library in a library does not effect other libraries or the application itself.

Manus: /* International Application */

2010-01-26T23:51:09Z

International Application

← Older revision		Revision as of 23:51, 26 January 2010
Line 101:		Line 101:
	end		end
	</code>		</code>
	As the renaming is done on the usage of the library, this does not break the Local Swiss Application. This allows also to have situations where we use a library directly and use another library that in its implementation uses the same library and we may have to do a renaming, then this still works. The idea is that a library can not be "broken" from the outside. A library always works ~~independent~~ of what the usage of the library is.		As the renaming is done on the usage of the library, this does not break the Local Swiss Application. This allows also to have situations where we use a library directly and use another library that in its implementation uses the same library and we may have to do a renaming, then this still works. The idea is that a library can not be "broken" from the outside. A library always works independently of what the usage of the library is.

	== Implementation ==		== Implementation ==
	=== UUID ===		=== UUID ===
	To decide if two libraries that are somewhere referenced in an application every library has a UUID. This solves the problems that occur if the same library is referenced with different paths (for example with symlinks). This allows to compile each library only once even if it is referenced multiple times by other libraries. Renamings are handled in a way that renaming/prefixing a library in a library does not effect other libraries or the application itself.		To decide if two libraries that are somewhere referenced in an application every library has a UUID. This solves the problems that occur if the same library is referenced with different paths (for example with symlinks). This allows to compile each library only once even if it is referenced multiple times by other libraries. Renamings are handled in a way that renaming/prefixing a library in a library does not effect other libraries or the application itself.

Manus: /* Name clashes and conflicts */

2010-01-26T23:50:36Z

Name clashes and conflicts

← Older revision		Revision as of 23:50, 26 January 2010
Line 12:		Line 12:

	=== Name clashes and conflicts ===		=== Name clashes and conflicts ===
	As libraries are designed and created ~~independent~~ of each other it is possible that two libraries have classes in them which have the same name. As long as the classes with the name clash are only in the implementation part of the library (and therefore not exported) the user of the library does not have to do anything as there is no conflict for him. If the name clash is in the interface part of the two libraries the user of the libraries has to deal with them. There are several possible solutions:		As libraries are designed and created independently of each other it is possible that two libraries have classes in them which have the same name. As long as the classes with the name clash are only in the implementation part of the library (and therefore not exported) the user of the library does not have to do anything as there is no conflict for him. If the name clash is in the interface part of the two libraries the user of the libraries has to deal with them. There are several possible solutions:

	# '''Prefixing''': He can prefix one (or both of the libraries) in his system.		# '''Prefixing''': He can prefix one (or both of the libraries) in his system.

Manus at 17:12, 11 August 2009

2009-08-11T17:12:18Z

← Older revision		Revision as of 17:12, 11 August 2009
Line 2:		Line 2:
	[[Category:Compiler]]		[[Category:Compiler]]
	[[Category:Configuration]]		[[Category:Configuration]]
			[[Category:Library]]
	== General ==		== General ==
	=== What is a library? ===		=== What is a library? ===

Patrickr: /* Name clashes and conflicts */

2006-10-26T22:10:38Z

Name clashes and conflicts

← Older revision		Revision as of 22:10, 26 October 2006
Line 14:		Line 14:

	# '''Prefixing''': He can prefix one (or both of the libraries) in his system.		# '''Prefixing''': He can prefix one (or both of the libraries) in his system.

	# '''Renaming''': Renaming is very similar to Prefixing, the only difference is that instead of adding a prefix to all classes, only one (or a few) classes receive a different name.		# '''Renaming''': Renaming is very similar to Prefixing, the only difference is that instead of adding a prefix to all classes, only one (or a few) classes receive a different name.

Patrickr at 22:10, 26 October 2006

2006-10-26T22:10:19Z

← Older revision		Revision as of 22:10, 26 October 2006
Line 11:		Line 11:

	=== Name clashes and conflicts ===		=== Name clashes and conflicts ===
	As libraries are designed and created independent of each other it is possible that two libraries have classes in them which have the same name. As long as the classes with the name clash are only in the implementation part of the library (and therefore not exported) the user of the library does not have to do anything as there is no conflict for him. If the name clash is in the interface part of the two libraries the user of the libraries has to deal with them. There are several possible solutions.		As libraries are designed and created independent of each other it is possible that two libraries have classes in them which have the same name. As long as the classes with the name clash are only in the implementation part of the library (and therefore not exported) the user of the library does not have to do anything as there is no conflict for him. If the name clash is in the interface part of the two libraries the user of the libraries has to deal with them. There are several possible solutions:

	~~====~~ Prefixing ~~====~~		# '''Prefixing''': He can prefix one (or both of the libraries) in his system.
	He can prefix one (or both of the libraries) in his system.

	~~====~~ Renaming ~~====~~		# '''Renaming''': Renaming is very similar to Prefixing, the only difference is that instead of adding a prefix to all classes, only one (or a few) classes receive a different name.
	Renaming is very similar to Prefixing, the only difference is that instead of adding a prefix to all classes, only one (or a few) classes receive a different name.

	~~==== Explicit dependencies ====~~
	In some situations it is also possible to solve the conflict by explicitly specifying the dependencies. For instance if library A is only used in Cluster my_cluster and Library B is only used in Cluster my_other_cluster. In this case we can specify that cluster my_cluster only depends on library A (and base) and cluster my_other_cluster only depends on library B (and base).

	=== Testing and Debugging of a library ===		=== Testing and Debugging of a library ===