[openbeos] Re: The world as we know it

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

You asked me to "just accept" that we were aiming for binary 
compatibility. There is no reason for me to do so.

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

I'm not saying that everything needs to be changed, just that a 
substantial number of them do. And nearly everything needs some amount 
of tweaking.

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

Indeed. Compared to what's out there, it's a joy. But the competition 
isn't that difficult to beat, and the Be API is by no means perfect.

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

And *that* is why "improving the user experience" is no reason to keep 
an outdated and kludgy API.

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

In many cases it can be. I would submit a code sample here to read a 
signle string from application preferences, print it and read a new one 
from the command line. (it's at the end of the message). There is no 
reason, in a properly constructed API, that this couldn't be done in 3 
or 4 lines instead of 36.

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

But I would move straight to GCC 3 :P

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

Yeah, I don't know here. That was pure conjecture. It would be nice to 
do, if possible.
-Nathan

My code sample: (this has bad error checking, but I'm just trying to 
make a point, and didn't want to make it even longer)

int main(void) {
        char path[255];
        find_directory(B_COMMON_SETTINGS_DIRECTORY,0,true,path,255);
        strcat(path,"/foo-prefs");
        BFile file(path,B_READ_WRITE | B_CREATE_FILE);
        if (file.InitCheck() != B_OK) {
                printf("File init failed: %s\n",strerror(file.InitCheck()));
                return -1;
        }
        BMessage msg;
        msg.Unflatten(&file);
        char *string;
        if (msg.InitCheck() != B_OK) {
                printf("Prefs init failed!");
                return -1;
        }
        status_t err = msg.FindString("string",&string);
        if (err < B_OK)
                puts("No String!");
        else
                puts(string);
        char buffer[255];
        scanf("%s",buffer);
        if (msg.HasString("string")
                msg.ReplaceString("string",buffer)
        else
                msg.AddString("string",buffer);
        file.Seek(0,SEEK_SET);
        file.SetSize(0);
        err = msg.Flatten(&file);
        if (err < B_OK) {
                puts("Error during flattening!");
                return -1;
        }
        return 0;
}


--
Fortune Cookie Says:

California is a fine place to live -- if you happen to be an orange.
                -- Fred Allen

Other related posts: