Modules and reflection

[Cleiton Santoia]

Hi Gabriel,

 I´m studying and proposing some horrible papers on reflection and I´m trying to make them horrible but complete and Module is a nice thing to reflect. 

1 - Do you understand exported and not exported parts of a module like "public" and "private" 

2 - Do you have some thoughts about attaching attributes to module definitions/import/using/export ?

3 - Can you "exdend" a module over more than one .cpp  without including, I mean in section 4.2.4 says

"its entirely needs to be produced by some tools that would scan all modules units making up the module."

This means that 

a.cpp

module x {
export { ... }
}

b.cpp

module x { // more of module x
export { ... }
}

module x has exported symbols in a.cpp and b.cpp ?

and we use them in c.cpp

c.cpp

using module x;//imports from a.cpp and b.cpp

Thanks

[Gabriel Dos Reis]

On May 21, 2014, at 2:35 PM, "Cleiton Santoia" <cleiton...@gmail.com> wrote:

Hi Gabriel,

 I´m studying and proposing some horrible papers on reflection and I´m trying to make them horrible but complete and Module is a nice thing to reflect. 

1 - Do you understand exported and not exported parts of a module like "public" and "private" 

In our view, a module interface (the exported part), is the set of entry points into a module.  That is visibility, not accessibility.  We understand that contemporary languages such as Java or C#  have long experience using 'private', 'public', 'internal', 'public private', etc. to describe visibility.  However, C++ has a much longer tradition in using 'public' and 'private' for accessibility.  We prefer to stick that established terminology to avoid unnecessary confusion.

Note also that the proposal is trying hard to avoid talking about linkage.  This is to avoid (1) elevating the notion of linkage above where it belongs; (2) the existing standard notions of linkage are poor compared to the diversity concretely available and we do not want to prevent implementations from supplying high quality experience.

A non-exported name does not necessarily have an internal linkage.  Such an entity may be internal to a module unit, or shared by a set of module units within the same module, but not available to the outside.

2 - Do you have some thoughts about attaching attributes to module definitions/import/using/export ?

We anticipate that, like any declaration, a module declaration may have attributes.  But since they are ignorable, we prefer to focus now on the core semantics.

In general, we are aiming for simplicity - which is required by the very nature of the problem we are tackling: programming in the large, e.g. scaling well beyond the billion lines of codes.

3 - Can you "exdend" a module over more than one .cpp  without including, I mean in section 4.2.4 says

"its entirely needs to be produced by some tools that would scan all modules units making up the module."

This means that 

a.cpp

module x {
export { ... }
}

b.cpp

module x { // more of module x
export { ... }
}

module x has exported symbols in a.cpp and b.cpp ?

and we use them in c.cpp

c.cpp

using module x;//imports from a.cpp and b.cpp

Thanks

The point we are making is that a module interface must be described in its entirety at exactly one place.   In practice, you will have a single source file, with an implementation-defined extension e.g. a.mi, that contains the interface of a given module.  In essence, they would be like your usual header files, except that you get isolation and the essential goodies we want from modules.  However, the implementation of the entities declared in the interface may span several module units, e.g. conventional source files that all declare belonging to the same module.

--
You received this message because you are subscribed to the Google Groups "SG2 - Modules" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modules+u...@isocpp.org.
To post to this group, send email to mod...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/modules/.