flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tillrohrmann <...@git.apache.org>
Subject [GitHub] flink pull request: [FLINK-2809] [scala-api] Added UnitTypeInfo an...
Date Mon, 19 Oct 2015 08:05:58 GMT
Github user tillrohrmann commented on the pull request:

    https://github.com/apache/flink/pull/1217#issuecomment-149137247
  
    I think in the case of the UnitTypeInformation and the above-mentioned
    methods which either return Unit or Boolean it is not a problem with the
    parentheses because those types don’t have a apply() method defined afaik.
    
    However, we had before situations where methods returned a more complex
    type which also defined an apply() method. In these cases foobar() with
    definition def foobar: TypeWithEmptyApplyDefinition or def foobar():
    TypeWithEmptyApplyDefinition have a different semantic behaviour. Since
    this is hard to spot if you don’t look at the definition of foobar and the
    resulting type we decided to stick to a common pattern to always add
    parentheses to overriden java methods. Of course, there are situations
    where this is not needed but then the rule wouldn’t be so simple anymore.
    ​
    
    On Sat, Oct 17, 2015 at 12:18 PM, Alexander Alexandrov <
    notifications@github.com> wrote:
    
    > Not all methods without paremeters should translate to methods without
    > parenthesis...
    >
    > @StephanEwen <https://github.com/StephanEwen> I agree with that, but I
    > cannot understand how the UnitTypeInfo might cause a confusion here.
    >
    > The typeInformation macros are synthesized by the macro based on the
    > inferred collection type, which means that the meaning of () is resolved
    > before that. Consider the following example:
    >
    > // in the Scala REPL
    > case class Foo(answer: Int)// defined class Foo
    > def f1(): Foo = Foo(42)// f1: ()Foo
    > def f2: Foo = Foo(42)// f2: Foo
    > val xs = Seq(f1(), f2) // how a literate person would write it// xs: Seq[Foo] = List(Foo(42),
Foo(42))
    > val xs = Seq(f1, f2) // how a dazed & confused person would write it, but still
compiles  // xs: Seq[Foo] = List(Foo(42), Foo(42))
    > val xs = Seq(f1, f2()) // even worse, but this breaks with a compiler exception//
error: Foo does not take parameters//       val xs = Seq(f1, f2())
    > val xs = Seq((), ()) // typing '()' without syntactic context resolves to Unit//
xs: Seq[Unit] = List((), ())
    >
    > In all of the above situations env.fromCollection(xs) is (1) either going
    > to typecheck and trigger TypeInformation synthesis or (2) fail with the
    > above.
    >
    > Can you point to StackOverflow conversation or something similar where the
    > issue you mention is explained with an example?
    >
    > —
    > Reply to this email directly or view it on GitHub
    > <https://github.com/apache/flink/pull/1217#issuecomment-148901986>.
    >



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message