. and () are not both optional, it's just another syntax. foo.bar(baz) can be written as foo bar baz. foo.bar().baz() cannot be written as foo bar baz, that would be ambiguous grammar. foo.bar().baz() can be written as foo.bar.baz, or depending on context, foo.bar baz.
If you reduce the above to ". and () are both optional", you've lost some information and are going to talk crap. Paul Phillips doesn't need an air of authority, he is an authority. On Wed, Sep 29, 2010 at 4:22 AM, Reinier Zwitserloot <[email protected]> wrote: > > > On Sep 29, 4:18 am, Paul Phillips <[email protected]> wrote: >> >> It's not possible? If you don't know the language it's not possible, >> I guess. > > Ah, yes, turns out if accountName is a method in this snippet: > > user getAccount accountName isEnabled > > scala indeed appears to throw out a compiler error complaining about > argumentlist sizes. Excuse me for not knowing this rather obscure > corner of scala. Given that () and . are both optional, you'd think > that one could replace user.getAccount().accountName().isEnabled() > with "user getAccount accountName isEnabled" but that assertion is > evidently false. () and . are only optional in some cases. That's > still complexity in the sense that the rule "() and . are optional" is > false, and it's still complexity in the sense that scala code that > makes use of the () and . are sometimes optional rule, isn't readable > unless you know these rules. The vast majority of java programmers add > needless parens because they don't know or don't want to bother future > readers with the distinction that i.e. || loses from && (or vice > versa, I don't know either, and I don't care) in precedence rules. > > To get back to making a point about the scala community: > > <making a point> > You're wrong when you said it wouldn't parse. It parses just fine. > It's the resolver that emits the error. > > You should try learning the lingo. It would lend an air of authority > to your retorts which is presently lacking. > </making a point> > > See how that lowers the discussion? This kind of behaviour is not > going to impress upon the casual reader the idea that scala is for > everybody. Instead it'll give the impression that scala is only for > elitist jackasses. That's not exactly fair to scala. > > >> > If for whatever reason the "getAccount" >> > method becomes zero-args, and returns an object that has a >> > "accountName" method, then the meaning of "user getAccount accountName >> > isEnabled" would change significantly. >> >> Yes, it changes to "this code no longer compiles because it doesn't >> parse." >> I think you should try learning the language. It would lend an air of >> authority to your ideas which is presently lacking. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
