Re: `new Foo` vs `new Foo()`

It's probably worth adding that there's no such thing as a constructor with
no params. Even so casual a document as a style guide shouldn't use that
language.

http://www.scala-lang.org/files/archive/spec/2.11/05-classes-and-objects.html#class-definitions

"If no formal parameter sections are given, an empty parameter section ()
is assumed."

The empty parens are made visible when there is an implicit param list and
args are supplied explicitly.

This isn't news. Maybe there's a phrase to be newly minted to capture what
this purely stylistic difference is. "Pure virtual style."

scala> class C(implicit val c: String)
defined class C

scala> new C
<console>:12: error: could not find implicit value for parameter c: String
       new C
       ^

scala> new C("hi")
<console>:12: error: too many arguments for constructor C: ()(implicit c:
String)C
       new C("hi")
       ^

scala> new C()("hi")
res2: C = C@60f82f98

scala> implicit val s = "bye"
s: String = bye

scala> new C
res3: C = C@5f375618

I also switch between where to put the parens when selecting; mostly
depending on whether I remembered the left paren when I started typing.

scala> (new C).c
res6: String = bye

scala> new C().c
res7: String = bye

Maybe this is the strongest case for postfixOps.

scala> new C c
warning: there was one feature warning; re-run with -feature for details
res8: String = bye

Yes, whenever I begin, It's probably worth adding..., it never is.

On Mon, Jul 13, 2015 at 4:50 PM, Rex Kerr <[email protected]> wrote:

> Well, the question is why you would ever
>
>   case class Foo {
>     def foo = ???
>   }
>
> instead of
>
>   case object Foo {
>     def foo = ???
>   }
>
> If you're doing the former, maybe it is because you are actually
> performing side effects.  Right?  So you should use parens?
>
> Except
>
>   trait Bar[A] {
>     def bar: A
>   }
>
>   case class Foo[A] extends Bar[A] {
>     def foo: A = ???
>     def bar = foo
>   }
>
> And, um, yeah.  Case object?  Not really gonna work here.  Not sure why
> this should be a case class at _all_, though--maybe just because we don't
> like the default toString?
>
> Anyway, there is at least some argument that case classes should have
> parens, even if it's not terribly strong.
>
>   --Rex
>
>
> On Mon, Jul 13, 2015 at 4:05 PM, Haoyi Li <[email protected]> wrote:
>
>> > That's the reasoning for case classes, I guess, since a
>> side-effect-free case class should be a case object.
>>
>> This doesn't make sense to me. Since when was object allocation
>> considered side effecting? When people say "avoid side effects", they
>> usually mean you should allocate *more* objects, not less! Is
>> CaseClass#copy just as side-effecting as mutating vars?
>>
>> On Mon, Jul 13, 2015 at 2:13 PM, Adriaan Moors <[email protected]>
>> wrote:
>>
>>> If we apply the same rule as for methods, you should not add parens
>>> unless your constructor is side-effecting (which is probably not a great
>>> idea in itself).
>>> That's the reasoning for case classes, I guess, since a side-effect-free
>>> case class should be a case object.
>>>
>>> I tend to leave off the empty parens. Their presence should imply
>>> potential side-effects.
>>>
>>> On Mon, Jul 13, 2015 at 1:28 PM, Jon Pretty <[email protected]>
>>> wrote:
>>>
>>>> I tend to include the parentheses for a couple of reasons: firstly
>>>> because case classes require the parens, and by association I justify that
>>>> classes should too, and secondly because instantiating a new instance of a
>>>> class is side-effecting, so the "method" which does that (i.e. the
>>>> constructor) should look like a side-effecting method.
>>>>
>>>> Additionally, for some reason, I prefer to write `new Foo().bar` rather
>>>> than `(new Foo).bar`. I think the reason is that I have a slight discomfort
>>>> at starting an expression with an opening parenthesis, and I've taught
>>>> myself to give the `new` in `new Foo().bar` higher precedence than the `.`,
>>>> even though this is counterintuitive to other parsing rules.
>>>>
>>>> Jon​
>>>>
>>>> On 13 July 2015 at 21:20, Rex Kerr <[email protected]> wrote:
>>>>
>>>>> That's the convention I use.  I've seen both with and without parens
>>>>> in e.g. the Scala library code base.
>>>>>
>>>>>   --Rex
>>>>>
>>>>> On Mon, Jul 13, 2015 at 12:06 PM, Seth Tisue <[email protected]> wrote:
>>>>>
>>>>>> Is there consensus on this? Not sure whether to merge.
>>>>>>
>>>>>> https://github.com/scala/scala.github.com/pull/344
>>>>>>
>>>>>> Seth
>>>>>>
>>>>>>  --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "scala-language" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>  --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "scala-language" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jon Pretty | @propensive
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "scala-language" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "scala-language" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "scala-language" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "scala-language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.