Michele, I realize: too much confusion... >In any case I propose to think small first. > >Some months ago I've proposed to try to create a Standard BASIC >without any Carbon. Even this won't be easy but with my little to no >knowledge of Obj-C and Cocoa and a bit more of Java, this task >appears manageable. If this is done, we could think bigger. > > >What sounds to me very difficult is to write a modern application >with just the FutureBASIC keywords. If you look at almost all the FB >code you could see a lot of call to Carbon functions. This was simply not intended. Furthermore, I doubt that what you want is possible without quite a lot of OO-knowledge and this means no more FutureBasic as a procedural language. >Since I don't believe that Apple plans to remove Carbon from their >system for a lot of time, I don't even think that it's important to >write a new runtime, based on Cocoa that just implements the >standard FutureBasic syntax. This is just for testing how to proceed. As I said: think small! >We have a working engine, who cares about the future? > >The new OOP runtime must answer to other issues. Carbon will never >removed from the system but his development was halted. ????? >Well, my experience with Java is that you can make an OO-language >appear procedural. Of course this wasn't intended by the languages' >creators and you loose quite a lot of the elegance and comfort but... > >The problem, in my opinion, is not the language. You could maybe >embed the standard FutureBASIC keywords in some sort of class, >methods. The problem is to access from source code to different part >of the Cocoa framework. > >FBtoC is a bridge between FB and Carbon API. Adding some OOP we can >reach Cocoa. If you add Cocoa, you need some Obj-C and because of Obj-C my suggestion is to then leave FB. >But Cocoa, for what I can understand, is something more than a >framework collection of API. It's a runtime enviroment. Well, may be, but the foremost problem with every programming language and modern GUI-OSs are the APIs. I've dwelled on this point over and over again. >We can hide the OOP part to the user but we strongly needs the tools >to access the underling framework. That's just what I've said in my recent posts. >I think that some OOP must propagate to user code. Maybe I could be >wrong but I don't think that it could be possible for the user to >ignore everything about Cocoa. Just like in today's FB it's >impossible to ignore some basic knowkedge about Carbon. Again, the problem is not Cocoa but Obj-C, or if you prefer elements of a OO-language in procedural FB. >To be realistic writing a new OOP runtime, based on Cocoa could take years. >Anyway, the first thing that we need is an OOP bridge to begin our path. IMHO, this is simply not true (see below), or you didn't get the point of my suggestion. >Now, with respect to BASIC this means to write a Runtime that calls >the required Cocoa-APIs that hide behind Standard BASIC calls >(keywords). Of course this won't result in our beloved open FB but >we shall see if it will be possible in the future to openly call >Cocoa APIs without becoming OO-coders. > >If the latter turns out impossible, I see no future of FB. In this >case, dear friends, I recommend to invest some months learning a >solid OO-language. > >I recommend it too, regardless of direction of FB. > >I'm unable to judge if such a _general_ bridge between the Cocoa API >and FB is feasible--in fact I doubt it--but there are others here >who seem to know more. > >I think that it's feasible but it requires a lot of time and knowledge. And of course you imply a considerable amount of Obj-C knowledge from FB-coders. >If my doubts turn out realistic, there won't be an open FB without >quite some knowledge of Obj-C, but at best a standard BASIC. > >Again, my still resting cents >-- > Herbie > > >In any case I agree about think small first. In my opinion this >would mean to make FBtoC ready to eat some OOP FB syntax just to >reach the goal of write some of the exixting Cocoa's example in FB. >This, in my opinion, is the basis of a new runtime. > >Michele. Somehow lost in translation -- Herbie ------------------------ <http://www.gluender.de>