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

Yeah, I can imagine cases where allocation is specially tracked. Rust does
that now too. Sometimes I wish things like iterators and builders had their
uniqueness tracked via the compiler.

Anyway this is off topic. My contribution to the original post is that I
just try to match parens() with whether or not the class was defined with
parens(). Often I wish the compiler would enforce this for me but it doesn't



On Mon, Jul 13, 2015 at 5:21 PM, Adriaan Moors <[email protected]> wrote:

> Some (exotic) systems consider allocation a side-effect (e.g., for
> embedded, where GC needs to be bounded etc).
>
> Normally, you only care about "changes"/effects to stuff that's reachable,
> and a freshly allocated object is known not to be aliased, so there is no
> side-effect -- move along people!
> Btw, on a related note: Facebook's Infer is fascinating stuff -- applying
> separation logic to production systems.
>
> On Mon, Jul 13, 2015 at 5:05 PM, Haoyi Li <[email protected]> wrote:
>
>> > I didn't mean to imply allocation is side-effecting. I meant the side
>> effect of the initializer in your case class would be invoked every time
>> you instantiate it, whereas the effect in an object's body occur at most
>> once.
>>
>> Oh ok. I thought you were agreeing with jon, who said instantiating a new
>> instance of a class was a side effect (???)
>>
>> On Mon, Jul 13, 2015 at 5:02 PM, Adriaan Moors <[email protected]>
>> wrote:
>>
>>> I didn't mean to imply allocation is side-effecting. I meant the side
>>> effect of the initializer in your case class would be invoked every time
>>> you instantiate it, whereas the effect in an object's body occur at most
>>> once.
>>>
>>> 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.
>>
>
>  --
> 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.