lowering barrier to entry

[ghost]

If all that eero had was optional semicolon, indentation as scope, optional parentheses around condition, message passing without square brackets and type inference I think it is a huge improvement over Objective-C because they are used all the time.

I want to use switch to eero, but after reading the documentation, the list is pretty long. i have to remember a bunch of new stuff.

I think just changing @selector(someMethod:) to |someMethod| isn't really worth it. Even though it is more concise, It just increases effort for adoption.

Here are things that I think are really useful and things that I rather not have changed from objective c (even if eero makes more sense).

Optional semicolons +100 Off-side rule (indentation indicates block scope) +100 Optional parentheses around conditions +30 Message passing without square brackets +100

Objective-C keywords without ’@’ -10 Logical and bitwise operators and, or, not, etc. +10 The goto statement is illegal -10

Built-in symbol search on names with the “NS” prefix -10 User-defined prefix namespaces -10 Variables and literals +0

Object declarations are assumed to be pointers +10 Local type inference +30

No variable shadowing +0 NSString literals using single quotes +0 No ’@’ needed for array and dictionary literals +0

Mutable array and dictionary literals -10 Variable definitions using type inference and nil or Nil -10

Selector and protocol literals -10 NSRange literals (and expressions) using ‘..’ or ’…’ -10 NSRange variables and literals in for in loops -10 Underscores permitted in numeric literals +0 Stricter enum type checking +0

Method parameter type names are not enclosed in parentheses -10 Method parameters have default variable names -10 Method return type specified by trailing return, void by default if omitted -10 Methods are instance methods by default +10

Optional parameters and default arguments -10 Default return expression -10 No curly braces needed around member-variable declarations +10 Declarations of properties of the same type can be grouped together +0

Built-in equality and inequality comparison operators -10 Built-in ’+’ (binary version) and ’«’ string operators -10 Binary operators (effectively, operator overloading) -10 Array and dictionary subscript operators with integer and object indexes -10 Object subscript operators with NSRange indexes -10

Converting primitive data types to objects (boxing) +10 Converting objects to primitive data types (unboxing) +10

Blocks enhancements Compact blocks -10 Nested functions (const blocks) -10

The switch statements No fall-through +20 Comma-separated lists of cases +10 Case-value ranges -10

I think decreasing the number of differences between objective c and eero makes sense and only adopting differences that make a big impact in everyday coding would make the transition to eero easier.

I know this would make eero not as pure and clean, but It would still be a lot better than objective c.

[ksjogo]

I agree with this. At the moment there is to much stuff added being not that important for me.

[andrebraga]

In my humble (but, hopefully, informed) opinion:

Optional semicolons +100 (less clutter) Off-side rule (indentation indicates block scope) +10 (nice in the way it enforces discipline, but I'm not a Pythonista) Optional parentheses around conditions +30 (breaks the otherwise conversation-like structure of the code) Message passing without square brackets +100 (YAY. And even yayer that most of the situations that would require parentheses to disambiguate happen to be passing properties as arguments, and there the dot syntax can circumvent such a need)

Objective-C keywords without ’@’ 0 (Neutral; no legacy code to worry about name collisions, but might be deviating a bit too much) Logical and bitwise operators and, or, not, etc. +10 (Yay C99/iso646.h!) The goto statement is illegal -1000 (DON'T DO THAT. WrIting interpreters without goto makes your code stink for the sake of pretense purity.)

Built-in symbol search on names with the “NS” prefix -10 (Breaks POLA, and it's quite frequent that people write their subclasses precisely by stripping the NS/UI prefix...) User-defined prefix namespaces -10 (Honestly, "using" is a bad idea.) Variables and literals +0

Object declarations are assumed to be pointers +100000 (times infinity!) Local type inference +30 (cool.)

No variable shadowing +30 (quite necessary when you're making declarations optional) NSString literals using single quotes +0 (I'd rather have all double quotes automatically correspond to NSStrings unless prefixed by C, as in C"This is a C array-of-chars a.k.a. char*".) No ’@’ needed for array and dictionary literals -10 (could be confusing. The previous point would remove much of the need for keeping at-signs out of those.)

Mutable array and dictionary literals +100 (I really liked your idea. But would there be a way to express the immutable empty collections and strings?) Variable definitions using type inference and nil or Nil +100 (high time since someone picked that from functional languages)

Selector and protocol literals +100 (brilliant!) NSRange literals (and expressions) using ‘..’ or ’…’ +10000 (BRILLIANT!!!!) NSRange variables and literals in for in loops +100000 (LIKEWISE!!!!!!) Underscores permitted in numeric literals +0 (weird.) Stricter enum type checking +50 (cool.)

Method parameter type names are not enclosed in parentheses +100 (great) Method parameters have default variable names +0 (not convinced this is a good idea) Method return type specified by trailing return, void by default if omitted -100 (don't mess with Obj-C's id by default.) Methods are instance methods by default -10 (I'm not for this, but not a deal breaker)

Optional parameters and default arguments +10 (this feels strange, but I thing this will grow positively on me) Default return expression -1 (don't do this on the interface, this ain't no java, no. On the implementation, I'd rather have it prefixed by the default keyword.) No curly braces needed around member-variable declarations +0 (strange, but may grow on me) Declarations of properties of the same type can be grouped together +10 (clever use of scoping)

Built-in equality and inequality comparison operators +100 (sweet!) Built-in ’+’ (binary version) and ’«’ string operators +100 (except that it should be += instead of << for appending!) Binary operators (effectively, operator overloading) +0 (haven't checked the syntax for that but I hope it's not an aberration like C++'s) Array and dictionary subscript operators with integer and object indexes +10000 (hell yeah!) Object subscript operators with NSRange indexes +100000 (hell yeah!!!)

Converting primitive data types to objects (boxing) +100 (yay!) Converting objects to primitive data types (unboxing) +100 (double-plus-yay!)

Blocks enhancements Compact blocks +10 (feels like Smalltalk, maybe use the square bracket notation or even keep the curly with the pipe?) Nested functions (const blocks) +10 (as long as you prefix the block name with the caret.)

The switch statements No fall-through +1000 (Normally I'd say this is utter fail, but...) Comma-separated lists of cases +INFINITY (so much win!!!!) Case-value ranges +INFINITY (so much win!!!!!!)

[andrebraga]

Crap, can't edit using an iPad.

Re: No ’@’ needed for array and dictionary literals: Okay, this makes sense since () wasn't overridden for a literal NSSet because of boxing, but you solved boxing separately (so that might be an idea worth considering!) and you decided it would be a nice fit for the block short notation. However, if you decide that NSSet would be a nice addition, the @ prefix is unavoidable, and in this case I'd rather have blocks return to the curly-brace notation, but looking like ^{args | body}, args being optional.