[openbeos] Re: The world as we know it
- From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 22 Sep 2002 21:54:22 -0400
>> That's nice, but if you don't understand why we are aiming for binary
>> compatibility (well, for you as a PPC user, we don't even do that :-
>> )),
>> please, just accept it. Be patient.
>
>I'm supposed to take your word for it?
OK, if not his, how about mine?
>Sure, you can do a lot without changing the API, without making any
>really major modifications to the system design. You can make a better
>OS. But the fundamental design of some things (like many of the
>inheritance issues in the API: see BSerialPort for an example) can't be
>fixed without a more wide-ranging overhaul. I'm not even proposing
>radical overhaul, just the recognition of systemic problems, and that
>we fix them. That we look at OpenBeOS systemically, instead of just
>modifying a piece here and there.
Sigh. We have been over this more times than I can count.
We are supposed to be doing this. On Glass Elevator. That *IS* your
charter. To look these things over and make suggestions. Take that bull
by the horns. Don't make a message here or there about it. Deliver some
great, grand design. We will look at it with a fair and unbiased opinion.
Far more so than we will distractions like this, here and now, when we have
a part of the course already plotted.
>It is nice, consistent, and modern... compared to the MFC. Outside of
>that, it is actually not particularly consistent (several different
>error-reporting strategies, inconsistent string formats, inconsistent
>use of abstract base classes), not particularly nice (Why the heck
>doesn't BMessage inherit from BFlattenable? And who thought up the type
>-specific data retrieval interfaces for BMessage?), nor particularly
>modern (other than classes, it displays a complete aversion to all
>features of C++).
A lot of this came about from different people writing things at Be at different
times. This is a place where some consistancy would be good. IIRC, BFlattenable
came long after BMessage. I want to say around DR9. I could be wrong, though.
I will give you a caveat, though, about the BMessage data type retrieval stuff.
I used to think a lot like you do. I wrote a system at my day job for database
I/O.
I used a generic method for populating a field that was overloaded with many
different types. Unfortunately, C++ was overly helpful with its built in type
casting
and caught me many times with trouble. These are harder to make right than they
sound. And harder to use for developers than they sound. Really. Not that it
can't
be done, but it isn't as trivial as it seems. A note from the trenches.
>Of course we want an OS with a great user experience. But developers
>are users too. The easier we make things for developers, the more we
>get, the more (and better) programs are written. That you can make an
>OS with an awesome user experience and a terrible API is illustrated by
>the Macintosh. But that is no justification for doing so.
Developers are people, too. And R5 is, IMHO, far better than anything else out
there. But your message that improvements need to be made is not falling on
deaf ears.
>Wonderful. But I would hope for more wide-ranging improvements as well.
Patience, young Jedi. Remember that, among other things, we are all learning.
None of us have ever done this before. You would have us learn how to write
an OS, design one, build it, test it and, build a killer organization at the
same time.
I very much thank you for your faith in our abilities. But I can tell you that
it is
*WAY* more than any volunteer group can chew.
>True enough on the philosophy bit. But even you agree that we don't
>just need a single person. And would you seriously support keeping the
>seriously over-extended and generally screwed up API we have now?
I wouldn't support that statement at all. The API needs some help and some
extension. But I would hardly call it seriously over-extended and screwed up.
>Wonderful. That's when I would add a new API too. And we would of
>course keep the R5 version (because of the different ABIs, they can
>even go in the same shared object).
There is a point at which this will become unwieldy. I don't know when or how
that will come about. But at some point, BC should be dropped. Will that be in
R2? R3? I don't know. I am not looking that far ahead. We can't at the moment.
But it will happen. And the fewer closed source apps that there are, the sooner
I think that day will come.
Other related posts:
