There was a time ca. Curl 1.7 when developers seemed to think that {package} was to be used to prevent circular declaration issues and such in Curl source. In that view, {package} is not much different than a main class in a Java or C# file.
But more and more it is uncommon to see any actual source in a file with a {package} herald; what one sees are {import} expressions and includes,
However the included files themselves have no heraldic metadata other than [char-encoding}
Perhaps the issue of source file metadata could be approached in terms of a herald that captures the need for the JIT to compile-at-load but not serve as the common namespace achieved by {package}
{module} comes to mind but in other languages it is synonymous with the introduction of namespaces
{parcel} and {assembly} are possibles ....
There is also a possible variant
{outer}
{inner}
which covers 'file' visibility without introducing a namespace and has something curly-brace about it ... but they tend to be used in reference to looping control.
From bookbinding comes 'codex' 'signature' 'helix' 'velo' and 'folio' among others ...
One option:
{source outer? = true} || must be the outer herald of the physical file (first item in the file at top level) for outer? to be true
{source inner? = true} || must be within a {source outer? = true} for inner? to be true
In an editor only the outer? contents might be displayed ( keeps implementation details further outa sight without being packaged up elsewhere) when you do not want to see such details
Almost all metadata would be at the outer? level when that is set to true
the default is for outer? to be false and inner? set to true is ignored unless ...
A file of equi-valence classes would have {source } entries with none being inner?
A file with a principal class (API is here) and private implementation class in the same file would have an outer? = true {source} herald
This could be very helpful when there is no packaging changes occuring but there is refactoring occurring across implementation details across files
But more and more it is uncommon to see any actual source in a file with a {package} herald; what one sees are {import} expressions and includes,
However the included files themselves have no heraldic metadata other than [char-encoding}
Perhaps the issue of source file metadata could be approached in terms of a herald that captures the need for the JIT to compile-at-load but not serve as the common namespace achieved by {package}
{module} comes to mind but in other languages it is synonymous with the introduction of namespaces
{parcel} and {assembly} are possibles ....
There is also a possible variant
{outer}
{inner}
which covers 'file' visibility without introducing a namespace and has something curly-brace about it ... but they tend to be used in reference to looping control.
From bookbinding comes 'codex' 'signature' 'helix' 'velo' and 'folio' among others ...
One option:
{source outer? = true} || must be the outer herald of the physical file (first item in the file at top level) for outer? to be true
{source inner? = true} || must be within a {source outer? = true} for inner? to be true
In an editor only the outer? contents might be displayed ( keeps implementation details further outa sight without being packaged up elsewhere) when you do not want to see such details
Almost all metadata would be at the outer? level when that is set to true
the default is for outer? to be false and inner? set to true is ignored unless ...
A file of equi-valence classes would have {source } entries with none being inner?
A file with a principal class (API is here) and private implementation class in the same file would have an outer? = true {source} herald
This could be very helpful when there is no packaging changes occuring but there is refactoring occurring across implementation details across files
Tags:
metadata,
scurl,
source,
refactoring
