> Hi, > > On Fri, 13 Dec 2002, Brad Settlemyer wrote: > > > No, that seems like a bad idea as const is used for compile time const > > checking by the compiler, but when implemented as a class the ability to > > substitute const instances is different I think. (e.g. const ness can > > always be resolved at compile time, type cannot). I can't see > any advantage > > in implementing const in this fashion, this does not allow you > to make const > > guarantees in you postconditions. > > Which part are you referring to? If it was the original idea of having > const methods that take a const node and return a const node (such as > getNextSibling) then the advantage I see is that if (for example)you pass > in a const DOMDocument to a method then you cannot change the document. > This seems a lot nicer. > [snip] > > Have I misunderstood you or am I missing something? > >
Yes, I think I must have been unclear. My only point was that a class cannot enforce constness via its own type (in your example ConstDomTreeWalker), because the enforcement mechanisms are different. Your way requires runtime type resolution at best, and even then can be circumvented without casting, whereas the only way to circumvent the const keyword is via a compile-time cast. I do agree that fixing the const correctness would be a good thing, I just don't think the way you proposed will work, Erik Rydgren however provided a solution which I do think is workable. Brad --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
