Finally, because it's important

The de-virtualisation approach actually requires to

#include "PackageImplIf.h"

in Package.h. A simple forward declaration

class PackageImplIf;

is not sufficient. It would allow the compiler to handle a PackageImplIf*, but for piml(), the compiler must know, that PackageImplIf is derived from ResObjectImplIf (the complete ImplIf hierarchy).

It would be possible to avoid this, but it would require more complex templating. And there's not time for it.

Ergo: Even if the ImplIf is included, it's not intended to be used within the interface (Package.h in this example, or Patch.h, or...).

But what we can do is using typedefs from there. Example:

Patches need some list of Atoms. This could (and should) be typedef'd. But where?

Basically it's PatcheImplIf which describes the patch and which is used by both, implementation (derived from it) and interface (forwarding to it).

So that's the place for the typedef:

---[PackageImplIf.h]---
namespace zypp {
namespace detail {

class PatchImplIf : ...
{
public:
typedef std::list<Resolvable::Ptr> AtomList;

Some of the typedefs, like AtomList, should be used in the interface as well:

---[Package.h]---
#include "zypp/detail/PackageImplIf.h" // visible but not intended to be used..

namespace zypp {

class Patch : ...
{
public:
typedef detail::PatchImplIf Impl;

public:
typedef Impl::AtomList AtomList;  // ..except for the typedef

That's it. Hope it's a bit helpful to understand the intend of the current resolvable hierarchy. Others - like Capability - will follow (almost) the same rules.

Please try to support the structure. E.g keep your interface and implementation interfaces in sync, i.e. don't call some interface method foo(), and forward it to an implementation method called all_foos(). Strictly forward!

If it proves to be ok, we may find a way to generate these classes out of some interface description. Until this, we have to write similar code at several location.

Or we convince the outer world, that binary compatibility is for cowards.

Or you find a better way to do it.

Or ... ?

I know we've got little time to implement all the stuff we need. That's why we IMHO must spend time on elaborating concepts. It's far easier to maintain and improve a concept, than individual solutions with several classes.

Resist the urge to produce quick results. Our code will not be thrown away after preview. It will be a PITA for a couple of years ;)

(Yes, we may clean up things if we have some time. But if we're honest, we know that we'll have some time sometime, but not while maintaining the code)

back

Last edit in Trac '11/24/05 18:37:13' by 'kkaempf'

Libzypp/Design/Resolvable/Background

Finally, because it's important