Library design - Revision history

Hzwakenberg: spelling

2021-12-21T21:27:09Z

spelling

← Older revision		Revision as of 23:27, 21 December 2021
Line 20:		Line 20:
	=== Plugins ===		=== Plugins ===

−	The master word is: no magic. The code should be crystal clear. All that can be written in Eiffel is, and when low-level is ~~need~~ that should be clearly written in the code.	+	The master word is: no magic. The code should be crystal clear. All that can be written in Eiffel is, and when low-level is needed that should be clearly written in the code.

	In other words, the library basic bricks rely on externals. There are two kinds of externals used in the library: ''built_in'' and ''plug_in''.		In other words, the library basic bricks rely on externals. There are two kinds of externals used in the library: ''built_in'' and ''plug_in''.

Hzwakenberg at 10:48, 7 September 2014

2014-09-07T10:48:22Z

← Older revision		Revision as of 12:48, 7 September 2014
Line 1:		Line 1:
		+	[[Category: Library]]
−	== Design ==
		+	== Library Design ==

	The design depends on the library. (TODO: add a section for each library).		The design depends on the library. (TODO: add a section for each library).

Hzwakenberg at 18:53, 5 September 2014

2014-09-05T18:53:36Z

← Older revision		Revision as of 20:53, 5 September 2014
Line 1:		Line 1:
−	[[Category:Smarteiffel]]
−
	== Design ==		== Design ==

Ramack at 21:15, 4 March 2013

2013-03-04T21:15:23Z

← Older revision		Revision as of 23:15, 4 March 2013
Line 1:		Line 1:
−	[[Category:~~Book~~]]	+	[[Category:Smarteiffel]]

	== Design ==		== Design ==

Ramack: 9 revisions: initial import from SamrtEiffel Wiki - The Grand SmartEiffel Book

2013-03-03T21:46:15Z

9 revisions: initial import from SamrtEiffel Wiki - The Grand SmartEiffel Book

← Older revision	Revision as of 23:46, 3 March 2013
(No difference)

Cadrian: fixed titles

2007-04-24T12:54:12Z

fixed titles

← Older revision		Revision as of 14:54, 24 April 2007
Line 9:		Line 9:
	The library is developed using a few principles.		The library is developed using a few principles.

−	== Memory conservation ==	+	=== Memory conservation ===

	If a user does not use the GC, then they should be able to keep the memory footprint under control.		If a user does not use the GC, then they should be able to keep the memory footprint under control.
Line 19:		Line 19:
	* if a library function returns a [[library_class:STRING\|<tt>STRING</tt>]], always return the same -- and/or provide a function that appends into a user-supplied [[library_class:STRING\|<tt>STRING</tt>]] (kinda <tt>append_in</tt>)		* if a library function returns a [[library_class:STRING\|<tt>STRING</tt>]], always return the same -- and/or provide a function that appends into a user-supplied [[library_class:STRING\|<tt>STRING</tt>]] (kinda <tt>append_in</tt>)

−	== Plugins ==	+	=== Plugins ===

	The master word is: no magic. The code should be crystal clear. All that can be written in Eiffel is, and when low-level is need that should be clearly written in the code.		The master word is: no magic. The code should be crystal clear. All that can be written in Eiffel is, and when low-level is need that should be clearly written in the code.
Line 25:		Line 25:
	In other words, the library basic bricks rely on externals. There are two kinds of externals used in the library: ''built_in'' and ''plug_in''.		In other words, the library basic bricks rely on externals. There are two kinds of externals used in the library: ''built_in'' and ''plug_in''.

−	=== external "built_in" ===	+	==== external "built_in" ====

	Those are rare. They involve compiler-specific code.		Those are rare. They involve compiler-specific code.

−	=== external "plug_in" ===	+	==== external "plug_in" ====

	Those are the most frequent and are less compiler-involved. They use the general-purpose [[plugins]] mechanism.		Those are the most frequent and are less compiler-involved. They use the general-purpose [[plugins]] mechanism.

Cadrian at 12:48, 24 April 2007

2007-04-24T12:48:43Z

New page

[[Category:Book]]

== Design ==

The design depends on the library. (TODO: add a section for each library).

== Implementation ==

The library is developed using a few principles.

== Memory conservation ==

If a user does not use the GC, then they should be able to keep the memory footprint under control.

Of course, if one uses the GC, the library should not keep too many objects around just for reuse.

The general solutions are:
* use [[library_class:WEAK_REFERENCE|<tt>WEAK_REFERENCE</tt>]]
* if a library function returns a [[library_class:STRING|<tt>STRING</tt>]], always return the same -- and/or provide a function that appends into a user-supplied [[library_class:STRING|<tt>STRING</tt>]] (kinda <tt>append_in</tt>)

== Plugins ==

The master word is: no magic. The code should be crystal clear. All that can be written in Eiffel is, and when low-level is need that should be clearly written in the code.

In other words, the library basic bricks rely on externals. There are two kinds of externals used in the library: ''built_in'' and ''plug_in''.

=== external "built_in" ===

Those are rare. They involve compiler-specific code.

=== external "plug_in" ===

Those are the most frequent and are less compiler-involved. They use the general-purpose [[plugins]] mechanism.

Cadrian: Just to start the page. To be filled.

2005-06-16T11:34:20Z

Just to start the page. To be filled.

New page

[[Category:Book]]

* memory conservation
* plugins