Circular dependency in facade definition

[Jean Gautier (jeanga)]

Hi,

I have successfully migrated most of my project's interfaces (thank you so much! proxy rocks!).

With one last area to migrate, I am stumbling on the difficulty that proxy won't allow circular dependencies in facade definition.
While it's trivial to describe and implement with pure virtual interfaces and forward declarations, with proxy, this appears more challenging. I have managed to have "something" but I'm not sure it's the right way to proceed with proxy (i.e. should I stick to pure virtual interfaces in that context if this is orthogonal to proxy's philosophy).

Here is a simplified version of what I am trying to achieve:

• This is a type system with support for type related information (typename, size, etc.) that supports lists, array, structs, avl trees etc.
• types may reference other types, typically arrays have an element type, structs have fields.

Here is the facade definitions I tried:

A core type façade with no dependency!

PRO_DEF_MEM_DISPATCH(MemTypeName, TypeName);
PRO_DEF_MEM_DISPATCH(MemSizeOf, SizeOf);
PRO_DEF_MEM_DISPATCH(MemViewPtr, ViewPtr);

struct CoreTypeFacade : pro::facade_builder
::add_convention<MemViewPtr, const void*() const> // type-erased bridge to Full view
::add_convention<MemTypeName, std::string_view() const>
::add_convention<MemSizeOf, size_t() const>
::add_skill<pro::skills::as_view>
::add_skill<pro::skills::as_weak>
::add_skill<pro::skills::indirect_rtti>
::build
{
};

using CoreTypeProxy = pro::proxy<CoreTypeFacade>;
using CoreTypeWeak = pro::weak_proxy<CoreTypeFacade>;
using CoreTypeView = pro::proxy_view<CoreTypeFacade>;

The array facade is:

PRO_DEF_MEM_DISPATCH(MemCount, Count);
PRO_DEF_MEM_DISPATCH(MemArrayOf, ArrayOf);

struct Array : pro::facade_builder
::add_convention<MemCount, size_t() const>
::add_convention<MemArrayOf, const CoreTypeWeak& () const>
::build
{
};

So far so good 😄

The problem arises when I need to explore the ArrayOf type for specific information.
In that context, I need to "upgrade" my CoreTypeFacade to the full type facade:

PRO_DEF_MEM_DISPATCH(MemIsArray, IsArray);
PRO_DEF_MEM_DISPATCH(MemAsArray, AsArray);

PRO_DEF_MEM_DISPATCH(MemIsStruct, IsStruct);
PRO_DEF_MEM_DISPATCH(MemAsStruct, AsStruct);

PRO_DEF_MEM_DISPATCH(MemIsSimple, IsSimple);
PRO_DEF_MEM_DISPATCH(MemAsSimple, AsSimple);

struct SubTypeFacade : pro::facade_builder
::add_convention<MemIsArray, bool() const>
::add_convention<MemAsArray, pro::proxy_view<Array>() const>
::add_convention<MemIsStruct, bool() const>
::add_convention<MemAsStruct, pro::proxy_view<Struct>() const>
::add_convention<MemIsSimple, bool() const>
::add_convention<MemAsSimple, pro::proxy_view<Simple>() const>
::build
{
};
struct TypeFacade : pro::facade_builder
::add_facade<CoreTypeFacade, true>
::add_convention<MemIsArray, bool() const>
::add_convention<MemAsArray, pro::proxy_view<Array>() const>
::add_convention<MemIsStruct, bool() const>
::add_convention<MemAsStruct, pro::proxy_view<Struct>() const>
::add_convention<MemIsSimple, bool() const>
::add_convention<MemAsSimple, pro::proxy_view<Simple>() const>
::add_skill<pro::skills::as_view>
::add_skill<pro::skills::as_weak>
::add_skill<pro::skills::indirect_rtti>
::build
{
};

I had to split Type facade definitions (in CoreTypeFacade & TypeFacade) because I could not define SubTypeFacade with the TypeFacade as it has a circular definition.
(no "forward" declaring of proxies for very good reason).

For performance reasons, I can't lookup the dictionary with type names or "type ids".

When it starts to be complicated, on the implementation side, to be able to "upgrade" CoreTypeWeak into a full TypeFacade proxy I had to "hack" the following :

All concrete type implementing TypeFacade inherit TypeAware:

namespace detail {
    constexpr uint32_t kFullViewCookie = 0xF17FCAFEu; // any distinctive value
}

template<class F>
struct TypeAware
{
    struct ViewErased
    {
        pro::proxy_view<F> view{};
        uint32_t cookie{0};
    };

    ViewErased erased_{};

    void SetView(pro::proxy<F>& p) 
    {
        erased_.view   = pro::proxy_view<F>(p);
        erased_.cookie = detail::kFullViewCookie;
    }

    const void* ViewPtr() const 
    {
        return &erased_;
    }
};

Which allows to implement free functions to "upgrade" CoreTypeWeak into a TypeView:

inline TypeView ToType(const CoreTypeWeak& w) noexcept
{
    auto core = w.lock();  
    if (!core) return {};
    const void* p = core->ViewPtr();  
    if (!p) return {};

    const auto* e = static_cast<const TypeAware<TypeFacade>::ViewErased*>(p);
#ifndef NDEBUG
    if (e->cookie != detail::kFullViewCookie) {
        // Corrupted or uninitialized bridge; catch during debugging
        return {};
    }
#endif
    return e->view;
}

It works fine and I achieve decent performance (esp. this design avoids RTTI lookups for each "upgrade", only one at type creation which is ok). What I'm really not sure is that proxy may have better patterns for me to implement this type system in a different facade /proxy design.

If you are interested, a "sample" I crafted to explore my options :
type_proxy.zip

Of course, a perfectly valid conclusion to this could also be: stick to pure virtual interfaces and dynamic_pointer_cast... (somewhat disapointing but valid 😁)

Thanks for reading up to here !

[Mingxin Wang (mingxwa)]

Hi Jean Gautier (@jeanga),

Thanks for the thoughtful write‑up. If I'm reading it right, you want TypeFacade (not CoreTypeFacade) to be the sole abstraction that represents a type. In that shape, there's a cycle: TypeFacade needs Array (via AsArray), while Array needs TypeFacade (via ArrayOf).

Recommended approach: make Array generic and use a facade‑aware overload

Make Array a template that depends on an abstract facade parameter (F), and express AsArray via a facade_aware_overload_t. This breaks the cycle cleanly. Example sketch:

// Forward declare a template that depends on the facade F (can be TypeFacade)
template <class F>
struct Array;

template <class F>
using AsArrayOverload = pro::proxy_view<Array<F>>() const;

struct TypeFacade : pro::facade_builder
    /* ... other skills/conventions ... */
    ::add_convention<MemAsArray, pro::facade_aware_overload_t<AsArrayOverload>>
    /* ... */
    ::build {};

template <class F>
struct Array : pro::facade_builder
    ::add_convention<MemCount, size_t() const>
    ::add_convention<MemArrayOf, const pro::weak_proxy<F>& () const>
    ::build {};

In this setup, MemViewPtr/TypeAware become unnecessary and can be removed.

Alternative: keep Array concrete and introduce a dependent type

If you prefer Array to remain a concrete type, model the dependency in the type system with a metaprogramming trick so the name is dependent without changing the concrete type.

Minimal utility (I have this in my personal metaprogramming library):

template <class T, class... D>
struct dependent_trait : std::type_identity<T> {};
template <class T, class... D>
using dependent_t = typename dependent_trait<T, D...>::type;

Keep Array a simple struct, then the overload becomes:

template <class F>
using AsArrayOverload = pro::proxy_view<dependent_t<Array, F>>() const;

This keeps Array concrete while still making the reference to Array dependent on F (avoiding the early binding that causes the cycle).

Note that the alternative requires moving the TypeView/TypeWeak aliases after Array's definition. Those aliases instantiate TypeFacade, which (via AsArray) refers to Array; defining the aliases earlier forces the cycle too soon.

BTW, since as_view, as_weak, and rtti are already specified on CoreTypeFacade, you don't need to repeat them on TypeFacade as TypeFacade inherits them fully.

Hope this helps unblock your design. If there's anything missing or you want to dig deeper, happy to discuss more!

[Jean Gautier (jeanga)]

I don't know what I was doing!
It now compiles and runs great!
Challenge solved! Thank you so much Mingxin Wang (@mingxwa) !
I'm gonna be rocking proxy inside my project now ;-)

[Jean Gautier (jeanga)]

If you still have the test project at hand, I have a strange behavior.
This facade definition (added MemArrayOfTypeName, before MemArrayOf) compiles and runs:

PRO_DEF_MEM_DISPATCH(MemCount, Count);
PRO_DEF_MEM_DISPATCH(MemArrayOf, ArrayOf);
PRO_DEF_MEM_DISPATCH(MemArrayOfTypeName, ArrayOfTypeName);

template <pro::facade F>
struct Array : pro::facade_builder
::add_convention<MemCount, size_t() const>
::add_convention<MemArrayOfTypeName, std::string_view() const>
::add_convention<MemArrayOf, const pro::weak_proxy<F>& () const>
::build
{
};

but (added MemArrayOfTypeName after MemArrayOf ):

template <pro::facade F>
struct Array : pro::facade_builder
::add_convention<MemCount, size_t() const>
::add_convention<MemArrayOf, const pro::weak_proxy<F>& () const>
::add_convention<MemArrayOfTypeName, std::string_view() const>
::build
{
};

does not:

[build] D:\Projects\proxy\type_proxy.h(29,17): error C2143: syntax error: missing ',' before '<' [D:\Projects\proxy\build\default\main.vcxproj]
[build] D:\Projects\proxy\type_proxy.h(29,17): error C2143: syntax error: missing ',' before '<' [D:\Projects\proxy\build\default\main.vcxproj]

I am using latest MSVC Version 17.14.13 Preview 1.0.

[Jean Gautier (jeanga)]

Apparently, you can't have "any" convention added after a F dependent one.

PRO_DEF_MEM_DISPATCH(ListType_ListOf, ListOf);
PRO_DEF_MEM_DISPATCH(ListType_ListOfTypeName, ListOfTypeName);
PRO_DEF_MEM_DISPATCH(ListType_NodeType, NodeType);
PRO_DEF_MEM_DISPATCH(ListType_NodeTypeName, NodeTypeName);

template <pro::facade F>
struct ListTypeFacade : pro::facade_builder
    ::add_convention<ListType_ListOfTypeName, const std::wstring&() const>
    ::add_convention<ListType_NodeTypeName, const std::wstring&() const>
    ::add_convention<ListType_NodeType, const pro::weak_proxy<F>&() const>
    ::add_convention<ListType_ListOf, const pro::weak_proxy<F>&() const>
    ::build
{
};

Won't compile either.

[Mingxin Wang (mingxwa)]

Hi Jean Gautier (@jeanga),

This is a dependent-name parsing issue in C++. Once any add_convention in the chain mentions F (e.g., pro::weak_proxy<F>), you need to qualify the subsequent member templates with the template keyword, e.g.,

template <pro::facade F>
struct Array : pro::facade_builder
    ::add_convention<MemCount, size_t() const>
    ::add_convention<MemArrayOf, const pro::weak_proxy<F>&() const>
    ::template add_convention<MemArrayOfTypeName, std::string_view() const>  // template is needed here because the result of the previous add_convention depends F
    ::build {};

See the Notes of basic_facade_builder (Use the template keyword on demand when defining a facade template).

[Jean Gautier (jeanga)]

Hi Mingxin Wang (@mingxwa) ,

Sorry for the RTFM question... I was puzzled by this error (and late at night).
Many many Thanks for your help setting this up!

I am closing this discussion as you have more than answered my questions.
Kudos for your support to your community!

Jean