[Gambas-user] Library and File

Benoît Minisini g4mba5 at gmail.com
Fri Nov 16 11:34:38 CET 2018


Le 16/11/2018 à 08:19, Christof Thalhofer a écrit :
>> "NameSpace:Class" will be a new syntax for the class "Class" exported
>> into the global symbol table "NameSpace". The ":" is a good candidate
>> for that syntax, as it does not conflict with the label declaration
>> syntax, which is an identifier always ending with ":".
> 
> Yes, something like that. I know that the decision for identifiers for
> namespaces in other languages caused a lot of discussions, if ":" works
> in Gambas easily: Great!
> 
>> We can imagine a project default namespace, so that you don't have to
>> write "Export NameSpace" in all your classes, but just "Export".
> 
> Ok, I think the vendor name in a library is a good candidate for
> defining the namespace so that all exported classes are available from
> outside as
> 
> vendorname:classname

Not really. The vendor is the vendor. The namespace is an arbitrary 
identifier that may have nothing to do with the vendor.

> 
>> "Export Default" will always export to the default global symbol table.
> 
> Dangerous!
> 
> I think this should be forbidden in future or at minimum deprecated. It
> gives the author of a library the ability to destroy foreign code by
> accident.
> 
> Am I wrong?

Yes. A library will always have the ability to destroy everything, 
having a global symbol table or not.

I won't remove the global symbol table. It will break the old code, and 
more important, it's the heart of the many Gambas feature and simplicity.

> I had a discussion in a large German community with an expert who has a
> lot more experience with computer language design than I. He gave me
> some advices (in German, thanks to deepl.com I am able to cite it in
> English here):
> 
> ------------------------------------------------------------------------
> 
> You have to set things up in such a way that you can find out at any
> time what was involved and for what reasons.
> 
> Baselines:
> 
> 1. Namespaces are based on domain names. This is the easiest way to
> avoid name conflicts right from the start. Alternatively you can build
> your own registry, but this is legally mined territory because of
> trademark rights and sovereign names (what should the registry do if
> someone wants to have the namespace "UTF-8"?)

The language won't force anything about namespaces and possible 
conflicts. It's up to another mechanism, if a mechanisme is actually 
really needed.

For example, if you can see with each library all the namespace it 
exports to, conflicts can easily be detected. We can even imagine the 
possibility of renaming the namespaces used by a library.

> 
> 2. Possibility to declare module dependencies. One can orientate oneself
> on the dependencies of existing systems, e.g. the package
> administrations of the Linux distros (yum, pkg, dpkg etc.) and Maven.

How is that different from the current dependency mechanism?

> 
> 3. Default policy: Once a module has been released, it must never be
> changed again. Also no bug fixes - the old version is still needed for
> any future bug diagnosis. If a new version has to be released, the
> publisher makes a new version number, which becomes part of the module
> name. I'm not sure if the Maven policy of allowing you to change the
> "SNAPSHOT" is good; at the moment I tend to re-version every single
> compilation and have a policy about which versions will be taken out of
> circulation under which circumstances.
> 
> Since the namespace is global, there is more to it than just a little
> syntax.

I don't see how a language could enforce that.

> 
> Translated with www.DeepL.com/Translator
> ------------------------------------------------------------------------
> 
> 1) Is not possible in Gambas because vendor name cannot contain a dot.
> 
> 2) Since libraries are currently organized in a way that involves names
> together with version numbers the basics for that are done IMO.
> 
> 2) and 3) cover a global organization structure and release strategy
> like one can find realized in https://packagist.org/ for PHP or
> https://www.cpan.org/ for Perl.
> 
> Alles Gute
> 
> Christof Thalhofer
> 

-- 
Benoît Minisini


More information about the User mailing list