[interfacekit] Re: BRoster & BWindow


> >> I suppose we should also get rid of all the FBC padding in the classes
> >> according to your argument, because after all, needing to add functions
> >> and data to a class only 'may happen'.
> >
> >     Please read again from the beginning this topic! You'll see it has
> > nothing to do with the FBC problem!
> >
> >     OR, is it I misinterpreted your sayings???
>
> Yes, you are misinterpreting.
>
> If your argument about not doing things because they "Might Happen" is
> correct, then we should never do anything because just because it "Might
> Happen". Like the FBC padding incuded in the classes.

    Yes, I do realize now, that the "might happen" argument isn't good.
Sorry. You're right, once it "may happen", means it happens!

>
> There is no garantee that we will ever need the extra space, but it is
> there because it makes things much better if it does.
>
> There is an addage:
    Right!

> Better safe than sorry.
    Yup!

> Accessors give you the safety.
    100% sure of that.
    I'm also 100% sure that modifying code "at the source" does.
        As I said, it is a good idea, but I don't see the need for them.

> If you want a real life example of this, consider the case of a string
class.
>
> You could just give direct access to the internal buffer so you can:
>
> String->fBuffer[10] = 'b';
>
> but this is foolish because you might one day want to use a copy-on-write
> semantic for the string using refrence counting. And you would have to
> break a lot of code to do that if you didn't have an operator[](uint32
> idx) defined for your string class.

    Alan!! (if, again I'm misinterpreting), I was not talking about adding
or removing methods/members/operators! I was talking about friends!


Adi.

Other related posts: