Method calling syntax - add dot notation

[mistydemeo]

I would love an optional dot notation syntax for calling methods, like Python and Ruby.

I've never enjoyed ObjC's [obj method:arg] syntax for method calling, particularly when method-chaining. Compare, using an example swiped from the internet:

[[NSOpenGLContext alloc] initWithFormat:[self pixelFormat]]

vs

OpenGLContext.alloc.initWithFormat(self.PixelFormat)

or even

OpenGLContext.alloc.initWithFormat self.PixelFormat

[jckarter]

In Smalltalk syntax, the brackets aren't necessary: NSOpenGLContext alloc initWithFormat: self pixelFormat. It looks like eero also does away with method call brackets so something similar should already work.

[mistydemeo]

Interesting. I saw that eero did away with the brackets, but not having a Smalltalk background I didn't realize that it was possible to readably chain methods that way. If that's the case in eero, that would be great!

[andrebraga]

@jckarter : this would be ambiguous in Smalltalk. You'd need to type NSOpenGLContext alloc initWithFormat: (self pixelFormat) instead, else it would parse as sending self as the sole argument for initWithFormat: and then the unary message pixelFormat to the resulting object.

Otherwise, I think it's fine the way eero does it, except that I'm hating the comma separated multi-argument methods. They should be made optional (are they already?).

[jckarter]

@andrebraga Unary methods have higher precedence than keyword methods in Smalltalk, so the parens aren't necessary.

(edited to clarify I was talking about Smalltalk and not Eero)

[andyarvanitis]

It is correct that this works in Eero very similarly to Smalltalk:

For example, this is valid in Eero:

mystring = String alloc initWithString: 'hello'

One difference is that unary methods in Eero do not have higher precedence, so you would need the parens for the earlier example:

context = NSOpenGLContext alloc initWithFormat: (self pixelFormat)

[andyarvanitis]

As for the commas, they are necessary partly because Eero does not require termination characters (';' or Smalltalk's '.'). They also help readability, in my opinion.

[andyarvanitis]

One more thing: respecting Objective-C's (albeit somewhat controversial) support for dot notation, Eero supports it as well, with no difference in the rules.

[andrebraga]

@jckarter hm... Didn't realise I'm this rusty. I always added the parentheses because this rule usually confused me. And it actually forces parenthesising the whole expression if the use case is the one I mentioned, no? (Of sending the resulting object an unary message)

[andrebraga]

@andyarvanitis still you require end lines, and the sole source of ambiguity would be name clashes between variable names in scope and unary messages, no? Make variables have higher priority, and document that.

And no, the commas are terrible. And completely ungrammatical :) And actually grammatically wrong for many non-native speakers whose mother languages have specific rules about commas and never write English in a way that exploit that language's lenience towards commas...

[pcperini]

Personally, I love the commas. I think they're a fantastic way to separate method parts:

initWithDelegate: aDelegate, color: aColor, andSize: aSize

[andrebraga]

@pcperini: well, commas trick the brain into reading the method call as an actual sentence (rather than a computer language that looks like a conversation but doesn't really cross that border) and there is a clear grammar violation in this situation if you keep the convention of prefixing your variables with an article...

// Obj-C/Smalltalk convention, status quo, doesn't really clash with English
initWithDelegate:aDelegate color:aColor andSize:aSize

// Eero current, clashes with English, articles inverted
initWithDelegate: aDelegate, color: aColor, andSize: aSize

// Reads proper, camelCases horribly :P
initWithADelegate: delegate, aColor: color, andASize: size

All IMHO of course :)

[andyarvanitis]

The latest version of eero now employs universal dot notation -- no brackets or spaces. In a way, I'm sad to see the Smalltalk-like syntax go away, but it simply doesn't play nice enough with the language's C heritage (particularly variable declarations). Please have a look, and hopefully enjoy!