Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×

Exploring the Mac OS X Object System 60

Posted by Hemos from the a-deep-look-into-it dept.
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."
This discussion has been archived. No new comments can be posted.

Exploring the Mac OS X Object System More

Exploring the Mac OS X Object System

Comments Filter:

  • PyObjC? (Score:5, Informative)

    by Fiznarp ( 233 ) on Monday June 26, 2006 @11:19AM (#15605723)
    I've seen Cocoa scripted with PyObjC [apple.com] and python Cocoa bindings.

    Apple currently employs one of the maintainers of PyObjC.

    Would someone informed care to explain if/when F-Script would be a better choice?
    • That was my first (and last) impression too. F-Script looks like it has a nice object browser, but why didn't they write it in Python and have all the hard work done for them?

      • Re:PyObjC? (Score:5, Informative)

        by Anonymous Coward on Monday June 26, 2006 @12:59PM (#15606547)
        F-Script can be attached to a running application. F-Script has been around since NextStep and before Python existed. Any other questions?
        • Python can also be attached to a running application, including one not designed to have Python attached to it.

          I didn't know F-Script has been around that long. Interesting.

          • Re:PyObjC? (Score:3, Interesting)

            by Bastian ( 66383 )
            F-Script can also be plugged into an app that wasn't designed to have it attached. From what I understand, PyInjector was created by following in the footsteps of FScriptAnywhere.

    • Re:PyObjC? (Score:3, Informative)

      by timmy_mc ( 985097 )
      F-script enables you to send messages to entire collections of objects at the same time. i.e. "> ArrayOfThings value" fires a value message to the array causing each object within the array responds to the message however it see's fit. When you get collections of arrays of objects takking to each other clever things can happen... http://www.fscript.org/documentation/OOPAL.pdf [fscript.org] tim
    • Woo! Nice! I didn't know about that.

    • Re:PyObjC? (Score:1, Interesting)

      by Anonymous Coward
      PyObjC is great for Python programmers who want to access Objective-C libraries. However, as a native scripting language for Objective-C/Cocoa, it is not optimal. First, you have two different object models to deal with (Python and Objective-C), which introduces some impedance mismatch and complexity. Second, the Python syntax for invoking methods does not fit well with Objective-C's keyword syntax for methods.

    • Re: (Score:3, Insightful)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

    • Re:PyObjC? (Score:5, Informative)

      by Bastian ( 66383 ) on Monday June 26, 2006 @03:53PM (#15608014)
      I've been using F-Script for a while now; it's solid, it plays very nicely with Cocoa, and includes a lot of nice time-saving syntactic sugar. Its syntax is also simple enough that I can use it for an application scripting language that users can pick up in a few minutes. The F-Script pallette for IB is also rather convenient; it means I can throw a debugging (or scripting) console into any app of mine with almost zero effort.

      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)

        by account_deleted ( 4530225 ) on Monday June 26, 2006 @05:20PM (#15608711)
        Comment removed based on user account deletion

        • Re:PyObjC? (Score:5, Interesting)

          by Bastian ( 66383 ) on Monday June 26, 2006 @10:15PM (#15610210)
          Right, which is a huge advantage of F-Script over what I've seen of PyObjC. The only major difference between passing a message in F-Script and passing one in ObjC is that I use parentheses instead of square brackets. PyObjC has to go through some rather unnatural contortions in order to do the same, and it kind of made the code hurt my eyes a little bit, and I could see where it could make reading others' code a bit confusing.

          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)

      by Anonymous Coward
      Nothing beats F-Script when it comes to exploring objects interactively. PyObjC does not have the kind of graphical tools shown in this article. My favorite feature is F-Script Anywhere, a tool for injecting F-Script into running applications.

  • How many? (Score:5, Interesting)

    by andrewman327 ( 635952 ) on Monday June 26, 2006 @11:21AM (#15605740) Homepage Journal
    I was wondering how many Mac-specific development platforms are out there. Obviously there are loads of them for Windows, but how many just for Mac?

    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)

      by ceoyoyo ( 59147 )
      Take a look at Python and PyObjC. http://pyobjc.sourceforge.net/ [sourceforge.net]
    • Do you mean APIs and SDKs like Quicktime, CoreAudio, .Mac, etc..., or something else? Regardless, coding Mac apps in Java is usually fine considering how well Apple ties Java into everything.
      Regards,
      Steve

      • Re:How many? (Score:3, Informative)

        by sqlrob ( 173498 )
        Hasn't apple stated that they aren't adding any of the new APIs to java?

        • Re:How many? (Score:4, Informative)

          by JulesLt ( 909417 ) on Monday June 26, 2006 @04:54PM (#15608492)
          Yes - due to lack of interest they have ceased development of the Java-Cocoa bridge. Of course I am sure that if there was a lot of interest, that decision would be reversed.

          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.
          • On top of that, the biggest objective benefit of developing Cocoa apps in Java was taken away with the addition of a garbage collector to the Objective-C runtime.

            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.
        • Just to clarify: Apple said they will not add new APIs to the Cocoa-Java Bridge. They will still support 100% Pure Java with the JRE, ongoing.

    • Re:How many? (Score:5, Informative)

      by quadelirus ( 694946 ) on Monday June 26, 2006 @01:06PM (#15606609)
      If you mean development frameworks then Cocoa is the way to go. Carbon is older and mostly included for backwards compatibility. Cocoa is the new hotness. As far as IDE's go, I use XCode2 and InterfaceBuilder. They are easy to use once you know where things are. I wish they had some sort of tabbed editor and I would reccomend dual monitors while developing due to the number of windows you will have open, but other than that it is a great product.

      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.

      • Tabbed editor (Score:4, Informative)

        by Jord ( 547813 ) on Monday June 26, 2006 @02:02PM (#15607060)
        Just an FYI, you can get the same functionality as a tabbed editor in XCode by setting the editor to use only one window. Double click on a file in XCode, then on the right side of the toolbar is a button which will change the editor mode and open all of the editors in one window. Then you can use Control-1 to switch between editors.

        Not sure if you were aware of that feature.

      • Cocoa MVS bindings (Score:3, Informative)

        by Fnord666 ( 889225 )

        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.

        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)

        by Cygfrydd ( 957180 )
        Java-Cocoa... this would be... mocha?

      • Re:How many? (Score:3, Informative)

        by aledwards20 ( 985127 )
        "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."
        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]; //or any other object
        [my
        • I figured there must be a way to do it but I didn't know how, thank you. When I started out in Cocoa programming all tutorials and books typically had you connecting things like that in the interface builder. Do you think programming graphically or by hand is better when dealing with Cocoa?
          • With Cocoa, I strongly encourage using Interface Builder especially if you are learning. I typically only use Interface builder to build my UI so it retains the Aqua look and feel and make the GUI easier to maintain. You could do it all by hand if you wanted to, and there isn't any thing wrong with that. I have mixed using NIB with coding portions of the UI by hand and it works fine (personal projects). I haven't done a complete UI in code yet because you miss some of the benefits of Interface Builder and N
      • Apple has a good tutorial [apple.com] on their site for those who want to jump right in and figure it all out. I think you can do this with Java/Cocoa just by selecting Java as your project instead of ObjC.

        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.
      • Comment removed based on user account deletion

      • 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)

      by JulesLt ( 909417 )
      The main and obvious one is Cocoa. While NextStep was available on many platforms and GnuStep continues to be, Cocoa has advanced a long way since. For all practical purposes, Objective-C is pretty much a 'Mac-only' language.

      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)

    by Gattman01 ( 957859 ) on Monday June 26, 2006 @11:23AM (#15605764)
    ...is the trash can?

    Or is that Vista I'm thinking of?

  • Looks nice... (Score:2, Flamebait)

    by Ant P. ( 974313 )
    ...but is giving everything access to everything else in this way safe?

    • Re:Looks nice... (Score:1, Interesting)

      by Anonymous Coward
      That's was a pretty vague question, so I can only give a vague answer. In general Objective-C will favor power and flexibility over "security", and no classes or methods are truly private.
    • It's safe in one way - you can say "F-script" on TV without getting fined by the FCC.

  • Live Testing is Where F-Script Really Shines (Score:3, Interesting)

    by krisamico ( 452786 ) on Monday June 26, 2006 @04:21PM (#15608236)
    I have used F-Script to write tests for my applications for quite some time. In fact, pretty much everything I write has an F-Script console built into it when DEBUG is on. Naturally, OCUnit is nice for built-in unit test, but I really like being able to write an impromptu test into the F-Script console real quick to exercise some newly written or changed code. My clients often do not give me much time for writing enough built-in tests, so F-Script helps me pick up the slack with convenient, live testing. On the bad side, with F-Script, you are relegated to writing non-portable tests with odd, SmallTalky syntax, but for me it is an acceptable compromise for such a good, free (as in beer), on-the-fly testing tool. I don't remember having thanked Philippe for making it available. Thanks, Philippe!
    • That's how I tend to do all of my testing, too. When I started combining an F-Script console with the "Fix" button, debugging became almost fun. I can just keep poking and prodding at a bug until I pin it down without having to worry nearly so much about continually dragging the program back to the conditions where the bug came out or any of that, because I can bang out an F-Script block that does that on the fly for me, and then tweak it as needed without ever having to restart the program.
  • The article seems to be more about exploring class libraries, not "the object system" (which would mean low-level analysis of how methods are invoked etc.).

    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).

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close