[Gambas-user] Idea for 3.17

[Brian G]

Good morning,

Ok I have done some testing with gambas regarding class and exports. I am Probably Just stating the obvious but.....

If you include a number of components/libraries thru component.load() that contain the class AnyClass
and your program also has a class AnyClass.

Each loaded component with the AnyClass Overloads AnyClass only until the application first references the class, 
in fact gambas does not load a class until it is first referenced at runtime.

So I can component.load() compa , compb, compc all containing AnyClass. The last component loaded will be the one referenced for the class load at runtime.

But if I reference the class in my application AnyClass first before loading other components containing AnyClass the APP version of AnyClass that will be used. Any subsequent
component.load() containing an exported class AnyClass will be cause that component's version of AnyClass to be ignored at runtime.

It looks like putting components into Project's component list causes the runtime to put entries for the exported classes into the classes collection at startup time.
So component's version will always overload our application version of the class. 

This sounds like a good way to handle such things.

Ok, Most people already know this, Just stating the obvious.

*********************************************************************

In the discussions so far it looks to focus on naming textual syntax not the actual implementations, you can call your components anything you like but it looks to come down to the
fact that we need a container for the classes we want to export that allows us at runtime/compile time to uniquely identify the class to load/reference(popup help).
It would seem we already have that container in the form of the component/lib/app. 

As a start to support name spaces what needs to be done is allow the Classes collection to contain class names that 
include the component name for lookup at runtime maybe a contraction of 'component:class' as the index, i.e. allow more than one definition of same class, but uniquely identify it.

A class already knows what component/lib/app to load from.
The old behavior would be possible thru the order of loading, the last def in is the first default out.

Can we look at what would be usable and practical within the existing gambas framework, that will get us down the road we are after. The fancy stuff could build upon this.

In the code the standard of component:class.item for static items, or component:class for class references  and no : in name refers to the last loaded or defined version of a class.

so....
if we have a class in our app we know is over ridden appname:myclass works to force our version to be instantiated... as the app is just another container that gets loaded first..

It would seem that this level of complexity as a first pass might be doable... with minimal changes to the underlying runtime environment and compiler

Well a thought. Perhaps needing far more work to do.

*********************************************************************

"Failure is the key to success; 
 each mistake teaches us something"  .. Morihei Ueshiba
Brian G

----- On May 6, 2021, at 1:34 AM, Christof Thalhofer chrisml at deganius.de wrote:

> Am 06.05.21 um 09:27 schrieb Bruce:
> 
>> On 6/5/21 4:08 pm, Christof Thalhofer wrote:
>>> 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.
>> 
>> This is the problem! The Gambas system does not understand the concept
>> "before".  For example and why I have an interest in this thread, some
>> time ago I wanted to create a library that contained a "Color" class.
>> This proved to be impossible as the gb.gui component already has a
>> static "Color" class. I specifically wanted a non-static class.
>> Notwithstanding that, every reference to "Color" before adding my now
>> hypothetical library refers to the gb.gui Color class. After I add my
>> library what do the un-namespaced references refer to? The compiler DOES
>> NOT KNOW that I have added a new library! It has no understanding of
>> what the project was like "before"!
> 
> I am not sure if I understand exactly, what you mean. And I also think
> that I may not always express myself correctly due to the language barrier.
> 
> Gambas currently has in fact one single namespace. This one where all
> the symbols reside. Therefor if you load a library which has the class
> 'Color' in it, it will overwrite the already existing class 'Color'.*
> 
> We can call this now already existing namespace "Global".
> 
> And this is the point where the concept of namespaces addresses your
> problem (and a lot of others). If we could have additional namespaces
> then you could define that symbols in your library reside in a namespace
> that you created and they will never collide with other symbols in other
> namespaces even when they have the same name.
> 
> Then you can create your own 'Color' class in the namespace
> 'Brucesoftware.com'.
> 
> And I can load a library you have written into my program and refer to
> this class by the name 'Brucesoftware.com:Color'.
> 
> 'Dim MyColor as new Brucesoftware.com:Color'
> 
> If the Gambas interpreter would be able to distinguish between the
> different namespaces and we get used to write libraries with own
> namespaces we can easily exchange code and I can use code you wrote and
> you can use code I wrote, even if we use the same names for our symbols.
> 
> Ok?
> 
> I have written an ORM and I'd like to give it to the public later. I
> called it 'DegOrm' and since then I pray every night before going to bed
> that noone in the Gambas universe ever comes to the idea to call another
> Class also 'DegOrm' – maybe in a component. Because if that happens and
> I would need that component in my software I had do rename every
> occurrence of 'DegOrm' in my software to make it work again.
> 
> That the Gambas interpreter currently has no understanding of namespaces
> hinders us all to exchange our code.
> 
> Alles Gute
> 
> Christof Thalhofer
> 
> *The interpreter does not allow you to overwrite the symbols with
> different signatures.
> 
> --
> Dies ist keine Signatur
> 
> 
> 
> ----[ http://gambaswiki.org/wiki/doc/netiquette ]----