1. public, export

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

new topic     » topic index » view message » categorize

2. Re: public, export

jiri said...

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: public, export

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

new topic     » goto parent     » topic index » view message » categorize

4. Re: public, export

Some more examples would definitely be useful.

The difference between export and public has eluded me as well.

new topic     » goto parent     » topic index » view message » categorize

5. Re: public, export

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

new topic     » goto parent     » topic index » view message » categorize

6. Re: public, export

Many thanks to Jim for his clear exposition and to Jeremy for his examples.

jiri

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu