1. public, export
- Posted by jiri Mar 15, 2009
- 993 views
The new version of 4.0 docs is pretty good already. Even the section dealing with scopes has been improved, but one thing is still puzzling me: the difference between public and export, if any. These terms seem to be used interchangeably in the libraries. If they are indeed synonyms, why do we have to have such stupid, misleading duplicity, well, I mean duplication? (Sorry, English is only my third language...)
jiri
2. Re: public, export
- Posted by jimcbrown (admin) Mar 15, 2009
- 1002 views
The new version of 4.0 docs is pretty good already. Even the section dealing with scopes has been improved, but one thing is still puzzling me: the difference between public and export, if any. These terms seem to be used interchangeably in the libraries. If they are indeed synonyms, why do we have to have such stupid, misleading duplicity, well, I mean duplication? (Sorry, English is only my third language...)
jiri
They are identical in every way but one.
Sometimes, in large multi-file libraries, it makes sense to declare different public symbols in different file, but still have the user of the library only include the main file. (win32lib is a good canidate for this)
The problem with public is that if you declare the symbol in a different file, other than win32lib.ew, then a user who includes win32lib.ew normally would not be able to see that symbol.
This is why we have 'public include' - win32lib.ew can become a file that just public include's all the other files. Then the user sees the public symbols regardless of which file they were originally declared in.
However, this creates a new problem. The 'public include' solution would make public no better than global, since ALL of the symbols that are shared with other files will be exposed in the main api file (e.g. win32lib.ew) Sometimes you need to share symbols between two different files of a multi-file library, but still keep it as an internal symbol and hide it from the user.
That is where export scope came from. export is identical to public in all ways but one - while public include will propagate public symbols to the next level, it will not propagate export symbols. To see these, you must still include the file that declares the symbol directly. Thus, public symbols are meant to be shared from a library and seen by a user, export symbols are meant to be used internally to the library only but between files.
So we have a range of: private - local - export - public - global
(You'd probably never need the export scope in a single file library.)
3. Re: public, export
- Posted by jeremy (admin) Mar 15, 2009
- 981 views
The Scope section of the manual goes into this a little. It should be expanded a bit to include some examples to better show it's reasoning. During the beta stages we are going to really focus on creating more unit tests and enhancing the docs more.
Jeremy
4. Re: public, export
- Posted by JansekVillaria Mar 15, 2009
- 968 views
Some more examples would definitely be useful.
The difference between export and public has eluded me as well.
5. Re: public, export
- Posted by jeremy (admin) Mar 15, 2009
- 979 views
A simple example right now:
-- button.e export function button_class_id() return "Button" end function public function button_new(sequence name) -- make new button return button end function -- window.e export function window_class_id() return "Window" end function public function window_new(sequence name) -- make new window return window end function -- gui.e public include button.e as but public include window.e as win ? button_class_id() -- Good! ? window_class_id() -- Good! -- myprog.ex include gui.e object w = window_new("Hello World!") -- Good! object b = button_new("Press Me") -- Good! ? window_class_id() -- Unknown Function! ? button_class_id() -- Unknown Function!
See, the *_class_id() methods are used internally for the multi-file GUI library. They are not meant to be used by the user, nor should the user be relying on them. Their implementation/functionality may very well change over time. So, the export keyword allowed those functions to be exposed to those who directly included button.e or window.e, but their availability was not passed on when gui.e did a public include button.e or public include window.e.
Jeremy
6. Re: public, export
- Posted by jiri Mar 15, 2009
- 949 views
- Last edited Mar 16, 2009
Many thanks to Jim for his clear exposition and to Jeremy for his examples.
jiri