[futurebasic] Re: [FB] re: Carbon, Cocoa & Objective-C

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : February 2010 : Group Archive : Group : All Groups

From: Max Taylor <maxclass@...>
Date: Fri, 26 Feb 2010 17:03:58 -0800
On Feb 26, 2010, at 11:19 AM, Christopher Wyatt wrote:

> On Feb 26, 2010, at 4:48 AM, H. Gluender wrote:
> 
>> Max and Christopher,
>> 
>> Now why "alternatives to FB"?
>> 
>> That said, whatever OOP-flavor of BASIC you propose, it isn't especially attractive and regarding an OOP-FB, we saw repeated statements on this list that it won't happen.

I understand that and I think Chris does too.

Maybe we should begin some short simple lessons for those who would like to stay procedural but still use ObjectiveC with Xcode and IB.

Just because you use Xcode does not mean you have to use the Object side of ObjectiveC. It has a C side and an Object side. Use one or both, whatever your end results justifies.

> I prefer procedural code, including 4D's environment, to OOP for many things. I still find procedural code easier to debug and update, but maybe that's because I'm a dinosaur of the 70s and 80s. Heck, I think PowerBASIC is amazing and wish there were a Mac edition, but PB is locked to Windows for now. (Seriously, I do use PB in DOSbox and Parallels because it is so fast and easy.)PowerBASIC is what I would *try* to match. 
> 
> Don't confuse me with a fan of the OOP world.

People don't use OOP because they simple don't understand the thought process that goes along with it. Apple lays it out there free for us to use, but they aren't holding a gun to anyones head here. Once you grasp a few basic principles or thought patterns then the light comes on you go "WOW".

> I see no serious benefits to OOP, despite decades of claims we would see better and easier coding.

When we can create a working app that actually does something and never have to write a line of code then that's powerful. When we have access to hundreds of classes and thousands of methods (98.672% bug free) that will do almost anything we want and choose to turn away from all that built in power just because we don't like the way of accessing it [ myObject  canDoAlmostAnyThingAutomaticallyBuiltIn ] (boy, that was some tuff code) it just seems a little odd to not give it a try.

OOP is more a thought process than code writing. Anybody can write code but not everyone thinks in terms of classes and methods and looking at it in a different light. People have been posting code examples on the list for years and every year I see examples that do the same thing over and over again. This is just me here, but I take those examples, figure out what class of objects they relate to, create a class and/or turn them into methods in that class. Almost any function you can create could be a method in some class if one thinks about it.

Classes are nothing but groupings of actions (methods) that pertain to one particular class of subject . If you have15 functions that read and/or write all data from files, some data from files, one line from a file, etc., open files for input/output, etc., close files, etc. you probably would not scatter them throughout your code. No, you would probably create a file like "MyFileHandlers" and put all those functions in that file so you could include them in other projects.

That file is simply "Your" File Class and all the functions in that file are "Your" Methods. Without even thinking about it you have been using OOP-Think all these years and probably didn't even realize it.

No serious benefits?

What if you had refined your file code to the point where you never had to write another line of code to access any file data but could just include your file in a project and BAM, there it is. That is a benefit of OOP-Think.

What if you had five different files you access repeatedly during the coarse of an application? You create five different file objects and send the same messages to any of them and it automatically accesses the correct methods and work on the correct files automatically. That's OOP.

What if you had a special file need? Through Inheritance you can cover that need and automatically link up with your regular code (subclassing) and cover the special need and get full access to all the rest without having to modify the original code in any way, Yet all of the original file code still works exactly the way you expect it to.

No benefits? I think not. There is no down side, it's all benefits once you see how they can benefit you.

>  I'd like to stand in the way of Obj-C if I could… darn.

Nothing is standing in your way of standing in the way of ObjectiveC, but you would be the only one standing in your own way. I'm not down on anyone here, trust me, I just hate to see people rag on OOP when they don't really realize that it's not OOP they are ragging on, its only a way of thinking they haven't discovered yet. 

>  Obj-C is different, but once you learn the basics the real challenge is Cocoa, which is *not* the language, but the framework coded by Apple. Usually when people complain about Obj-C, they are complaining about Apple's Cocoa library.

You are right here. ObjectiveC is just a means to an end. Cocoa is the culprit here and the toughest part of the process with so many classes and methods. The advantages are that if we learn to use those classes and methods then any updates Apple adds to any of those methods we get for free and do not have to modify our code to get.

Hope this is taken in the spirit it is intended with no harm meant towards anyone. We are all in this boat together and just need to get it to shore safely.


Max Taylor
The MaxClass Guy