괄호

2014-09-04 2 views
0
내가 (Int) => String)의 유도를 구현하고이 같은 toString 메서드를 재정의하고

Function1.toString (Scala IDE와 동일). 그리고 인 IntelliJ도 (스칼라 IDE는이 경고를 표시하지 않습니다) 빈 괄호를 나타내는 다음과 같은 경고로 인해 빈 괄호를 포함하여 Function1.toString 선언에 toString 방법에 추가해야합니다 보여줍니다괄호

빈 괄호 스칼라 방법은 매개 변수가

로 오버라이드 (override)

메서드에 측면 효과가있는 경우 괄호를 포함하는 것이 좋습니다. Liskov 대체 원칙에 따라 재정의 메서드는 비공개이므로 무시 메서드는 부작용이있는 메서드로 선언 된 이어야합니다. 스칼라 프로그래밍을 참조하십시오 * 5.3 연산자는 스칼라 패키지 I은 다음 ScalaDoc에 가서 Function1 (source를) 확인 방법

, Function2 (source)와 PartialFunction (source가) 있습니다. 2.11.2의 소스 코드에서 Function1Function2은 각각 toString 메서드를 재정의하며 빈 괄호 (PartialFunctionFunction1의 재정의 만 사용함)를 포함합니다. 따라서 Function1Function2toString 메서드에 대해 String 리터럴을 선언했기 때문에이 두 클래스 파일의 소스 코드에 괄호가 포함 된 이유는 알 수 없습니다.

toString 메서드에서 괄호 사용을 정당화하는 어떤 분명한 사실이 있습니까? 또는 IntelliJ 경고가 잘못 되었습니까? IntelliJ 경고가 정확하다면 왜 Scala IDE에 IntelliJ와 같은 경고가 표시되지 않습니까?

답변

1

override def fdef f()을 무시하면 사양에 따라 괄호가있는 것으로 간주됩니다.

당신이 인용 한 IntelliJ 메시지에는 메서드가 단지 접근자가 아니라 부작용이있을 수 있음을 문서화하기 위해 괄호를 포함시켜야한다는 "규칙"이 있습니다.

누구나 해당 표기법에 동의하거나 준수하지는 않습니다.

반복자 초기화 상태와 같이 많은 toString 메서드가 부작용이므로이 규칙은 특히 toString의 경우 비어 있습니다.

난 그냥 최근 ML에이 질문 :

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

특별한 규칙 우려 매개 변수가없는 방법 :

https://groups.google.com/d/msg/scala-internals/ahNPTB6-P3M/1pPyptaH6coJ

내가 후속 내 자신의 질문에 대답했다. ... f는 빈 매개 변수 목록을 가질 수도 있다고 으로 가정합니다.

따라서 괄호를 무시할 수 있습니다. 예를 들어

,

scala> def f = 42 
f: Int 

scala> f() 
<console>:9: error: Int does not take parameters 
       f() 
      ^

scala> class X { def f() = 42 } 
defined class X 

scala> class Y extends X { override def f = 43 } 
defined class Y 

scala> new Y().f() 
res1: Int = 43 

Y.f 빈 PARAM의 목록이 있습니다.

Object.toString()에는 빈 매개 변수 목록이 있으므로 Any.toString의 재정의를 포함하여 모든 재정의가 수행됩니다.

(자바의 이유 괄호는 "빈 응용 프로그램"이라고 변환에 공급 될 때 toString() 인용한다.) 응답에 대한

+0

Tysvm. 귀하의 답변을 세 번 읽었으며 또한 Google 스레드를 읽었습니다. 나는 아직도 확신을 갖고 결론을 이끌어 낼 수 없다. 그래서 짧은 대답입니까? toString 메서드를 재정의 할 때 괄호가 필요하지 않으므로 IntelliJ의 경고가 잘못되었습니다. 만일 그렇다면, 나는 당신의 대답을 요약 (또는 tl; dr)으로 맨 위에 올리면 나중에 받아 들일 것입니다. 그래서 미래의 독자들은 더 깊은 것을 읽지 않고도 결론을 빨리 내릴 수 있습니다. 그렇지 않다면 제 마지막 단락의 세 가지 질문에 대한 답을 이해하도록 도와주십시오. – chaotic3quilibrium

+0

그리고 그 답이 괄호를 생략 할 수 있다면, 왜 그들이 scala.Function1과 scala.Function2 (특히 문자열 리터럴이 할당 되었기 때문에)를 벗어나지 않았는지를 알 수 있습니까? – chaotic3quilibrium

+1

나는 더 강한 단어를 사용했다. –