[Gambas-user] Idea for 3.17

[Christof Thalhofer]

Am 06.05.21 um 02:13 schrieb Bruce:

> Inline ...

Yupp, better!

>> Yes, parts of. These are Gambas libs we use here, they reside in the
>> "Gambas vendords namespace" 'deganius':
>>
>>> christof at tof-x230 /usr/lib/gambas3/biz1 » ls /usr/lib/gambas3/deganius
>>> deg-betrieb:1.1.gambas
>>> deglib-basic:1.6.gambas
>>> deglib-gb:1.6.gambas
>>> deg-models-degdaten:1.0.gambas
>>> deg-report:1.0.gambas
>>> deg-statistik:1.0.gambas
>>> deg-tabpanel:1.0.gambas
>>> deg-telefon:1.1.gambas
>>
>> Dependencies seem to be managed well, also versions!
>>
>> But I cannot use '.' in a vendor name, so domain names are not allowed.
> 
> Ah yes, but not everyone has a domain name registered. In fact the farm 
> neatly gets around that by allowing anyone (registered) to publish 
> gambas software. I am not aware of any name collisions in the farm?

I don't talk about a bunch oft software which is placed in something
like a filesystem but has nothing to do with each other except the fact
that it is on the same disk.

I talk about shared libraries which come from different vendors but can
be used by the programmer inside the same program. I think, if you are a
professional programmer, wrote a library and want to share it with the
public, registering a domain does not cost very much.

So we could have the registration thing done. There is an existent
organization which does that for us. Instead, we would have to raise
that kind of organization by ourselves.

> (Nor do I know what would happen if I tried to publish a "gb.deg.form" )

This is also something I'm not talking about. 'gb.deg.form' is a
component for Gambas which I had to name this way because instead I
would not have been able to integrate it into the Gambas IDE. That's a
different thing, as it is no library.

> Another issue is where, locally I have different libraries - with 
> similar names containing classes with colliding names. Why? Because here 
> we have multiple software "products" to support (and multiple versions 
> of one product for racehorse trainers - the consortium version, a 
> tai;ored version for one particular trainer and a "free" version with 
> restricted functionality and "nags". Each version uses different 
> libraries with many similarly named classes). These are all adequately 
> handled by the vendor prefixing.

If you look at the domain system you could easily handle this by subdomains:

consortium.brucessoftware.com
tailored.brucessoftware.com
free.brucessoftware.com
...

In namespaces we needed something like aliases for that.

'Alias tailored.brucessoftware.com as Brucelib'

Then you could switch between libraries easily by changing that alias
and refer to 'Brucelib' inside your program.

And then your whole program would use 'tailored.brucessoftware.com' and
the other one 'free.brucessoftware.com'.

That can be changed via one line of code.

On the other hand you should also be able to define that every lib that
you use uses the Namespace "Global". It even should be default. Then the
symbols in it reside in the same namespace as every other Gambas symbol.

Then everything would be the same and you would not have to change your
program(s) at all.

>> Worse: Any class 'Mail' in one of these libs would enhance/overwrite any
>> other class 'Mail' loaded before. This is not what we need.
> 
> That is exactly what I am talking about - the ability to load multiple 
> libraries and not have the name collision problem.

I do not understand how you can load multiple libraries with the current
Gambas "and not have the name collision problem" …

Assume two libraries:

'bruce.gambas' and 'christof.gambas'

Both contain the class 'Mail' with the method 'Send' in it but with
different signatures of the methods.

What happens if you load them? You get an error that one method of them
is "incorrectly overwritten" by the other.

If we had namespaces and both would use different ones we can load them
both.

> The more I think about this the harder I believe it would be. Namespace 
> specificqtion would have to be done for any class reference. That would 
> include all declarations and all static references. So
> * object instantiation (local variables)
> * parameter declarations (methods using a colliding object)
> * function results
> * global variables
> * property declarations
> * static method calls
> * others?

Sure. Everything public.

> These would all add complexity (and thus fragility) to the symbol table 
> lookup in at least the intepreter, the compiler and the IDE.

Nope. Other languages handle the same problem well. Namespaces are not
rocket science.

https://realpython.com/python-namespaces-scope/
https://perlmaven.com/namespaces-and-packages
https://www.php.net/manual/en/language.namespaces.php

> Another matter, as you say, is that existing code must not be disturbed. 
> But I dont see how that could be achieved as that code would not specify 
> the namespace in all the above cases. So how could the gambas system 
> know how to resolve non-namespaced references? I I am currently using 
> the "deganius.de:Mail" library and then add the "example.com:Mail" 
> library to the project how could the gambas system know which library 
> all the existing references refer to?

As long as there is no namespace definition before the symbol name
everything is as before.

Think as there is a global namespace in which everything happens –
currently. This one should not be disturbed.

Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20210506/b3cf402b/attachment-0001.sig>