Stefan Westerfeld wrote:
> You should mention what happens when there is more than one parent with
> default ports (and you don't specify anything) - however it's not really
> relevant what this is (if the result is undefined, well, thats fine as
> well, just needs to be documented).

Done! It's in the doc, so I won't repeat myself here.
BTW, there was a comment some time ago on kde-devel from a guy that had a vision
problem and couldn't read pages with a white background. I also personally find
white tiring for the eyes, so changed it to something smoother.

> Comments to your implementation:
> 
>  - isNull() shouldn't return true if b->_error() is true - that would mean
>    that an object could become null without the user changing anything -
>    rather these two conditions should be kept seperate

Ok, adding a bool error() funtion in no big trouble. Do we keep them completely
separate, or does error() return true when isNull()? I mean, if you do somthing
like
  Foo foo;
  foo.isNull();
and there is no implementation, then isNull() is true, but it can be argued if
it's an error or not.

>  - you probably don't need to increment the _base reference count every time
>    the pool reference count is incremented, that only wastes time - all "pool"
>    users can be mapped to one single "_base" reference

I wasn't too sure about it, but it seems logical. 

> - we can have const assignment operators again (as copying the reference to
> - we can do very fast assignments (as it is basically copying the "pool"
> C++ Foo f(Foo a, Foo b) may be possible after all.
> - SmartWrappers should be fast when doing method calls
> - SmartWrappers shouldn't bloat the libs too much
> - SmartWrappers should be usable for everything
> - SmartWrappers should be fast creatable
> - SmartWrappers should have const assignment and constructor args
> - SmartWrappers should expose the same cast behaviour as "real" base* stuff

;-)
I agree on all you said, and the 'should' lines above should not be a problem.
I cannot do it before some time though, quite busy right now...

> 
> The dot-forwarding will probably be the most critical part of all that, e.g.
> writing Foo f; f.xyz(). If the syntax was Foo f; f->xyz(); all that would
> be one operator -> overload. However, when you do dot-forwarding, inheritance

I don't see why inheritance would be a problem. Since the smartwrappers inherit
only between themselves, there is no virtual (or other) things to bother us.
Now, the _pool->base is a real pointer, so that should solve the vitual problems
when you do wrapper.method(); (in fact _pool->base->method())

> is the problem. The pool representation also is tricky and things like that.

It might be, indeed. But the current CVS has solved this very problem that
existed with the _var previous system, and I'm confident we can adapt your
solution to the pool idea.

> Please go on with your pool implementation (its IMHO the way to go, too),
> if you like commit the things you are working on. If you like, you can also

Well, to be honest, I had the idea while writing the last mail (took a couple of
hours!) and don't have any code other than that. Again, account for some time
before it's in the CVS...

> look at http://space.twc.de/~stefan/kde/download/smartwrapper-test.tar.gz,

I'll have a look, it's good to have more than one way to look at the same
problem.

Bye for now,
Nicolas
-- 
A shortcut is the longest distance between two points. (unknown author)