[openbeos] Re: The world as we know it

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Mon, 23 Sep 2002 01:26:51 CEST (+0200)

"Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx> wrote:
> > 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?

What do you mean? I will do as much as I can do make OpenBeOS R1 happen 
- so do many others. And that includes binary compatibility for BeOS R5 
x86.
A also want to have OpenBeOS R1 on PPC, but I can't do much work on 
that, because I don't have a PPC based machine (yet - perhaps).

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

Yes, of course, that's needed, and it will happen. Some classes might 
be completely replaced by better versions (but they will build upon 
what's done in R1, no doubt).
I think BSerialPort is a good example for this. BApplication would not.

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

You are exaggerating a bit here. The BeOS API has already proven to 
attract developers, it can't be that bad, and it sure isn't.
Of course, it is not 100% perfect, or consistent - that happens when 
you have so many people working on it, but it's still very good.
Coming from a Java world, I think both APIs are very comparable in the 
design. With lacks and short-comings, but also strengths and advantages 
at both sides.

I heard that even MS has learned how to do APIs in .NET.

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

Of course, they don't necessarily connect to each other. That's another 
reason why we can stick with the IMHO mostly nice and current Be API 
for R1.

> > I.e. querying non-indexed attributes took hardly two lines in the 
> > code 
> > for BFS - because the implementation allowed it.
> Wonderful. But I would hope for more wide-ranging improvements as 
> well.

Sure, so do I. And it would really make we wonder if it won't happen :-
)

> 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 introduced that single person as one person that just doesn't exist 
in reality. Again you're vastly exaggerating - sure, the Be API is not 
perfect, but it's still a nice API to work with.
Some lacks will be solved almost automatically, like the Net Kit issues 
(error codes, select, ...).
You don't like little things about inheritance and such - but that 
often doesn't matter much when you are working with those classes. Of 
course, sometimes it would really have been nice if this or that class 
would use a BDataIO, or would inherit from BArchivable. Not a big deal 
in my opinion.

> Wonderful. That's when I would add a new API too. And we would of 

That's the plan. Keep binary compatibility for R1 and later releases, 
and improve things with the move towards gcc 3 for R2.

> course keep the R5 version (because of the different ABIs, they can 
> even go in the same shared object).

I don't think so; I am not that familiar with the ABIs from both 
versions, but I could imagine that there are some double meanings or 
that some RTTI functions have the same name. I think it's a better 
design to have them separated from the new libraries.

Adios...
   Axel.



Other related posts: