[Kde-pim] KCalCore Ptr typedefs and constness

[Ingo Klöcker]

On Saturday 21 August 2010, Bertjan Broeksema wrote:
> Hi David, pimsters,
> 
> David Jarvie wrote:
> > I think that many of the method signatures in kcalcore are
> > misleading because they use for example 'const Event::Ptr&' which
> > gives the initial impression of being equivalent to 'const
> > Event*', but is actually equivalent to 'Event* const', i.e. only
> > the pointer is constant, not the object pointed to. I think it
> > would be a bit clearer to pass 'const Event::ConstPtr&' which
> > *would* be equivalent to 'const Event*'.
> 
> equivalent to 'const Event * const' even.
> 
> David, although I fully aggree with the arguments you bring up, I'm
> not sure that bringing in ConstPtr is the right solution. To make
> the *full* api const correct, you'd end up with numberous of
> overloads which imo results in an api that is hard to read and hairy
> to use/maintain.
> 
> I already said in an internal discussion at KDAB on this topic that
> we now somewhat ended up with an java style API. That is, change
> something here and it will be magically changed at the other side of
> the universe as well.
> 
> I see two possible ways to approach this problem:
> 
> 1) Pass the *::Ptr objects by value:
> 
> e.g. setPerson( Person::Ptr person )
> 
> This would give slightly more overhead but probably negligble and
> makes indeed clearer that we're working with pointers here and not
> with ConstPtr or const objects. This would still leave the need of
> prominent and clear documentation about memory management/ownership
> of the objects passed around. But that was not very different in the
> old situation.

This is just wrong. Non-POD should always be passed as const &.


> 2) Make the API value based.
> 
> e.g. setPerson( const Person &person )
> 
> This is of course even more clearer than the Ptr/ConstPtr approach.
> *But* this would I think require a considerable amount of work. I.e.
> changing the API and port kdepim (again).

This approach will either make assignment expensive (if all data needs 
to be copied on assignment) or, if one uses implicit or explicit 
sharing, it will require additional API and make the API more difficult 
to use because you have to know exactly what the assignment does.


Anyway, I don't see the need to change anything if introducing ConstPtr 
is not an option (I don't have an opinion about this because I don't 
know enough of the API). The semantics of const Event::Ptr& is probably 
not immediately obvious if one sees this (standard C++) construct for 
the first time but one will learn the semantics very quickly.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100822/bedbc9f9/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/