[MUD-Dev] [TECH] [ObjC] : programming languages - Obj-C as opposed to Java

[Bruce Mitchener]

Adam Martin wrote:

> I had a look at the ObjC FAQ at

>   http://www.cs.ruu.nl/wais/html/na-dir/Objective-C/answers.html

> Having started in C and some C++ I moved to Java a long while ago
> and have stuck with it as the lesser of many evils. The ObjC FAQ
> gave the following as the only differences between Java and ObjC
> (well, they mentioned pointless stuff like "different syntax:
> colons for fullstops", etc):

>     "Features that Java adds include mandatory typing, exception
>     and thread support in the language, security managers, name
>     spaces, predefined class libraries (java.lang, awt), etc.

>     Features that Java misses include categories and the selector
>     type.  No categories means that a class can not be amended to
>     suit your needs (a problem suffered by more OO languages,
>     including C++).  No selector type means that `forward::' and
>     `perform:' methods do not exist, and that the possibilities of
>     dynamic binding are limited; e.g. you can't tell an array to
>     say `@selector (hello)' to all its elements, and the buttons
>     in your GUI won't be able to use the target/action paradigm
>     employed by the OPENSTEP AppKit (and which is why inner
>     classes were invented in Java 1.1).

> Unfortunately that doesn't explain to me what "selectors" and
> "categories" actually are (and bear in mind that the things listed
> as Java-only are pretty serious stuff).

Apple's got decent documenation on messaging in Objective C at:

  http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/3CoreObjC/How_Messaging_Works.html

The short of it though is that a selector is a way of identifying
methods.  All methods in Objective C with the same name will have
the same selector.  You have access to this at runtime and is used
in method forwarding and other constructs.

Selectors let you refer to method names within source and toss them
around, like this:

   [aCollection makeElementsPerform selector(printName)];

in TOM, where makeElementsPerform will invoke the printName method
on every element of aCollection.

Categories are an alternative way of extending a class.  Say you've
got a method that you'd like to call on all of your strings, but you
don't want to (or can't) just subclass NSString and use your
subclass everywhere.  With Objective C (or TOM), you can instead
define an extension to the NSString class.  There are plenty of
other uses for categories as well.

Apple's documentation on this is at:

  http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/4MoreObjC/Categories.html

This concept of extension is one of the driving things behind TOM:

  http://www.gerbil.org/tom/

How does this apply to MUDs?

Depending on your view of them, MUDs can be a system well suited to
dynamic implementations.  Being able to extend arbitrary classes
(and dynamically load those extensions at runtime) can be a great
thing. (Especially since you're able to extend the system with
native code, not only interpreted code.)  If nothing else, they
enable some new types of solutions to various implementation
problems.  Objective C and TOM have also been some of the most
enjoyable languages that I've worked with in some time.

  - Bruce

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev