[Gambas-user] Library and File

[Christof Thalhofer]

Am 16.11.18 um 00:02 schrieb Benoît Minisini:

> OK, let me try to summarize, condense and simplify all that... :-)

:-) Great! Thank you!

> What you'd like to have is apparently the following:
> 
> "Export NameSpace" will not export a class to the default global symbol 
> table, but to a specific global symbol table identified by "NameSpace".

Yes, something like that, but later on ...

> "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

We would have to think about whether namespaces should offer the
possibility to be organized in hierarchical ways, like filesystems. So
for example that later sth like

vendorname:db:Orm
vendorname:mail:Send

could be possible.

But also later on ...

> "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?

> All that will slow down the class name resolution, but it is done once 
> by class reference in a class, so it should not be a big deal.
> 
> Of course all that is just a suggestion, and will not be done in the 
> next version.

Yes sure, but I think there are two things which could bring Gambas to a
higher, more professional level: Testing and namespaces.

Maybe this is Gambas 4?

Now here is "later on":

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"?)

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.

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.

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

-- 
Dies ist keine Signatur

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gambas-basic.org/pipermail/user/attachments/20181116/15d3f483/attachment-0001.sig>