[Gambas-user] Library and File

[Bruce]

I just hope that these proposed changes will not destroy neither the 
current nor the proposed pathing mechanism for libraries etc.

To explain, we rely heavily on accessing metadata in a "higher" level 
library from a "lower" one. This, I beleive is exactly the opposite of 
what is being proposed.

To be specific, we use a four level persistence mechanism that hopefully
can be explained as a dependency chain as follows, where "higher" is to 
the left and "lower" to the right.

Application --> BOL --> DAL --> PDL

BOL is a "business object layer", it knows all about the objects that an 
application needs to use in a specific domain.
DAL is a "data abstraction layer", it knows all about converting 
persisted data into object state values and vice versa. It also knows 
how to abstract some pretty complex mappings between object heirarchies 
and the underlying data model. It provides CRUD mechanisms to the BOL.
PDL is a set of "physical data layer" libraries that are switched 
depending on what persistence mechanism is used. I.e. there is a 
postgres PDL, a SQLite PDL and an XML PDL. Each of which knows how to 
store and retrieve persisted data of that ilk.

There is possibly a fifth level, just to be complete, below the PDL 
which is the Gambas components that let us read/write to an actual 
persistence mechanism.

Now as I said, the lower level libraries in the dependency chain depend 
on metadata that is stored in the higher level libraries. For example 
the BOL has metadata that maps object properties to conceptual storage 
data models. If you like, it acts as a sort of entity relational model.
The DAL layer needs to access that mapping model so it can implement the 
ER conversions. It also needs to know from the "Application" layer which 
specific persistence mechanism to be used and the specific instance of 
that mechanism. (This way, the application can specify that the data to 
be used is say in a postgresql database called xyzzy on a particular 
server or conversely in a postgresql database called plugh on a 
particular server or for that matter in holes in cheese stored on the 
moon. However, it has no idea of how the persistence occurs. It just 
knows that it wants to CRUD a certain object's state).

So the DAL plugs in the PDL library it needs for "this particular 
application" and "that particular BOL". That way we can use two or more 
BOLs in the same application. Given that it can produce a map between 
the ERM and a physical data model. AND THAT metadata needs to be made 
available to the PDL.

So each layer needs to access metadata in the next or highest level 
layer and occasionally in its' own layer. A lot of that metadata is 
static so we use files stored in each layers archive. The . .. (and ...) 
mechanisms have worked for us for going on ten years or so.

Now I believe this the complete opposite of what Tobi has been talking 
about here. In his case, he needs "downward" disambiguation (if there is 
such a word) from a higher level in the dependency chain. In other words 
from ONE at the higher level to MANY as we go down. What I am talking 
about is completely the opposite i.e. from one of the MANYs, depending 
on the instance, to the definitely only ONE of the ones.

Sorry to intrude.
b