[Gambas-user] Idea for 3.17
adamnt42 at gmail.com
Thu May 6 02:13:30 CEST 2021
On 6/5/21 4:23 am, Christof Thalhofer wrote:
> Am 05.05.21 um 20:20 schrieb Bruce:
>> Doesn't the vendor prefixing for libraries already provide that?
> 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
> 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?
(Nor do I know what would happen if I tried to publish a "gb.deg.form" )
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.
> 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.
> Namespaces should introduce that 'deganius.de:Mail' can be used together
> and independently of 'example.com:Mail'.
> As 'deganius.de' and 'example.com' are different namespaces the class
> 'Mail' in the second would not overwrite/enhance 'Mail' in the first.
> You could use in your software:
> 'deganius.de:Mail.Send(Address as string, Subject as String, Text as
> 'example.com:Mail.Send(Subject as String, Text as String, Address as
> string, PathToAttachment as String)'
> Note the different signatures of the methods.
> Alles Gute
> Christof Thalhofer
Yes that is one of the complexities.
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
These would all add complexity (and thus fragility) to the symbol table
lookup in at least the intepreter, the compiler and the IDE.
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?
No wonder Benoit keeps putting this in the "too hard" basket! :-)
More information about the User