Anyone Still Interested

#1 · January 11, 2010, 7:16 pm

Quote from Forum Archives on January 11, 2010, 7:16 pm
Posted by: maxclass <maxclass@...>
To All,

MaxNote: This ended up longer than I expected but then again I do tend to do that.

Haven't seen any posts so far this year and wondering where everyone is in Cocoa land.

Believe it or not but I just went back through and reread all the previous Cocoa posts to see if I had missed anything. Guess not, but I know there must still be some OOP interest out there.

Meanwhile I keep plugging along with updating MaxClass to run under Carbon Events and trying to mimic the "NS" class structures and inheritance chains. The "NS" classes stay pretty simple but have a lot of methods per class. I have also been trying, where ever possible, to switch to using Obj-C wording and class name conventions except mine all start with "Mx".

One of the things that stood out the most to me was the idea that it appeared to me that most do not understand one of the basic underpinnings of OOP. That is the idea of hiding the implementation behind methods.

After untold hours (really) going through the documentation on the "NS" classes the one thing that stands out is not just that they give you the methods and their parameters and any return values but that you end up not having a clue as to what is actually inside each of the methods or how they actually work internally. That is as it should be. They are hiding all that from you.

The main idea here in OOP land is if Apple suddenly switched from Cocoa to Beer they would simply modify the internals of each method, hiding it from you, but all of your existing code that used it would still work.

For instance, if I ask my "MxDate" class for the long date I always get it. How that information is arrived at should not be my concern, just that I get what I asked for. It should not matter if internally it uses Carbon calls, Cocoa calls or just use the FB calls. The syntax is not really that important either, just that I get what I ask for. It is not any different with Cocoa classes either as everything underneath is totally hidden from site. Just as most data structures in Cocoa are opaque so are the internal workings of the class methods involved. There is a reason it is that way and a good one at that. Example.

dim as MxObject dateObj // dim the date object

dateObj = fn MxNew ( @MxDate ) // make the date object

MxSend( _cmsgInit, "o", dateObj ) // Init the date object once

MxSend( _cmsgLongDateNoTime, "o", dateObj ) // send the message

print gMxDateStr // print out the long date string

Everything in the above code is basically opaque. Where is the method? What is the method that gets called? How does it work internally? How does the message get to the correct method of the correct class in the first place? Where does it get parsed?How do the parameters get to the correct final destination? The answer is, "It doesn't matter", just that it does.

Anyone can argue the syntax involved above (and probably will) but it doesn't break any basic FB rules. Anyone can understand what's happening, just not exactly how it happens and that is the bottom line here.

There is nothing here that can't be learned in three minutes or less and all without any OO, Obj-C special added syntax, modifications to the runtime, editor or FBtoC.

All of the actual code that gets the date above involves "CF" calls internally (thanks to Bernie here). If, sometime in the future things change then only the internals of any methods that require changing get changed and all of the above code will still work perfectly and opaquely.

That's all for now. Just some new thoughts for the new year.

Max Taylor

The MaxClass Guy
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]   

Posted by: maxclass <maxclass@...>

To All,

MaxNote: This ended up longer than I expected but then again I do tend to do that.

Haven't seen any posts so far this year and wondering where everyone is in Cocoa land.

Believe it or not but I just went back through and reread all the previous Cocoa posts to see if I had missed anything. Guess not, but I know there must still be some OOP interest out there.

Meanwhile I keep plugging along with updating MaxClass to run under Carbon Events and trying to mimic the "NS" class structures and inheritance chains. The "NS" classes stay pretty simple but have a lot of methods per class. I have also been trying, where ever possible, to switch to using Obj-C wording and class name conventions except mine all start with "Mx".

One of the things that stood out the most to me was the idea that it appeared to me that most do not understand one of the basic underpinnings of OOP. That is the idea of hiding the implementation behind methods.

After untold hours (really) going through the documentation on the "NS" classes the one thing that stands out is not just that they give you the methods and their parameters and any return values but that you end up not having a clue as to what is actually inside each of the methods or how they actually work internally. That is as it should be. They are hiding all that from you.

The main idea here in OOP land is if Apple suddenly switched from Cocoa to Beer they would simply modify the internals of each method, hiding it from you, but all of your existing code that used it would still work.

For instance, if I ask my "MxDate" class for the long date I always get it. How that information is arrived at should not be my concern, just that I get what I asked for. It should not matter if internally it uses Carbon calls, Cocoa calls or just use the FB calls. The syntax is not really that important either, just that I get what I ask for. It is not any different with Cocoa classes either as everything underneath is totally hidden from site. Just as most data structures in Cocoa are opaque so are the internal workings of the class methods involved. There is a reason it is that way and a good one at that. Example.

dim as MxObject dateObj // dim the date object

dateObj = fn MxNew ( @MxDate ) // make the date object

MxSend( _cmsgInit, "o", dateObj ) // Init the date object once

MxSend( _cmsgLongDateNoTime, "o", dateObj ) // send the message

print gMxDateStr // print out the long date string

Everything in the above code is basically opaque. Where is the method? What is the method that gets called? How does it work internally? How does the message get to the correct method of the correct class in the first place? Where does it get parsed?How do the parameters get to the correct final destination? The answer is, "It doesn't matter", just that it does.

Anyone can argue the syntax involved above (and probably will) but it doesn't break any basic FB rules. Anyone can understand what's happening, just not exactly how it happens and that is the bottom line here.

There is nothing here that can't be learned in three minutes or less and all without any OO, Obj-C special added syntax, modifications to the runtime, editor or FBtoC.

All of the actual code that gets the date above involves "CF" calls internally (thanks to Bernie here). If, sometime in the future things change then only the internals of any methods that require changing get changed and all of the above code will still work perfectly and opaquely.

That's all for now. Just some new thoughts for the new year.

Max Taylor

The MaxClass Guy

--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]