I want to build a plugin for an application(TeamSpeak), however I have no lua knowledge. Is it possible to somehow wrap or bridge my Obj-C knowledge to lua?
If needed I could learn the basic syntax of lua to get my plugin started, but ultimately I want the meat of the program in Obj-C.
Any advice appreciated!
Lua's api written in c so rather than going from obj-c to Lua, you will have to go from obj-c to c to Lua. This is not as bad as it sounds though, obj-c and c play well together so you can have functions to expose to Lua in your .m source files and/or use .c source files in your project. As far as I know there isn't a luabind type library for obj-c but if you are using c++ with your obj-c this may also be an option.
Once you get past the stack manipulation, you will probably find the api pretty intuitive. The c api for tables can be a little confusing at first but it is also extremely powerful and allows you to expose your application's functions in many interesting ways.
Lua is a fairly simple, yet extremely powerful language. For example, there is only one datastructure: tables. Unless you are trying to do complex things with metatables you can probably dive right in with little trouble coming from Objective C. Do note that array indices (i.e. tables with sequential numerical keys) are 1-based instead of 0-based. Take a look at Programming in Lua (PiL) to get started.
Search for iPhone Wax on Google. Might not be what you need, but might help your needs. It lets you call Obj-C via Lua.
Related
I am new to Mac/iOS development. I am coming over from C# .net. My question is should I read on Objective-C first or Cocoa? I don't want to buy two books and start reading one and find out I should have only got one book and read it.
Thanks
Curtis
Seeing as how the Cocoa frameworks were built with Objective-C, learning the language is the logical first step.
You don't need to become fluent in the language, to the point of exchanging implementations and dispatching blocks like nobody's business, all before you learn the frameworks. Indeed, such an undertaking would be folly.
At the same time, you can't learn Cocoa without a firm grasp of OOP, dynamic dispatch (messaging), MVC, and other important concepts. Some of these underlie Objective-C, some are part of Objective-C, and some are separate from Objective-C.
I say start learning those concepts, including the basic portions of the language, and then pick up the framework before you get too far into it. Like Regexident said in their comment on one of the other answers, you pretty much can't practice Objective-C without using Cocoa anyway, so it won't be long before you need to start into the framework to in order to practice the language—at which point you'll be practicing with both.
Relevant Apple documentation:
Object-Oriented Programming with Objective-C
Learning Objective-C: A Primer
Cocoa Fundamentals Guide
The (full, gory details of the) Objective-C Programming Language
If you don't already know C, start there. As with Objective-C, you don't need to become a full-blown C guru, but you do need to understand pointers, declarations vs. statements, how function calls work, the differences between the primitive types, and other basic concepts.
Objective-C is just a superset of C. All the Cocoa books that I've seen introduce Objective-C in the first part and then go on to describe how to use the frameworks. I'd recommend just getting a Cocoa book, just leaf through it and make sure the Objective-C primer in it is meaty enough for you.
I believe there is a lot of good information in the various answers here (especially #Peter Hosey's), but I do want to make sure we're not confusing the OP.
You can't practically learn ObjC without learning Cocoa today. It's like learning C# without learning .NET. You absolutely should focus very early on the patterns and underlying concepts of Cocoa (like MVC, as PH notes). But you'll get that best by working through things that teach you practical iOS or Mac development techniques rather than working through something that tries to provide a more "pure ObjC" experience such as writing command-line apps (though even Foundation is part of Cocoa, so even then you can't escape it).
The key lesson here is that I recommend new students focus on resources that teach them the whole process they need to develop for iOS or OS X. It's worth learning Xcode, ObjC, and Cocoa(Touch) together, along with MVC, target/selector, and the other critical patterns, rather than trying to take them one at a time.
PH is absolutely correct that you don't need to learn all of ObjC in one go. You can do a lot of development and never use blocks or KVO for instance. (That may change in future versions of iOS, but it's still true today.)
i wanted to write a web crawler library for Objective-C ! but there is a library available for C language !
since we can compile C codes in our Objective-C projects in Xcode ! is there any reasonable purpose that we write a new library for Objective-C with itself syntax?
any performance ? or any reason ?
thanks
Sure; lots of reasons.
The primary reason is if you want to hook the web crawler into an Objective-C application. For example, you might want to crawl the web and store results in Core Data for later local retrieval. Writing an Objective-C API makes it that much easier.
Wrapping a C based API in Objective-C is very easy, too. It is quite common to wrap C API in Objecitve-C to make the C based API that much easier to work with. OO patterns naturally encapsulate the notion of "session" or "context" that are typically represented by awkwardly managed manual malloc()d structures in C; those structures typically fit naturally into an Objective-C class.
I believe the question speaks for itself, and I know that to many of you this question might seem retarded. I just wonder if everything, in Objective-C, that starts with Core is written in a plain C.
My guess is "Yes, it is.", but I want to be sure for 100% ;)
Many thanks.
EDIT: Looking at the answers I now realise I should have asked about the syntax in Core libraries.
Is it always C like syntax: void myFunction(int num); and not - (void) myFunction:(int) path;?
So far one thing that I am not too fond of, in Obj-C, is mixing ()/dot/-> syntax with [] syntax. I think it really isn't elegant...
No offense, but the proper answer is "who cares"? (insert tongue in cheek)
Honestly, though, any system libraries can be written in pretty much whatever they want. There's probably a combination of Objective-C, C, C++, and assembler; less likely (but technically still possible) options include Pascal, Fortran, LOGO, or hand-assembled machine code.
If you want an example of the combinations of code in system libraries, take a look at the open-sourced Java libraries. You will see that the java.* packages are written in a combination of Java and C; some ports may include assembly for parts.
As long as the interface is Objective-C compatible, that's all you really need to worry about.
Also, the only people who can answer that are probably at Apple, and probably aren't allowed to tell you.
It's written in "whatever" (a bit of ObjC, a lot of C, a bit of asm), but the key thing is that the interface it presents is pure C.
I'll note that Core Data and Core Image present ObjC interfaces though.
Yep it is - Appkit / UIKit is built on top of that, and they've done some tricks to make the interaction between ObjC and Core* to be very efficient (called "Toll-free Bridging")
It is Objective-C after all; the language is a very small layer of syntax on top of straight C with a runtime library to provide the dynamic behaviors.
Mixing C and Objective-C is a very oft encountered and natural part of the environment.
As others have said, the languages used to implement the various Core* frameworks is an implementation detail that should generally be of no concern. With that said, a good sized and growing chunk of CoreFoundation is written in Objective-C.
I've been doing iPhone development full-time over the last couple of months.
Having previous experience only in OOP, I've relied heavily on Apple's APIs, which eventhough majestic I must reckon, led me to write code that in retrospective looks like a weird mix of ruby/smalltalk with added boilerplate.
So I'm thinking I'm missing out, and ordering K&R. Yet I wonder how what I'll learn, can specifically be put to good use in iOS work, without fighting against the devices' API and the whole OO pardadigm ?
The lower level APIs are largley in straight C, perhaps you'd like to explore them? For example Quartz 2D has a C API.
Objective-C is a superset of C. You can intermingle Objective-C and C function calls, statements, etc.
So for example, if you prefer Posix sockets to NSSocketPort, you can just mix in the C socket functions wherever you want. Or, if you wanted to keep it a little more object oriented, you could wrap C statements in an Objective-C function call that would isolate your C code from the rest of your Objective-C code.
Something that might help you understand the relationship between C and Objective-C would be to create an Objective-C wrapper for some C code. I’d recommend writing a simple iPhone app scripted in Lua. That should be enough of a project to really look at the C.
Not learning C is not missing out on anything.
I almost agree with #jeff except that I don't see why so many beginning Objective C programmers go straight for the iPhone stuff when they could be running a Mac app with much less hassle and convert it later.
But yes, buying a copy of K&R would be a very good idea (as well as getting a copy of the C90 or C99 standards, if you can afford them). In fact, I have a book on iOS games that suggests going straight to vanilla C for a lot of the low-level stuff to cut out the messaging overhead for performance's sake. Essentially, you're not doing anything you're not "supposed" to do by using C functions; the C library is still there to be used, so you aren't doing anything particularly strange or kludgy.
I've become very comfortable in the world of pointer-free, garbage-collected programming languages. Now I have to write a small Mac component. I've been learning Objective-C, but as I confront the possibility of dangling pointers and the need to manage retain counts, I feel disheartened.
I know that Objective-C now has garbage collection but this only works with Leopard. My component must work with Tiger, too.
I need to access some Cocoa libraries not available to Java, so that rules out my usual weapon of choice.
What are my alternatives? Especially with no explicit pointers and automatic garbage collection.
What do you mean by "component?" Do you mean a chunk of code or a library you are going to hand to other people to link into their apps? If so then it is not realistic to use any of the bridged languages at this time. While a lot of the bridges are very nice, they almost always have complications and issues that most app developers will not be willing to deal with to use a single component, especially if it involves bringing in a substantial runtime.
The bridges are most valuable to bridge other language libraries into your Objective C app. While you can write fairly complete apps using them, doing so often requires a better understanding of Objective C than simply writing an Objective C application, since you need to understand and cope with the language, object model, threading, and memory allocation impedance mismatches that occur.
This is also why many people argue that even if you are quite familiar with a language, trying to learn Cocoa using that language through a bridge is generally more difficult that learning it using Objective C.
Finally, much of the recent support for bridged languages was due to "BridgeSupport," a feature was added in Leopard. Even bridges that predate that have been migrating towards, sometimes in such a way that using the bridged language on Tiger and Leopard can have substantial differences. Also, there is currently no bridge support for iPhone, and most bridged languages will not work on it, if that is an issue.
Ultimately, if you are writing a library that is going to be linked into other apps, you need to run on Tiger and Leopard, and you need to access Cocoa only APIs I think you will find using any non-Objective C solution quite difficult.
You can try PyObjC to write Cocoa apps in python, or MacRuby if you are interested in Ruby.
You shouldn't be intimidated by Cocoa's retain/release reference counting. It's much, much easier in practice than GC fans would have you believe. The Cocoa memory management rules are dead simple, they only affect a tiny amount of your code, and even that code can be generated automagically.
Here's the trick. You encapsulate your MM code in accessor methods, and always use accessors. Xcode has built-in scripts to generate the appropriate accessors, or if you need more flexibility there are 3rd-part apps like Accessorizer.
This isn't an intrusive approach - you only need to worry about retaining an object if you're going to need to keep it for later use, and if you're going to do that you'll need an instance variable in which to keep it anyway. And, if you're using KVO and bindings, you'll need to use accessors to make sure the appropriate observer notifications are fired. Basically, if you're using good OOP and Cocoa practices, there's practically no additional thought or effort involved with memory management.
Most folks who have difficulty with Cocoa's "manual" memory management are doing so as a result of misusing it. The most common mistake is to scatter the relevant code all over the place. That means that a missing retain, extra release, etc will be difficult to find.
Try any of the Cocoa bridges listed in here http://www.cocoadev.com/index.pl?CocoaBridges
You can also try F-Script - a smalltalk dialect that is written specifically for MacOSX/Cocoa.
RubyCocoa is getting steadily more impressive, and I've seen lots of successful implementations using it. That is, of course, if Ruby's your cup of tea...
You can always use REALbasic (www.realsoftware.com). Real easy and fun to use, not free though. You can not make dylibs (or dll's) using it, but you can use dylibs and dll's in your code. And you can use cocoa libraries as well
Don't forget that you can use java as well, and i don't mean java-cocoa bridge, i mean actual java.
There's also a package from apple that provides you with access to a couple of osx features as well.
Also to comment on Shem's point, if your targeting osx 10.5 and above, you can take advantage of garbage collection.
If you want lisp syntax then Nu is a lisp implemented on top of Objective-C http://www.programming.nu/
Also, FreePascal can generate native Carbon Apps (in progress working for Coccoa)
Look at Python and wxPython (the wxWidgets in Python).
The wxWidgets have a very elegant App-Doc-View application design pattern that's very, very nice. It's not used enough, IMO. I haven't found any wxPython examples of this App-Doc-View example, so you have to use the C examples to reason out how it would work in Python.
I'd post examples, but I haven't got it all working yet, either.
.NET via Mono mono-project.com
See NObjective (http://code.google.com/p/objcmapper/) bridge to Cocoa. It provides more features than others with less overheads.
I'm looking into Mono too. Objective-C is a little too bizarre for me at this point. Too many years doing C/C++, Java, C#, Perl etc. I suppose. All these seem pretty easy to float between. Not so for Objective-C. Love my Mac but afraid it will take too much precious time to master the language.