Exploring the Mac OS X Object System 60
Philippe writes "F-Script is an integrated set of tools that makes it possible to interactively explore and manipulate Cocoa objects as well as script them using new high-level programming techniques. This new article, Exploring Cocoa with F-Script, shows you how to use some of its most impressive features and demonstrates how it can be a useful addition to your developer toolkit."
PyObjC? (Score:5, Informative)
Apple currently employs one of the maintainers of PyObjC.
Would someone informed care to explain if/when F-Script would be a better choice?
Re:PyObjC? (Score:1)
Re:PyObjC? (Score:5, Informative)
Re:PyObjC? (Score:2)
I didn't know F-Script has been around that long. Interesting.
Re:PyObjC? (Score:3, Interesting)
Re:PyObjC? (Score:3, Informative)
Re:PyObjC? (Score:1)
Re:PyObjC? (Score:1, Interesting)
Re: (Score:3, Insightful)
Re:PyObjC? (Score:5, Informative)
I don't really care if an Apple employee is working on one but not the other; F-Script is mature enough that it's not like I need to be afraid that the project will be orphaned before it's completed or anything like that. Nor do I care if Apple has blessed PyObjC or not. Apple also put scads of time and money into what I had always heard was a rather hacked Cocoa-Java bridge, only to essentially orphan it a year ago. And dare I mention AppleScript?
I haven't tried PyObjC, so I can't tell you if F-Script is a better choice or not, all I know is that it's a good choice. So I'll turn the question around - what makes PyObjC a better choice?
Comment removed (Score:4, Informative)
Re:PyObjC? (Score:5, Interesting)
I'm also wondering, does PyObjC have "tab completion" for code the way the built-in F-Script console does? I've gotten really used to that in XCode; Python would have to be a damn sight better than F-Script for the switch to it to accelerate my coding more than the loss of Code Sense-style symbol completion would slow it down.
Re:PyObjC? (Score:1, Interesting)
Cringely? (Score:5, Funny)
Is that you?
Re: (Score:3, Insightful)
How many? (Score:5, Interesting)
As much as this will get me flamed, I code in Java when I am writing applications for Mac. I find it works well enough, but I am interested in becoming a bit more versitile.
Re:How many? (Score:3, Informative)
Re:How many? (Score:1)
Regards,
Steve
Re:How many? (Score:3, Informative)
Re:How many? (Score:4, Informative)
Where people have interest in particular technologies you'll certainly see JNI libraries appearing, but most Java development on the Mac is cross-platform so didn't use the Cocoa bridge. I would imagine that building on top of the Eclipse RCP will be a popular means for many Java developers to get a closer native feel.
Re:How many? (Score:2)
I suppose there's still the benefit of allowing people who already know Java to work with a familiar language, but of course OS X also provides Java developers with a set of APIs that should be much more familiar than Cocoa. In a sense, the Cocoa-Java bridge was always a solution in need of a problem.
Re:How many? (Score:1)
Re:How many? (Score:5, Informative)
A couple of notes:
I, like you, come from a Java background and have recently begun to write native Mac apps. I use XCode and InterfaceBuilder and they work together really well to write Cocoa apps very quickly. I decided to learn Objective-C because for some reason I thought it would be idea to know yet another language, but Java-Cocoa should work just as well.
I'm not sure if this is the same for Java-Cocoa, but in Objective-C/Cocoa the hardest thing for me to get used to was the graphical nature of the programming. In many languages you have API's that allow you to do things like Hello World programs and/or more complex programs like a simple browser without writing a line of code. You design the interface graphically and hit run and it works. The difference between most of those (for isntance JBuilder) and Cocoa development is that in JBuilder, even if you don't physically write the interface code, it gets coded to your class file as standard Java code. In cocoa this isn't the case. The interface is housed in a file called a NIB file. Your average programmer will probably not ever have to look directly at the contents of a NIB. Also connections between classes is created graphically. For instance, if you want to have a button do something when it is clicked you don't add an onclick listener anywhere in the code. Instead you have a special type of method in your controller class that handles actions and then in interface builder you control click on the button and drag it to the instance of your class and tell it to connect to the action. AFAIK, this MUST be done graphically. It can't be coded. Or at least, it is strongly discouraged. This graphical nature took me quite awhile to get used to.
Bzzt. Wrong. (Score:5, Informative)
In that regard, Carbon is meant to run on other platforms only if you consider OS9 another platform. I think you are thinking that Objective C is somehow a bastardized version of C. It's not; Objective C is the full C language with additional object-oriented components a la C++, but not to the extreme that C++ takes it. Plus, Objective C gives you run time typing, which C++ does not provide (static, compile-time typing). This makes it very easy to get information about objects and is the basis of the key-value system that runs most of Cocoa. Objective C is inspired by Smalltalk and uses a number of its concepts whilst C++ was influenced heavily on Simula2 (I'm pretty sure). Regardless, both can call strncpy(), malloc() etc. if you want.
If you want write truly cross-platform C, you write to the standard C API *only* and let the users get their input and output via stdin and stdout. Not very graphical, but hey, you want cross platform, right?
Re:Bzzt. Wrong. (Score:3, Interesting)
Re:Bzzt. Wrong. (Score:1, Troll)
You're new to unix arn't you? He could use many of the X windows libraries that use a C API
which will then run on (probably) all versions of unix. Apple include an X windows layer
if you wish to use it instead of their wierd home-brew GUI system and Objective-C language
which no one apart from
Tabbed editor (Score:4, Informative)
Not sure if you were aware of that feature.
Cocoa MVS bindings (Score:3, Informative)
InterfaceBuilder makes the bindings in the MVC architecture for you when you connect them graphically. Once you get the hang of which object creates the event and which object should receive it then this becomes very straightforward. That being said, you can code by hand if you wish. I don't have the reference on me, but I believe the Hillegass b
Re:How many? (Score:3, Funny)
Re:How many? (Score:1)
Re:How many? (Score:3, Informative)
This can be done through code. use the setAction:(SEL)aSelector and setTarget:(id)target methods. setTarget tells the button which object to talk to setAction tells the button what you want to say to the object.
ex:
defined in header
IBOutlet NSButton *myButton;
in some function in source file
[myButton setTarget: self];
[my
Re:How many? (Score:1)
Re:How many? (Score:1)
Re:How many? (Score:2)
I actually did this in ObjC and it all worked fine, then tried to go back and make it Java... and it was kind of odd how it worked with Java I thought. It seems for this kind of programming model and IDE, that Objective C is better suited.
Re: (Score:1)
Re:How many? (Score:1)
Carbon is older and mostly included for backwards compatibility. Cocoa is the new hotness.
Just to clarify, Cocoa is not newer than Carbon. It was created for Mac OS X 1.0 as a way for traditional Toolbox applications (i.e. MacOS Classic apps) to be compiled to run natively in Mac OS X. Cocoa, however, is simply a new name for the API that NeXT computers used from 1985. Don't get me wrong. Cocoa is the new hotness, just because it's the first-class API for Mac OS X, getting the most love and care from
Re:How many? (Score:3, Informative)
Others that spring to mind
WebObjects - was cross-platform for a while, and in a weird way still is (the run-time was C++, now Java, but the only way to get a licence is with OS X server, and the development tools are now Mac specific). Front-ends can be Java or Browser clients.
OSA - t
First object to check out... (Score:3, Funny)
Or is that Vista I'm thinking of?
Re:First object to check out... (Score:4, Funny)
Re:First object to check out... (Score:1)
If people other then Microsoft don't start doing the same thing, there won't be any 0's left for our great-grandchildren.
Won't someone please think of the children?
Re:First object to check out... (Score:1)
Man, I'm sad...
Looks nice... (Score:2, Flamebait)
Re:Looks nice... (Score:1, Interesting)
Re:Looks nice... (Score:2, Funny)
Live Testing is Where F-Script Really Shines (Score:3, Interesting)
Re:Live Testing is Where F-Script Really Shines (Score:2)
misleading (Score:2)
Furthermore, there is little that is OS X specific about either the class libraries or the object system: the object system comes from Smalltalk, via Stepstone, and the class libraries come from NeXT and borrow heavily from Smalltalk and also exist in GNUStep (and, yes, people are working on porting FScript to GNUStep).