Re: Design question: polymorphism after object creation

Hi,

I am seeking for a neat solution for the following problem:

There are objects of different types with a common base class, let's say
folders and files (although that does not completely hit the nail on the
head). These objects have a common primary key, the full qualified path.
But the polymorphic type of the objects emerges only *after* the object
has been referenced. See below.

The implementation currently uses a static instance repository of all
objects. The objects are reference counted and only instantiated by a
global factory function. Two objects with the same key must not coexists
in memory.

// int_ptr<T> is mostly the same than boost::intrusive_ptr<T>

class Base;

class Repository
{ ...
 public:
  // Singleton!
  static Repository Instance;

  // Seek whether an object is already loaded.
  // May return NULL
  int_ptr<Base> FindByURL(const string& url);
  // FACTORY! Get a new or an existing instance of this URL.
  // Does not return NULL
  int_ptr<Base> GetByURL(const string& url);
};

When instantiating the objects by their path (e.g. while enumerating a
folders content) the exact type of the object is not yet known. Only if
the application requests certain information about the object, the type
has to be specialized. Unfortunately this is not always a cheap
operation. In fact it cannot be done synchronously at the time the
factory is called.

class Base
{public:
  const string URL;

  enum InfoFlags // Different kind of information
  { IF_None = 0,
    IF_Metadata = 1,
    IF_Content = 2,
    IF_Type = 4, // The polymorphic type of the object
    ...
  };

  // Retrieve information asynchronously if the requested information is
  // not yet available. The function returns the flags of the requested
  // information that is immediately available.
  // For all the missing bits you should wait for the matching
  // InfoChange event to get the requested information.
  // If no information is yet available, the function returns IF_None.
  // Of course, you have to register the event handler before the call
  // to EnsureInfoAsync. If EnsureInfoAsync returned all requested bits
  // the InfoChange event is not raised as result of this call.
  virtual InfoFlags EnsureInfoAsync(InfoFlags what);

  // Observable pattern
  event<InfoFlags> InfoChange;

  // Retrieve the current meta information. Returns only valid info
  // if EnsureInfoAsync has returned IF_Metadata or the InfoChange event
  // has fired with IF_Metadata set.
  virtual Metadata GetMetadata() const;
  ...

 protected:
  Base(const string& url) : URL(url) {}
};

class File : public Base
{public:
  virtual Metadata GetMetadata() const;
  ...

 protected:
  File(const string& url) : Base(url) {}
  friend class Repository; // For the factory
};

class Folder : public Base
{public:
  virtual Metadata GetMetadata() const;
  ...

 protected:
  Folder(const string& url) : Base(url) {}
  friend class Repository; // For the factory
};

At the very first no information is available about the object. Only if
some information is requested, I/O operations take place to specialize
the object. Of course, once specialized, the type will never change.

Now the problem is at the time the object is created, I have only an
empty shell, that forwards EnsureInfoAsync to plug-ins to determine the
effective type of the object. But at this time observers are already
registered and strong references to the object are around in the
application. Therefore it is not sufficient to atomically replace the
generalized object by the specialized one in the repository.

The only idea I have so far is to introduce another level of indirection
and replace all occurrences of int_ptr<Base> by int_ptr<BaseProxy>.
BaseProxy contains the int_ptr<Base> and forwards the functionality. But
this is neither clear nor of high-performance. Furthermore some services
have to be provided by BaseProxy only, e.g. the observable pattern or
the synchronization. This causes a briskly interaction between BaseProxy
and Base, although these classes are unrelated from the C++ point of
view. No well designed OOP.

So, are there any other ideas to implement something like that?