[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [octvae forge] shadowing between packages

From: Andrew Janke
Subject: Re: [octvae forge] shadowing between packages
Date: Sat, 16 Mar 2019 20:48:53 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3

On 3/16/19 8:28 PM, JuanPi wrote:
Hi all,

I need to ask suggestion on how to solve the following situation:

1. Package A implementes funcA
2. Package B also implementa funcA, but is much better than A's funcA
3. Package B depends on Package A

Clearly Package A needs to run on itself, and if Package B is loaded
funcA is now pointing to B's funcA... this means functions from A
using funcA might fail (e.g. signature incompatibility)

What solutions do you have?

We have considered:
1. Renaming B's funcA to funcA_B ... not ideal, but well if that's it...
2. Creating a new package mirroring A, that renames funcA into funcA_A
... breaks all A's functions as does the shadowing, unless done
3. Renaming functions of package A when package B is loaded, and
putting them back when package B is unloaded

2. is done via CVS, but as said is not actually a solution, unless one
renames everythig
3. We do not know actually how to do it! :D

Is 1. the only solution?


Namespaces. Or classes.

If Package A's funcA is for A's internal use, or has distinct semantics from Package B's funcA, it could go in a +pkgA namespace. And Package B's funcA could go in +pkgB. That way they can coexist, and each package calls its own funcA(). Instead of a namespace, you could also make them methods on distinctly-named classes in Package A and Package B.

If you want to replace them globally and dynamically, such that both packages will be calling the same funcA() implementation, but you can select which one at runtime, then you could use a "factory" pattern: Have a global func_a_provider class or function that returns a function handle to a funcA implementation. It uses one of them as a default. And it provides a "register" behavior that allows code to replace the default funcA implementation with another function (or class) at run time. Java and similar languages use "factory" and "service provider interface" patterns to do this.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]