Re: Difference between "def a()" a "def a"?

Seth Tisue wrote:
>>>>>> "Ricky" == Ricky Clarkson writes:
>
> Ricky> It'd be nice if Java setX could be called as foo.x = 5, and getX
> Ricky> called as .x too.
>
> Ah, like @BeanProperty, but in reverse! I like it.
>

It should definitely work like that for closer java integration.

This might push it too far for you all, but I personally would like a
name matcher that also works around camel casing and underscoring naming
conventions, too.

See this article on scala & ruby dsls for one use case:
http://www.artima.com/weblogs/viewpost.jsp?thread=251945

For example this code:
result should be true

could match this:

result.should_be(true)

Of course I also like falling back to case-insensitive matching, too :)
I'm not expecting any of this to be approved for scala.

--
Doug Holton
http://edtechdev.blogspot.com/

>>>>> "Jorge" == Jorge Ortiz writes:

Jorge> I think def a is the "more idiomatic" way to write it. The
Jorge> difference in invocation syntax between def a and def a() was
Jorge> blurred, such that using Java APIs was not a total pain (e.g.,
Jorge> you can do javaList.size vs having to do javaList.size()).

Jorge> That said, def a and def a() are not entirely identical, as you
Jorge> and other have noted.

Jorge> Some people suggest using () only for methods that have
Jorge> side-effects.

Jorge> I would suggest that, as a matter of style, Scala methods should
Jorge> always be invoked how they are defined (i.e., def a is invoked
Jorge> with a, def a() is invoked with a()).

I suggested earlier that the Scala compiler ought to enforce that the
call match the definition when Scala code calls Scala code. It seems to
me that the looser rule is only needed when Scala code calls Java code.

2009/3/20 Seth Tisue :
>  Jorge> I would suggest that, as a matter of style, Scala methods should
>  Jorge> always be invoked how they are defined (i.e., def a is invoked
>  Jorge> with a, def a() is invoked with a()).
>
> I suggested earlier that the Scala compiler ought to enforce that the
> call match the definition when Scala code calls Scala code.  It seems to
> me that the looser rule is only needed when Scala code calls Java code.

I believe Martin has said that this will indeed be the case in 2.8.