Blocks in Objective-J 2.0

[Maz]

In Objective-C, recently, there has been a trend of APIs moving over from a delegate based callback system to one based on blocks. Given that closures are already implemented in JavaScript, are there any plans to add the blocks syntax to the new version of Objective-J and, additionally, are there any plans to change the Foundation/AppKit APIs over to this new system?

~ Maz

[Randy Luecke]

I don't think adding the objc block syntax makes much sense. From an implementation standpoint the "^" just turns into "function" and nothing else changes. 

As for the APIs, sure… keeping parody is important. it's just a matter of someone doing it… you're more than welcome to do it, yourself. :)

[Alexander Ljungberg]

We actually already support many block based APIs, using the Javascript equivalent, functions. E.g. you can do,

[anArray enumerateObjectsUsingBlock:function(anObject) { ... } ];

Other block APIs will be added as developers need them.

Alexander

--
You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
To view this discussion on the web visit https://groups.google.com/d/msg/objectivej/-/e9Zxuo8UavYJ.
To post to this group, send email to objec...@googlegroups.com.
To unsubscribe from this group, send email to objectivej+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/objectivej?hl=en.

[Aparajita Fishman]

> As for the APIs, sure… keeping parody is important.

LOL! Yes, Cappuccino is a *parody* of Cocoa. :D

Perhaps you meant "parity". :)

Regards,

Aparajita

[Randy Luecke]

Freudian slip? ;)

[Kjell Nilsson]

Since it is possible to send Functions at arguments in a method call there is already a block syntax in the Cappucino frameworks and you can easily extend that to work in your own code.

Since data fetching from the server in our project is done by a connection based mechanism we have introduced
blocks that takes care of the response (of data) from the server when it arrives.

This approach is outstanding and makes asynchronous task just so much easier to read and understand.

Like this:

....
[sidebarViewController setEnabled:NO];
fetchSpecification = [LOFetchSpecification fetchSpecificationForEntityNamed: @"uaf_user"];
[fetchSpecification setQualifier:searchPredicate];
[fetchSpecification setOperator: @"count"];
[objectContext requestObjectsWithFetchSpecification:fetchSpecification withCompletionBlock:function(objects) {
var operator = [fetchSpecification operator];
var count = objects[operator];
if (count > maxNoOfFetchedRecords) {
[sidebarViewController showWarning:@"Resultset is more than " + maxNoOfFetchedRecords + @" records. Use the filter to specify more."];
[sidebarViewController setEnabled:YES];
} else {
[fetchSpecification setOperator:nil];
[objectContext requestObjectsWithFetchSpecification:fetchSpecification withCompletionBlock:function(objects) {
[self setUsers:objects];
[sidebarViewController setEnabled:YES];
}];
}
}];

Here we will fetch data that is less than maxNoOfFetchedRecords so we first request a count on the result set to decide if to load the records into the browser. If its under the max limit we then fetch the records. Two roundtrips to the server done in a couple of lines of code and without any other methods involved.

So this kind of blocks is already there waiting for you. :-)

my2c
--kerusan

On 29 dec 2012, at 23:42, Maz <ma.m...@gmail.com> wrote:

> In Objective-C, recently, there has been a trend of APIs moving over from a delegate based callback system to one based on blocks. Given that closures are already implemented in JavaScript, are there any plans to add the blocks syntax to the new version of Objective-J and, additionally, are there any plans to change the Foundation/AppKit APIs over to this new system?
>
> ~ Maz
>

> --
> You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/objectivej/-/czh3QcsRNi8J.

[Maz]

I was specifically wondering whether Objective-J 2 would have the carrot syntax for blocks. I know that one of the most loved features, in coffee script, for example, is the compacted function syntax. So, it might make sense to bring the block syntax over to JavaScript. This is especially the case as it would be relatively easy to make a carrot (in a certain context, of course) simply be an alias for the function keyword.

~ Maz

[Francisco Tolmasky]

I wouldn't necessarily be opposed to the carrot syntax. From a technical perspective, we'd have to make sure the syntax works (remains a strict superset etc). If that's the case, then it would be a consideration of weighing the "social" implications. For example, a pro would be that its easier to port over Objective-C. However, a con would be additional foreign and unfamiliar syntax for people coming from the JS world, perpetuating the idea that there is a lot to "learn" in ObjJ. These are just examples, I have no idea if these concerns/potentials are substantiated or matter.

[Randy Luecke]

Well, one of the coolest parts about Objective-J 2 is that it's super simple to add new features. If a lot of people want it, it's something we should consider… but IMO it doesn't add much. For it me it takes about the same amount of time to type "function" as it does to reposition my hands to type the carrot. :)

[Andrew Hankinson]

I would vote for the carat syntax, if for no other reason to be consistent with Obj-C. The Cocoa docs are almost as important to Cappuccino as its own docs, so the further we diverge from the syntax of Obj-C in Obj-J ("oh, you use 'function' for blocks instead of ^") the more confusion potential there is between the two sets of documentation.

I don't think we should try to appease straight-up JavaScript devs, since they seem to be a pretty finicky bunch at the best of times, and are pretty skeptical of projects like Cappuccino at the best of times, if not downright hostile. It's best to appeal to those who know Obj-C (from Mac/iOS development) or who are attracted to Capp for its comprehensive nature and willing to invest some time to learn the syntax and language features.

--
You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.

To view this discussion on the web visit https://groups.google.com/d/msg/objectivej/-/gZs4JCXOBlEJ.

[Ross Boucher]

I don't think caret syntax is a great addition. It has always been more important to us to be a strict superset, and to design objective-j as desirable extensions to JavaScript, not as a port of Objective-C. We have explicitly chosen, in the past, to change Objective-C syntax in favor of what we deemed to be a more holistic solution. For example, we use @import and not #import. If we believe a function shorthand is needed, I think I'd prefer a similar approach, using @^ rather than just ^. We should also consider whether or not we're ok just letting ES6 solve this problem for us, since the plan already includes shorthand syntax for function.

[Maz]

I don't know what plans are in store for browser compatability in future versions of cappuccino, but if we want to maintain browser compatability, then we can't simply use an ES6 implementation. Moreover, I think that it would make sense to use a simple carot for two reasons. First, not every Objective-C feature has the at-sign prefix. The message syntax in Objective-J uses the identical Objective-C syntax. Second, the arrow syntax is (at least to me) indicative of a more functional-programming based paradigm or syntax (that you might see in Ruby) rather than something you'd see in Objective-C. As such, its use would not seem to fit with the surrounding syntax.

~ Maz

[Randy Luecke]

Well, Cappuccino itself wouldn't start using ES6 function shorthand. It would be the developer supplying blocks/functions using the shorthand.

[Tom Robinson]

Additionally we could simply add ES6 function syntax to the compiler instead of caret syntax. No need for the browser to actually support ES6.

--

You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.

To view this discussion on the web visit https://groups.google.com/d/msg/objectivej/-/jTuTHb6nsxIJ.

[Mehdi Abderezai]

Hi All,

It is 2 years since this thread has stopped. I have started to consider Cappuccino recently, and have to say I am sad to see the 280N gone, but happy to see that the git repo is alive and maintained. My 2 cents, there are lots of folks like me who don't know JS that well, and want to jump into Obj-J head first, but get thrown off or turned off by not having blocks. Is this supported now?

To unsubscribe from this group, send email to objectivej+unsubscribe@googlegroups.com.

[Ross Boucher]

Block syntax remains unsupported (as do many of the "block" APIs added to Cocoa recently). But, the functionality of blocks has always been there in the form of anonymous javascript functions, and some of the APIs in Cappuccino do accept these functions, e.g.:

https://github.com/cappuccino/cappuccino/blob/master/Foundation/CPArray/_CPArray.j#L616

To unsubscribe from this group and stop receiving emails from it, send an email to objectivej+...@googlegroups.com.

To post to this group, send email to objec...@googlegroups.com.

Visit this group at http://groups.google.com/group/objectivej.
For more options, visit https://groups.google.com/d/optout.

[Martin Carlberg]

Hi!

Yes, I can only concur. The block syntax is not there and I don't know if it should as javascript has anonymous functions. We are using blocks (anonymous functions) a lot in our project with great success.

You should not be thrown / turned off just because the syntax is not there. It works like a charm.

Best regards,

- Martin Carlberg

[Aparajita Fishman]

Like the others said, anonymous functions in Javascript are the equivalent of blocks in Objective-C. In fact, you could say that Apple had to invent blocks to emulate the anonymous functions available in Javascript.