[Gambas-user] Library and File

[Christof Thalhofer]

Hi,

Am 16.11.18 um 11:34 schrieb Benoît Minisini:

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

But in the current Gambas design in parts the vendor string plays a
similar role like namespaces do in other languages. It plays a important
role in the game "how libraries are found" and "how libraries of
different namespaces are separated from each other"

In PHP (this is a language I know a little) foreign libraries are
searched in the (PHP-) projects path under the directory "vendor". For
example:

christof at tof-x230 ~/programming/web/xyz.com/php ±master⚡ » find
-maxdepth 2 | grep vendor

./vendor
./vendor/phpunit
./vendor/symfony
./vendor/react
./vendor/pear
./vendor/pear-pear.php.net
./vendor/phpdocumentor
./vendor/zendframework
./vendor/webmozart
./vendor/michelf
./vendor/illuminate
...

If you look at Java there is a similar organization. But there it is
organized by domainnames.

Namespaces are used to separate things (files, classes) from each other
not only in code but also in other organization units like filesystems.

And afterwards in the community.

So ... as you decided to separate libraries in /usr/lib/gambas3/ by
vendorname I immediately thought of namespaces.

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

Yes I was wrong.

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

Yes thats right. But: If a vendor name like "gambas.net" isn't allowed
(as it is now in the IDE at minimum)  there is no way to organize
namespaces similar to domainnames later.

> For example, if you can see with each library all the namespace it 
> exports to, conflicts can easily be detected. 

Yes, locally, but not global. The expert I talked with had a more global
view on namespaces. Also a political. As with namespaces libs
potentially are "in the wild" later, someone could stand up and say
"Stop! This is my name! Don't use it or pay for it!". Bad if the lib is
important.

This cannot happen with domainnames. He gave us the advice to think
about that before we implement namespaces.

> We can even imagine the 
> possibility of renaming the namespaces used by a library.

Yes sure. Namespaces and even classes could be renamed (locally, in the
language). PHP does this like so:

use LongNamespaceString\LongerClassNameString as SmallName

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

I think not. I think the current mechanism is sufficient (I wrote that
at the end of my last mail). I must admit that I constantly work with a
lot of libraries but I do not really understand whats going on under the
hood. I did not read the code.

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

Why not with sha2 hashes?

With namespaces we all can share code much more easily because we have
no name clashes any more. So we can build mechanisms to deploy common
available libs and to integrate them in the own project.

So there must be a way to ensure that namespace/lib/version defintely is
an atom. A component could do this for example.

Imagine a "Export Lib" button which packs a library together with a sha2
hash over the whole project.

And a "Import Lib" Button on the other side which verifies that the lib
is clean (unchanged) and install it or update the predecessor.


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/20181117/26e6d538/attachment.sig>