Retitled for  more better more clear inspirational calamity.

On Jan 3, 2011, at 2:34 AM, Robert Purves wrote:

>
> Robert Covington wrote:
>
>> Question: Can FBtoC as currently configured ( assuming Use  
>> Objective C Compiler is checked)  emit code and directions  
>> currently, either in bypass/passthrough mode or other, to build  
>> what would be recognized as a 'pure' Cocoa App?
>
> FB_5_4_8_Examples/Carbon in Cocoa/CocoaApp.fbproj
> It builds a genuine Cocoa app from FB code with no  
> BeginCDeclaration/BeginCFunction/EndC tricks.
>
> Robert P.

That's cool. Just saw that.

So:

Facts seem to be this:

FBtoC can already cause a Cocoa App to be emitted.

A while back in the list, I showed links and more that demonstrated,  
without the need for IB or Nibs that:

Cocoa windows can be created programmatically
Cocoa Menus can be created programmatically
Cocoa Controls can be created programmatically
Connections and such can be created programmatically
Selectors and such can vector messages to one's preferred  
destination, no?

We already know that C code works in Cocoa too.

I don't really understand why we can't have FBtoCocoa anymore. We  
wasted a good year listening to reasons why not every time it was  
brought up. But they were not even the best reasons, more like a  
description of symptoms of fear upon seeing the maw of a new  
CocoaMonster, in a  new lake where our gifted big fish suddenly were  
resized into smaller ones, who knew not what to do, as they had in  
the past.

Cocoa does that. To everyone, initially. Well pooey.

Makes for opportunities too.

Reasons given last year for no FBtoCocoa:

3) We'd have to rewrite our code.

Like I have to do one or two times more already?  Not a reason. We've  
had to do that every FB release of any stature.

2) We'd have to rewrite FBtoC to emit That Something Else.

So? We are programmers, not like it can't be done. It was done the  
first time, and yes it was a long haul,  but this time the result  
wouldn't be deprecated! If that is not a great reason to do it, I  
don't know what is. So, #2 is not a great reason. It is a tedious  
task to be sure, but it also -sure- could be done, using that bestest  
of approaches for any large task, baby steps.

1) We'd have to come up with some kind of Objective FB it was said.

Not that hard, even if that has to be done, and I am not sure it  
does, though it makes sense to go towards the future with some kind  
of Object.method syntax. And one was already done for us, but it got  
thrown out with the MaxClass baby-bathwater.

Perhaps MaxClass, creator willing, could be retooled and remapped on  
top of Cocoa output from FBtoC to become the new Objective FB, same  
as OS X was set on top of UNIX.

Win-Win....all that work there of Mr, Taylor's does not go to waste,  
and there's our new syntax. The task then is in remapping to Cocoa  
routines and any C needed.

Even if not a go as to that, such syntaxical worry is still not a  
reason for not doing something new because again, I am not even sure  
you can't fake a linear procedural FB something in Cocoa anyhow, with  
a little imagination.

So, I count no real reasons why it can't be done.

Let's do it.  Let's explore it. Instead of thinking up reasons why  
not, let's spend some time working on ways -we might could do it- :

Here's a quick step by step. Maybe there are better steps, but again,  
starting with baby steps means you get it going, and look instead at  
what you can do, instead of what you -think- you may not be able to.

1. Be able to compile Objective C program.

Done

2. Be able to intake new syntax FBtoC "Cocoa Window" statement, and  
output Cocoa/NSWhatever create window.

Make it so. Do it for one type first, then worry about the rest.  
Congrats. Do we now have a window that shows up in the Cocoa Window  
Menu?

3. Be able to intake usual Menu Statement, or if needed, "Cocoa Menu"  
statement to better interface to any existing raw materials nib if  
need be, and make it so.

Just be able to put up one that Quits the program, but made  
programmatically. And a choice to make another window. Congrats, we  
now have some menu power.

4. Be able to intake new "Cocoa Control" syntax, and output code for  
a Cocoa control, and make it so. NSControl?

5. Worry about routing messages to the proper handlers/functions/ 
methods, to emulate DoDialog in our Cocoa Something, and Make It So.  
This might need to be #10. Selectors, @implementations, why can't we  
make this so?

6. Add Mouse functionality. And Make it So.

7. Add some basic Graphics functionality, and Make It So (Plot for  
starters, draw a line via the mouse), and upgrade the syntax where  
needed.

8. Add some Printing Functionality, to print a window and it's  
contents...and Make It So.

9. Add some basic Array functionality, and Make It So, to store the  
mouse points. Or any kind of whatever, but store something, and be  
able to access it, change it, delete it. NSArray? Mutable, non, add  
any new syntax needed.

10. Worry about the rest (vars, vartypes, etc) and more in Cocoa  
Land. We already have the C stuff set up...no?  So only need to add  
any additional Cocoa vartypes, etc. If collision between the current  
is likely, then Fork It, and make the new thing output The New Way  
Only, where vars are all typed to C and Cocoa monster types.

Now a lot of these are a 'couple weeks' or more steps, but many are  
not , and generally, it's a "written once, done for everybody" thing.

One can come up with their own 10 Steps, or a more defined 20 step or  
more step program, but it's a do-able.  How about we think how we can  
do it, and how any obstacles can be worked around, instead of making  
them reasons why not to do it at all?

:)

FBtoCocoa, We Can Make It So.

r
c