|
2 | 2 |
|
3 | 3 | > UNIT name
|
4 | 4 |
|
5 |
| -Declares the source module as a unit. Units are a set of procedures, functions and/or variables that can be used by another program or unit. |
| 5 | +Declares the source module as a unit. Units are a set of procedures, functions, constants or variables that can be used by another program or unit. |
6 | 6 |
|
7 |
| -As of SmallBASIC version 0.12.6: |
| 7 | +- UNIT supports 'namespace' (Namespaces allow reuse of same names in different contexts. e.g. BitLib.Set(x) and StrLib.Set(x) are both using a function with the same name, "Set", but in different contexts). |
| 8 | +- While UNIT can be used as a collection of sub-routines for your own program, UNIT is particularly useful for creating a general-purpose library. General purpose libraries can be useful for many programs or projects, the same way the internal routine “PRINT” is useful for many programs, and not only for specific one. |
| 9 | + |
| 10 | +Use EXPORT to export procedured, functions, constants or variables. Only exported names can be access in the main program. |
| 11 | + |
| 12 | +### Example 1: Simple Unit |
| 13 | + |
| 14 | +First an example of the unit. Please save it with the filename "MyTestUnit.bas" |
| 15 | + |
| 16 | +``` |
| 17 | +UNIT MyTestUnit |
| 18 | +
|
| 19 | +export MyFunc |
| 20 | +export MySub |
| 21 | +export MyConst = 3.1415 |
| 22 | +export MyVar = 5 |
| 23 | +
|
| 24 | +func MyFunc(a,b) |
| 25 | + return a + b |
| 26 | +end |
| 27 | +
|
| 28 | +sub MySub(a,b) |
| 29 | + print "a + b = "; a + b |
| 30 | +end |
| 31 | +``` |
| 32 | + |
| 33 | +Second an example on how to use the unit. |
| 34 | + |
| 35 | +``` |
| 36 | +import MyTestUnit as u |
| 37 | +
|
| 38 | +u.MySub(1,2) |
| 39 | +
|
| 40 | +print u.MyFunc(2,3) |
| 41 | +print u.MyConst |
| 42 | +
|
| 43 | +u.MyVar = u.MyVar + 5 |
| 44 | +print u.MyVar |
| 45 | +``` |
| 46 | + |
| 47 | + |
| 48 | +### Example 2: An unit for using string |
8 | 49 |
|
9 |
| -#. UNIT supports 'namespace' (Namespaces allow reuse of same names in different contexts. e.g. BitLib.Set(x) and StrLib.Set(x) are both using a function with the same name, "Set", but in different contexts). |
10 |
| -#. UNIT name on Linux system is no longer case sensitive (which makes life easier for Linux users). |
11 | 50 |
|
12 | 51 | The UNIT file is strlib.bas:
|
13 | 52 |
|
@@ -83,122 +122,4 @@ Print Strlib.Rset("-->> ", 25)
|
83 | 122 | Pause
|
84 | 123 | ~~~
|
85 | 124 |
|
86 |
| -#. While UNIT can be used as a collection of sub-routines for your own |
87 |
| - program, UNIT is particularly useful for creating a general-purpose |
88 |
| - library. |
89 |
| - General purpose library can be useful for many programs or projects, |
90 |
| - the same way the internal routine "PRINT" is useful for many programs, |
91 |
| - and not only for specific one. |
92 |
| - |
93 |
| -#. It is very important to keep the syntax of EXPORTed routines fixed. |
94 |
| - For example: |
95 |
| - Imagine that the internal routine "PRINT" will use a new syntax in |
96 |
| - future version of SmallBASIC, something like: |
97 |
| - |
98 |
| -~~~ |
99 |
| -PRINT [fileN,] x, y, color, "string" ' the "new" syntax |
100 |
| -~~~ |
101 |
| - |
102 |
| - In this case many older programs will not work with the new version |
103 |
| - of SmallBASIC. |
104 |
| - |
105 |
| - The same way, when you create a UNIT to be used as a general-purpose |
106 |
| - library, you must keep the syntax of EXPORTed routines fixed, so old |
107 |
| - programs will continue to work well with newer versions of your UNIT. |
108 |
| - |
109 |
| -3. If you modify an existing UNIT, you should assign to it a new version number. |
110 |
| - The easy way to maintain a <a href=https://en.wikipedia.org/wiki/Software_versioning> Software versioning</a> is like this: |
111 |
| - |
112 |
| - "Unit Name", Version major.minor.revision, Release_Date |
113 |
| - |
114 |
| - For example: |
115 |
| - |
116 |
| -~~~ |
117 |
| -REM Unit "StrLib" Version 1.15.11, 20/3/2016 |
118 |
| -~~~ |
119 |
| - |
120 |
| - major number:> is increased when there are significant jumps in functionality such as changing the framework which could cause incompatibility with interfacing programs. |
121 |
| - minor number:> is incremented when only minor features or significant fixes have been added. |
122 |
| - |
123 |
| - revision number:> is incremented when minor bugs are fixed. |
124 |
| - |
125 |
| - By assigning a version number, other users will know what to expect from the |
126 |
| - modified version. You should also add a short description of the changes |
127 |
| - that you have made. |
128 |
| - |
129 |
| -4. If your UNIT is quite advanced, and you expect it to work differently in |
130 |
| - future versions, you can use the following method which allows Old & New |
131 |
| - programs to work with your unit correctly: |
132 |
| - |
133 |
| - Instead of using a fixed syntax for sub routines, such as: |
134 |
| - |
135 |
| - |
136 |
| -~~~ |
137 |
| -ZipText(string, method, fileName) |
138 |
| -~~~ |
139 |
| - |
140 |
| - |
141 |
| - Use a single object parameter which has a default value of 0: |
142 |
| - |
143 |
| - |
144 |
| -~~~ |
145 |
| -ZipText(x) |
146 |
| -~~~ |
147 |
| - |
148 |
| - |
149 |
| - Now, in version 1.0.0 for example, x might have this syntax as an array: |
150 |
| - |
151 |
| - |
152 |
| -~~~ |
153 |
| -x is [string, method, fileName] ' Version 1.0.0 |
154 |
| -~~~ |
155 |
| - |
156 |
| - And in some future version, x might have another syntax, such as: |
157 |
| - |
158 |
| - |
159 |
| -~~~ |
160 |
| -x is [string, method, fileName, format] ' Version 1.1.0 |
161 |
| -~~~ |
162 |
| - |
163 |
| - Or... |
164 |
| - |
165 |
| -~~~ |
166 |
| -x is [string, fileName] ' Version 1.14.5 |
167 |
| -~~~ |
168 |
| - |
169 |
| - Etc. |
170 |
| - |
171 |
| - The |
172 |
| - |
173 |
| -~~~ |
174 |
| -ZipText(x) |
175 |
| -~~~ |
176 |
| - |
177 |
| -routine will verify the number of arguments |
178 |
| -and/or their type (array, string, etc) and execute the correct code for this |
179 |
| -version's-syntax. |
180 |
| - |
181 |
| - This method is especially useful for maintaining a big project for a long |
182 |
| - time, which is going to offer more and more features in the future. It will |
183 |
| - allow old programs to work as usual, and new programs to benefit from the |
184 |
| - new features. |
185 |
| - |
186 |
| -#. UNIT should Export only> routines or constants (variables) |
187 |
| - which related to the specific use of that unit. |
188 |
| - For example, UNIT which offers string manipulation routines should only> |
189 |
| - Export string manipulation routines or string constants. |
190 |
| - |
191 |
| - If UNITs contain routines for many different uses, it is likely that two |
192 |
| - UNITs will have to IMPORT each other - and this is basically illogical. |
193 |
| - |
194 |
| -#. * UNIT must be documented well, so other users can use it. |
195 |
| - * UNIT should be efficient, because it should serves many other programs. |
196 |
| - * Routines syntax should be consistent and standard, to be easy to use. |
197 |
| - * UNIT is saved as Byte-Code (SBU), which is fast and does not include |
198 |
| - spaces, comments, etc. So feel free to add enough comments and spaces... |
199 |
| - |
200 |
| -There are more about UNITs (shared libraries), but the most important: |
201 |
| - When you write a UNIT to be used by others, try to be merciful... i.e. |
202 |
| - write clear and documented code, and make it easy for others to use your |
203 |
| - UNIT. |
204 | 125 |
|
0 commit comments