Are there any plans to implement more language features? Declared Properties?

[Chris Corbyn]

Hi,

At this stage I'm more interested in Objective-J than I am in the
Cappuccino framework as a whole, and I'm curious if there are plans to
extend the language further?

Obviously things like Garbage Collection are implicitly handled in
JavaScript, but what about adding declared properties? Would such a
feature add much overhead or be difficult to implement?

I'm probably way out here (*slaps self for being so naive*), but I
imagine it's more boilerplate code than anything else hooked into the
messaging system so if the receiver gets a message for [receiver
title] and a "- (id)title" method doesn't exist but @property was used
to synthesize that accessor then the appropriate value is returned.

Are the features I see on this page (http://cappuccino.org/learn/
tutorials/objective-j-tutorial.php) everything Objective-J has in
terms of new syntax or are there other things not mentioned here?
Protocols for instance?

Cheers,

Chris

[Ross Boucher]

We have support for something like properties, but it isn't
properties. We call it @accessors. Read this post for more details:

http://cappuccino.org/discuss/2008/10/26/synthesizing-accessor-methods/

The reason it isn't Objective-C 2.0 properties is that we did not want
people to incorrectly associate properties with "the dot syntax", and
mistakenly believe that we support that syntax for Objective-J
property access. This feature isn't possible with the current
implementation of Objective-J, and its unlikely we'll see it anytime
soon. This is a technical decision more than anything else, its just
not practical at this point in time.

There are no protocols in Objective-J, and I'm not sure of the utility
in adding them. In Objective-C, protocols make sense particularly as a
compiler tool, so you can guarantee that objects respond to a given
set of messages. Many of these protocols are informal as well, meaning
you don't always need to implement all of the protocol.

Objective-J has no compiler, and until there's some static analysis
tool (if ever), protocols may have limited use. There's some talk (and
I don't know for sure if this made it into the language) about
allowing default implementations for protocols. Maybe this is
something worth considering for the future, but I'd definitely want to
get opinions on it from the community.

The tutorial covers most of the main stuff. We'll need to add
@accessors in once it ships in 0.6. It doesn't cover any of the
runtime features, and right now the best documentation for that is the
code (or the Objective-C runtime docs). I think we implement many of
the new runtime methods in 2.0, but I'd have to look.

-Ross

[Chris Corbyn]

Hi Rob,

Awesome! @accessors looks perfect. I wans't so bothered about the
keyword or the way it's used, but just the fact that it's possible.

I've added the project to my watchlist on github. I haven't actually
cloned the repo yet, I'm still playing with the download from the
website.

In terms of the @protocol debate. I'm a PHP 5 developer. PHP is
still a new player in the OO game and it is a procedural language, yet
it still has interfaces (a bit like a protocol in ObjC) and abstract
classes.

Yes, errors get picked up at runtime (or hopefully in test coverage)
but there's more to an interface declaration (err, protocol) than
error checking. They provide a sort of contract to fit.

Let's say for example I write my own implemention of a rich text
editor like TinyMCE, only using Objective-J as the environment of
choice. I want to support plugins so I have to design a plugin API.
The system expects plugins to have a known set of methods. It will
work without protocols if the plugin developer correctly implements
all the methods needed. But the protocol itself is like a contract.
It's an outline that needs filling in. So basically it aids
developers just as much as it would generate compiler errors in a
compiled language :)

We have this same debate in PHP sometimes when it comes to static
typing, abstract classes and interfaces in a interpreted language. My
general opinion is that if you expect others to write code to fit an
API you should provide an interface (err, @protocol :P).

It's not important, just a would-be-nice.

Cheers,

Chris

[Chris Corbyn]

I meant Ross, dammit ;)

[Francisco Tolmasky]

The question of whether or not to support protocols is also a question
of how far we want to take the optional static typing support. Since
JavaScript (and thus Objective-J) is so dynamic, any object more or
less can be of any class at any time (which is also true in some
instances with Objective-C). The way we envision type checking in the
future is that (when debug is enabled), the types of objects will be
checked at runtime, and you will receive a warning if the classes or
protocols don't match, as opposed to ObjC where you receive the
warning at compile time. Since there is no compiling in Objective-J
we obviously can't do it then. I'm not sure how PHP works, but it may
be very similar since its not compiled either. I think this is still
very useful, because I think most of us have chased down a bug that
ended up being the sending of the wrong kind of object to a method/
function. Unfortunately we won't be able to warn you about this
"before" the program is run, but at least we can tip you off when it
actually happens. You will of course be able to use "id" or "var" to
mean "any object".

[Chris Corbyn]

Hi Francisco,

Here's what happens in PHP (the type is checked at runtime, always).
Most programmers understand the basic constructs of Java so I'll
assume you understand them too (PHP basically steals the same ones).

--------------------------------------------------------------
interface Observer
{
public function notify($message);
}

class MyObserver implements Observer
{
public function notify($message)
{
printf("Message received: %s\n", $message);
}
}

class Observable
{
private $_observers = array();

public function addObserver(Observer $observer)
{
$this->_observers []= $observer;
}

public function imaginaryMethod($arg)
{
foreach ($this->_observers as $observer)
{
$observer->notify($arg);
}
}
}

$instance = new Observable();
$instance->addObserver(new MyObserver());
$instance->imaginaryMethod(42); // Message received: 42

-----------------------------------------------------------------

Now if I drop the "implements" declaration....

--------------------------------------------------------------

class MyObserver
{
// ... Snip ...

$instance = new Observable();
$instance->addObserver(new MyObserver()); //Fatal error: Argument 1
must be of type Observer at line X in file xxx
$instance->imaginaryMethod(42); //Program execution has halted
entirely so this never executes

-----------------------------------------------------------------

It's better than a potentially cryptic "call to undefined method
notify()" when somebody forgets that you should use notify() rather
than receive() or such like. This example is so simple it's
unconvincing though... you need to imagine the larger system with many
different points for message passing.

Of course, if you declare that you're implementing the interface (err,
adopt the protocol) than the parser errors as soon as it realises you
haven't implemented the correct methods.

Like I say, it's always debatable but my main reason for using them is
not so heavily for error checking, it's to provide a point of
reference for developers who wish to write components for a larger
system and need to satisfy a pre-defined API.

Cheers,

Chris

PS: I noticed fast enumeration does work when trying to recreate this
in Objective-J... I guess that's just because JS already uses that
same syntax to iterate over the entire object.