[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.

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:

Better safe than sorry.

Accessors give you the safety.

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

Other related posts: