Just tossing a query out to see if anyone out there has ever worked on, seen, or heard of a MUD being developed in the Objective C language.

I recently got an iphone, and so of course I'm looking into writing applets for it. I'm stonewalled at the moment, since Apple only released their development kits for OSX, and specifically 10.5 on intel-based macs. However! I know development there is done in Objective C, so I figured step 1 is to putter around with the language and see how it ticks.

To that end, I went searching and only came up with one dead-end on SourceForge (no files released).

So, if nobody else has anything, I'll probably look at porting our good friend SocketMUD to it, but I'd rather see how someone who actually knows the language would do it.

I'll post if I find (or write) anything useful!

I only know the language academically, so I'm probably not that much help here. Frankly, except for iPhone development learning value, I'm not really sure I see the point in writing MUD code in ObjC… :tongue:

Yep, that's mostly it. Although Objective C isn't a bad choice either. It supports dynamic typing, which C++ still doesn't unless you use the BOOST library, and it is supposed to be a strict superset of C, meaning you could (in theory) rename all your .c files to .m files and gcc would still spit out a proper executable. I haven't tested that, but that's what the fanboi's say. :)

I do like the idea of incorporating some of the smalltalk features though. Being able to iterate over a set of objects and try to call a method (via message passing), and have the ones who don't understand it just ignore it (or pass it along to other objects), rather than throwing exceptions, sounds like a great enviornment for game development.

If I wanted features like those (which I do) I would just use a more modern language (take your pick of Ruby, Python, Lua, Scala, …) instead of ObjC. Being a strict superset of C is kind of nice but not really a killer feature for me.

Also I think that there is something to be argued w.r.t. just how nice it really is to work in a "typeless" environment. It's nice in the small scale, but trying to extend it to large systems can be 'interesting'…

David is right about "typeless" environments. All of the extensions I'm doing in TeensyMud(Ruby) are becoming harder and harder to maintain without running into bugs due to that. The large scale projects like adding a GUI frontend for Teensy is being a paaaaain.

Objective C isn't typeless though… it's dynamically typed. Being a super-set of C, it can't be typeless. I take that to mean you can create types which are bound at run-time, but you still have to manage conversions (IE: no magical it-sorta-looks-like-a-number logic).

I've done enough work with large systems in perl to have developed a dislike for memory management in C, but also a dislike for the sort of squishy typing that perl has.

Dynamic typing is kind of what I was referring to, although it's unclear what exactly is meant by types when everything is "duck typed". I want the compiler to be able to tell me at compile time whether or not I'm screwing up. Usually, when I don't want it bothering me, I'm in the middle of prototyping something "quick 'n dirty" – when I'm doing something seriously, I want those checks etc.

The only one I have ever come across is called Cheezmud. I've uploaded it to the repository here.

Thanks for the heads up Orrin, I'll take a peek at it.

This is how Objective-C defines dynamic typing. It's not duck typing, because you can't just use the string "3.14" as a float, but it does allow you to write methods that don't have to specify the type of their arguments and write code in them to figure out what they are. Since you have have objects which take arbitrary types, you can also have collections which accept mixed types. It also sounds like you can nail the type info down to have errors thrown if the wrong type of message is passed.

What's described there allows duck typing, but of course duck typing only works on things that actually know how to accept messages (so if the string "3.14" isn't a full object, it wouldn't implement this message handling anyhow). If an object can at runtime decide what to do with any message, it can implement duck typing for various types. This is more than simply not specifying types yet having static types. In this sense, "type" is defined more theoretically: an object's type or interface is the set of messages that it knows how to handle.

I guess the distinction I'm trying to make is that the language doesn't automatically provide conversions for you, and it does give you the option of restricting the types of messages accepted at compile time. Most of the newer dynamic language DO provide automatic type conversion, and in many cases there isn't any easy way to prevent it. Some newer language also allow you to provide type hints, which can be caught at compile time (assuming they are compiled languages), but some also allow you to later ignore them. I'm thinking Perl here.

If I write a method and restrict the parameter to be of type integer, the compiler will flag any attempt to pass it anything not specifically known to be an integer (acting like a static type). If I don't make that limit, but don't implement anything beyond the integer type, it will become a runtime exception. If I handle it myself and either accept or pass the message to someone else, it becomes fully duck typing.

Still, you're right in that this isn't the best language to chose for MUD development. If I were going to start one from scratch, I'd probably pick ruby or lua at this moment. But, it's still interesting to see how it works. If things had gone a little different in the early 90's, Objective-C might have become what C++ is now. There's even an Objective-C++ out there. :)

To my knowledge there isn't any language that really manages to combine duck typing with type restrictions. C++0x and it's concept maps for templates comes close, but not close enough.

The general idea of duck typing is that if a type implements the methods/messages you want, it doesn't matter if it derives from any specific type. The problem happens when the type doesn't actually implement the methods/messages – the errors end up being run-time errors, possibly in parts of the code far away from the code that passed in the wrong type. Total pain. What would be fantastic is a way for methods to check that the value passed in fits some mandatory profile, but without requiring interfaces to be created and inherited from all over the place.

One way I've been experimenting with is to use fallbacks on missing methods. Newer versions of JavaScript, for example, allow you to call Array methods using either the value.method(params) syntax or by using a "static method" syntax like Array.method(value, params). The general gist of the idea is to annotate a function parameter as being of the Array type, but not actually checking for any inheritance at call time. Instead, when a method is called on the parameter, but the method does not exist, it falls back to looking up the method on the annotated type and invoking it on the object.

That way you pretty much only need to worry about a handful of methods to mimic any given type. Mimicing a String would only require a charAt and a charCodeAt method, for instance. All the others can be implemented on top of those. The core native String type can internally use faster C implementations, and the "static" methods on the String type object would be there for fallback purposes during duck typing.

You can then take things a little further, if need be. You can state that any type trying to pretend to be a String needs its own charAt and charCodeAt methods, for instance, and check those when calling methods with annotated types. With the recent work into tracing in dynamic languages and the older tricks with auto-classes, you can eliminate most of the speed penalty of doing a bunch of method lookups for type checking.

I say all this because I've been writing a JavaScript based MUD kernel (http://jsmud.googlecode.com) and dealing with the strengths and short comings of JavaScript (much as Chris is running into limitations with Ruby) and working up solutions. The JavaScript 2 work is looking pretty… misguided. They're trying to add Java/C++-ish type checking and making JavaScript act more like a static language instead of, oh I dunno, trying to come up with solutions actually designed for dynamic languages.

… </tanget>

You might want to look into Scala – it lets you do this kind of thing in very interesting ways. It's a statically typed language, but completely type inferred. It's also purely object-oriented, which gives you all those nice features. It's like a statically-typed-dynamic language, if that makes any sense. It's really a fun and interesting language. :smile:

Could you go into some more detail on this? (Perhaps in a separate thread….) I'm curious if you are using unit tests, and, if not, why not?

Mods, please split this post off into its own thread if you feel it's hijacking the original thread. :-)

Unit tests will only get you so far. They help you verify that things are working, but they don't really help you at all when it comes to keeping the entire system in your head. Also, it's pretty hard to unit test GUIs.

Why in gods name would someone create something as ugly as ObjC i was jus looking at the Syntax and im now offically scared to even touch it, in fear id shoot Davion, or DH ;)

I don't disagree with this, but I don't think it's an argument against unit tests. Sure, they're not a panacea, but having tests prevents a lot of problems from ever happening. That way, you can worry about other problems. :-)

In the context of MUDs, there generally isn't a GUI to worry about (though there can be other fiddly bits that are hard to test). As far as keeping the whole system in your head, that's what refactoring (when necessary) and the KISS principle are for.

Everyone RUN he wants to kiss DH!!!!!

I wasn't trying to make an argument against unit tests, I was trying to say that they don't necessarily address the problem being discussed in this particular case. :wink:


Frankly, that's good in theory, but it only goes so far when the system gets large enough. I think I'm generally pretty good at keeping large amounts of interface in my head, but why should I do myself what computers are much better at?