[Gambas-user] Library and File

[Tobias Boege]

On Thu, 15 Nov 2018, Benoît Minisini wrote:
> Le 15/11/2018 à 01:41, Benoît Minisini a écrit :
> > 
> > What you could have done is defining a unique parent exported class
> > named "Help", with "CREATE STATIC" and create an non-exported class
> > inheriting "Help" in each library (maybe keeping the "Help" name, i.e.
> > reimplement it), then returning a singleton of that class to the caller.
> > 
> > So for me that case is not a strong argument for allowing free access to
> > the library namespace from the outside. Or having one name space for
> > each library export. I don't know exactly what you suggest.
> > 
> 
> Sorry it's late for me too, so I didn't see what your problem was exactly.
> 

Apparently it was *very* late for me yesterday. I didn't explain as
clearly as I would have liked to.

> Actually it's not a problem with namespace at all.
> 
> It's the lack of "library metadata returned by code".
> 
> At the moment, all metadata needed by Gambas are stored as files in
> library/component archives, so it's not big deal to extract them.
> 
> But if you want to return some metadata from a method in a
> library-independant way, you can't. Your method must be in an exported
> class, and the exported class name must be predictable.
> 
> You tell me that you should be able to use the same name, making the
> difference by prefixing it with the component name (which you call
> "namespace"), avoiding to have a different class in each library.
> 
> But the real solution may be that one: assuming that an exported class
> having the "same" name (not really the same, but marshalled in an unique
> way) is a class reserved for metadata (the "ME" at the library/component
> level).
> 

I didn't mean to hijack Christof's request for namespaces and my example
with the Help class wasn't meant as a representative of the whole issue.
I don't know if your "metadata" was focused just on getting help from a
library. If it wasn't, I didn't get what it was supposed to mean.
In general, this is not about getting specific metadata from a library,
but about the library providing classes to the user without polluting
the global symbol table and risking naming conflicts. [ Though I agree
that a Me for libraries sounds intriguing, *especially* to get stuff
like help comments programmatically. ]

I don't know why I don't see people writing and sharing Gambas libraries.
Maybe I don't look around enough (I certainly don't), or maybe there are
not enough Gambas programmers. My observation is that languages with a
flourishing "ecosystem", as they call it, have namespaces and a package
manager with automatic dependency resolution.

If a programming community wants to have user libraries that depend on
user libraries that depend on user libraries (which might very well pass
as a sign of a healthy language), I would expect there to be name clashes
when every one of them always exports all the symbols that any of its
users might want into a single table. Conversely, the fear of producing
such a mess might prevent people from sharing and reusing code. That's what
I read into Christof's statement, anyway.

Imagine you write a project using gb.web. It exports a class by the name
of "Request". I'm sure people can come up with applications where they
might want to load another library where having the class name "Request"
also makes total sense (maybe they are bridging between CGI and some other
software where Request doesn't unambiguously mean CGI request), but
merging both classes by inheritance breaks both classes. Should the
developer of the user library have in mind that his library might be
used together with gb.web and rename his class? Well, gb.web.feed does
that by prefixing all classes with an "Rss" -- primitive namespacing.

> Anyway, I don't want a mechanisme that allows to access non-exported classes
> inside components/libraries. They are not exported. They are private!
> 

Yes, and they should stay private. Looking at my favourite language
*with* namespaces, they have an additional distinction for privateness
(I know you don't like additional complexity in GamBAS, but here goes:)
By default symbols are /private/, like non-Export symbols in Gambas today,
they can be /shared/ in which case they are accessible from the namespace
they belong to via a namespace::symbol syntax, and they can be /exported/
into the importer's namespace, which is roughly the effect that Export
has in Gambas today, except that in Gambas it goes straight into the
global symbol table because there are no intermediate namespaces.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk