[Gambas-user] Library and File

[Fabien Bodard]

Le ven. 16 nov. 2018 09:38, Bruce <adamnt42 at gmail.com> a écrit :

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

Sorry but I don't really understand the problem between your impressive
work and the namespace idea.

In your case you can use a specific space for all your class or use again
the global namespacing which is a bad idea because it will be reserved to
the gambas official libs.. Yes I'm a vinegrower ... so I've maybe missed
something (too many alcohol in air in my distillery) 😊

Regards,
Fabien Bodard

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gambas-basic.org/pipermail/user/attachments/20181116/efca98a7/attachment-0001.html>