[openbeosstorage] Re: some suggestions

Sorry the delay on these. Mondays and Tuesdays don't leave me much free time.

> First the specific items:
> * Path.h: MustNormalize() could be static.

Good point. I'm sure it'll end up that way. :-)

> * Entry.h: `#endif // __sk_path_h__'

Thanks. Fixed. 

> * vfs docs, read/write/remove_vnode: As to be read in the ISO FS code
>   (/boot/optional/sample-code/add-ons/iso9660) the `char r',
>   parameter is a re-enter flag:

Thanks. However, we're done with these and aren't going to develop them any 
further. They were meant as an educational exercise and (rough) private 
reference, and that's really all. I should add an "index.html" file that 
mentions this.

> * 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?

> * 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? 

> * Am I the only one, who thinks the R5 storage kit classes are strangely
>   designed (to use moderate terms)?
>   E.g. why the heck has each class all its directly derived classes as
>   friends (see BStatable, BNode) instead of declaring certain members
>   protected? It seems to be a way to prevent the application programmer
>   from write subclasses that can access those members too.

No, I've noticed this too and come to the same conclusion: it must have been to 
prevent developers from getting to the internals of the system. It actually 
makes quite a bit of sense from Be's perspective IMHO, but it's definitely more 
questionable from our perspective.

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

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.

Thanks for the suggestions :-).

-Tyler

Other related posts: