Libraries - Revision history

Bmeyer at 00:34, 27 January 2010

2010-01-27T00:34:13Z

Bmeyer: /* How to perform a renaming */

2010-01-27T00:33:27Z

‎How to perform a renaming

Bmeyer at 00:17, 27 January 2010

2010-01-27T00:17:31Z

Bmeyer: /* Local Swiss Application */

2010-01-26T23:59:26Z

‎Local Swiss Application

Manus: /* UUID */

2010-01-26T23:53:01Z

‎UUID

Manus: /* International Application */

2010-01-26T23:51:09Z

‎International Application

Manus: /* Name clashes and conflicts */

2010-01-26T23:50:36Z

‎Name clashes and conflicts

Manus at 17:12, 11 August 2009

2009-08-11T17:12:18Z

Patrickr: /* Name clashes and conflicts */

2006-10-26T22:10:38Z

‎Name clashes and conflicts

Patrickr at 22:10, 26 October 2006

2006-10-26T22:10:19Z

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

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

@@ Line 30: / Line 30: @@
 === Name Clash Example ===
-==== Library swiss_bank ====
+==== Swiss_bank library ====
 Provided by a Swiss bank
@@ Line 38: / Line 38: @@
 * EUROCARD
-==== Library us_bank ====
+==== Us_bank library ====
 Provided by a US bank
@@ Line 73: / Line 73: @@
 ==== 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]
@@ Line 102: / Line 102: @@
 end
 </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.
 == 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:

@@ Line 46: / Line 46: @@
 * 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]
 class
@@ Line 70: / Line 70: @@
 </code>
 ==== International Application ====

@@ Line 105: / Line 105: @@
 == Implementation ==
 === 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.

@@ Line 12: / Line 12: @@
 === 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.

@@ Line 2: / Line 2: @@
 [[Category:Compiler]]
 [[Category:Configuration]]
 == General ==
 === What is a library? ===

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

@@ Line 11: / Line 11: @@
 === 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 ===