Difference between revisions of "Library design"
(fixed titles) |
|||
| 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. |
||
Revision as of 13:54, 24 April 2007
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 WEAK_REFERENCE
- if a library function returns a STRING, always return the same -- and/or provide a function that appends into a user-supplied STRING (kinda append_in)
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.