FreeLists / openbeosstorage / [openbeosstorage] Re: some suggestions

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On Mon, 8 Apr 2002, Tyler Dauwalder wrote:

> > * What do you think about code reviewing?
> 
> I think it's a very good idea. I was originally planning on leaving this
> until alpha->beta transition time, but I've been thinking lately we
> ought to do it in between pre-alpha and alpha as well (here taking
> pre-alpha to mean the previously designated base subset of classes:
> BEntry, BEntryList, BDirectory, BFile, BNode, BNodeInfo, and BStatable I
> think they were...they're up on the website now). We may be including a
> copy of libstorage.a in one of the upcoming releases so the test team
> and any other folks out there who might be interested can give our
> classes a workout; getting things tightened up a bit would be a good
> idea.
>
> I'm not opposed to doing it on a class by class basis as well, but due
> to the rather interdependent nature of the classes (the pre-alpha ones
> at least; a lot of the alpha classes are fairly independent), it seems
> like taking a step back and doing some polishing after we've got a nice
> set of classes all written up would be a better.
> 
> How about we wait until we're all done with the pre-alpha classes, at
> which point we'll do some sort of review, most likely Ingo (thanks for
> volunteering :-) and myself, but possibly a more general round-robin.
> Then we'll decide how best to handle the rest of the Kit from there.
> 
> Sound reasonable?

Absolutely. :-)

> > * How to test binary compatibility?
> >   As soon as we can compile out classes with USE_OPENBEOS_NAMESPACE, we
> >   can write a test app, that compares the sizes of R5 and OpenBeOS class
> >   instances. Probably it is possible to test the vtables as well?
> 
> That's probably not a bad idea. Anybody know off the top of their head
> how to test vtables? 

Unfortunately I don't. Perhaps pointers to virtual functions can be
compared. That would be at least a start. I'll check this out later.

> >   Personally I vote for reducing those dependencies where possible, i.e.
> >   to make stuff needed by subclasses protected and to analyze whether
> >   friendships to other classes are really needed.
> 
> I'm going to reservedly say yes, I think this would probably be a better
> way of doing things. The one thing that sticks out in my mind as
> something we'll gain is the ability for the person writing a given class
> to be responsible for checking initialization status and parameter
> validity before using private data members. Certainly the person writing
> the friend class could do this as well, but it's more likely to be on
> the mind of the person writing the class that's being manhandled. Plus
> that way you write it once for each accessor as opposed to every time
> you access a private data member in a friend class. Being able to
> subclass the Storage Kit classes more easily is a bonus as well, but I
> don't know that this will realistically happen very often.

Yes, that's want I think too. Actually I don't want to encourage
application developers to subclass those classes using the currently
private members. Its more that I dislike this private-friends construction
as currently implemented. I would rather make the members protected, but
document them being internal and not to be used.

> Go ahead and do it for BDirectory, I'll work it into BEntry and BNode,
> and we'll see how things look. If it goes well, we can make it a
> kit-wide thing.

Alright.

CU, Ingo