기능 과부하? 예 또는 아니오 [닫힘]

정적으로 강력하고 형식이 지정된 컴파일 언어를 개발 중이며 언어 오버로드 기능을 언어 기능으로 포함할지 여부를 다시 생각하고 있습니다. 나는 주로 C[++|#]배경 에서 비롯되어 약간 편향되어 있음을 깨달았습니다 .

가장 설득력있는 인수 무엇 을위한 과 에 대한 언어로 오버로드 기능을 포함하여?

편집 : 반대 의견을 가진 사람이 없습니까?

: 버트 랜드 마이어 (1985/1986에서 에펠 다시의 창조자) 방법이 오버로드를 호출 ^_(소스)

OO 언어의 의미 론적 힘에는 아무런 영향을 미치지 않지만 가독성을 저해하고 모든 사람의 작업을 복잡하게하는 허영 메커니즘

이제는 일부 일반화이지만 똑똑한 사람이므로 필요할 경우 백업 할 수 있다고 말하는 것이 안전하다고 생각합니다. 실제로 그는 거의 CLSv1 개발자 중 한 명인 Brad Abrams에게 .NET이 메소드 오버로드를 지원하지 않아야한다고 확신했습니다. ^_(출처) 그것은 강력한 것입니다. 누구든지 자신의 생각과 25 년이 지난 후에도 그의 견해가 정당화되는지 여부를 밝힐 수 있습니까?

함수 오버로딩은 C ++ 스타일 템플릿 코드에 매우 중요합니다. 다른 유형에 대해 다른 함수 이름을 사용해야하는 경우 일반 코드를 작성할 수 없습니다. 그것은 C ++ 라이브러리의 많은 부분과 C ++ 기능의 대부분을 제거 할 것입니다.

일반적으로 멤버 함수 이름에 존재합니다. A.foo()와는 완전히 다른 함수를 호출 할 수 B.foo()있지만 두 함수는 모두 이름이 지정 foo됩니다. +정수 및 부동 소수점 숫자에 적용될 때 다른 것들 과 마찬가지로 연산자에 존재하며 종종 문자열 연결 연산자로 사용됩니다. 정규 기능에서도 허용하지 않는 것이 이상합니다.

호출되는 정확한 기능은 두 가지 데이터 유형에 따라 달라지는 공통 Lisp 스타일 "멀티 메소드"를 사용할 수 있습니다. Common Lisp Object System에서 프로그래밍하지 않은 경우 이것을 쓸모 없게 만들기 전에 시도하십시오. C ++ 스트림에 필수적입니다.

함수 과부하가없는 I / O (또는 더 나쁜 가변 함수)는 다른 유형의 값을 인쇄하거나 다른 유형의 값을 공통 유형 (문자열)으로 변환하기 위해 여러 가지 다른 기능이 필요합니다.

함수 과부하가 없으면 변수 또는 값의 유형을 변경하면 변수를 사용하는 모든 함수를 변경해야합니다. 코드를 리팩토링하기가 훨씬 어렵습니다.

사용자가 사용중인 형식 명명 규칙을 기억할 필요가없고 표준 함수 이름 만 기억할 때 API를보다 쉽게 ​​사용할 수 있습니다.

연산자 오버로드가 없으면 기본 작업을 둘 이상의 유형에서 사용할 수있는 경우 사용하는 유형으로 각 기능에 레이블을 지정해야합니다. 이것은 본질적으로 헝가리어 표기법이며, 나쁜 방법입니다.

전반적으로 언어를 훨씬 더 유용하게 만듭니다.

적어도 Haskell의 타입 클래스를 알고있는 것이 좋습니다. 타입 클래스는 연산자 오버로딩에 대한 훈련 된 접근 방식으로 만들어졌지만, 다른 용도를 발견하고 어느 정도까지 Haskell을 만들었습니다.

예를 들어, 다음은 애드혹 오버로드의 예입니다 (유효하지 않은 Haskell).

(==) :: Int -> Int -> Bool
x == y = ...
x /= y = not (x == y)

(==) :: Char -> Char -> Bool
x == y = ...
x /= y = not (x == y)

그리고 타입 클래스로 오버로드하는 것과 같은 예가 있습니다 :

class Eq a where
    (==) :: a -> a -> Bool
    (/=) :: a -> a -> Bool

    x /= y  =  not (x == y)

instance Eq Int where
    x == y  = ...

instance Eq Char where
    x == y  = ...

이것의 단점은 당신의 모든 typeclasses에 대한 펑키 이름을 마련 할 필요가 있다는 것이다 (하스켈처럼, 당신은 오히려 추상적이 Monad, Functor, Applicative뿐만 아니라 간단하고 인식 Eq, Num및 Ord).

단점은 일단 typeclass에 익숙해지면 해당 클래스에서 모든 유형을 사용하는 방법을 알고 있다는 것입니다. 또한 다음과 같이 필요한 클래스를 구현하지 않는 유형에서 함수를 쉽게 보호 할 수 있습니다.

group :: (Eq a) => [a] -> [[a]]
group = groupBy (==)

편집 : Haskell에서 ==두 가지 다른 유형을 허용 하는 연산자를 원하면 다중 매개 변수 유형 클래스를 사용할 수 있습니다.

class Eq a b where
    (==) :: a -> b -> Bool
    (/=) :: a -> b -> Bool

    x /= y  =  not (x == y)

instance Eq Int Int where
    x == y  = ...

instance Eq Char Char where
    x == y  = ...

instance Eq Int Float where
    x == y  = ...

물론 이것은 사과와 오렌지를 명시 적으로 비교할 수 있기 때문에 아마도 나쁜 생각 일 것입니다. 그러나 일부 상황 에서는 실제로 +a Word8를 추가 Int하는 것이 현명한 일 이므로 이것을 고려할 수도 있습니다.

기능 과부하를 허용하면 선택적 매개 변수로 다음을 수행 할 수 없습니다 (또는 가능하지 않은 경우).

사소한 예는 방법이 없다고 가정base.ToString()

string ToString(int i) {}
string ToString(double d) {}
string ToString(DateTime d) {}
...

항상 함수 오버로드보다 기본 매개 변수를 선호했습니다. 오버로드 된 함수는 일반적으로 기본 매개 변수를 사용하여 "기본"버전을 호출합니다. 왜 쓰는가

int indexOf(char ch)
{
  return self.indexOf(ch, 0);
}

int indexOf(char ch, int fromIndex)
{
  // Do whatever
}

내가 할 수있을 때 :

int indexOf(char ch, int fromIndex=0)
{
  // Do whatever
}

즉, 때로는 오버로드 된 함수가 기본 매개 변수를 사용하여 다른 변형을 호출하는 대신 다른 일을한다는 것을 알고 있습니다. 그러나 그러한 경우에는 그냥 좋은 아이디어가 아닙니다. 다른 이름.

또한 파이썬 스타일 키워드 인수는 기본 매개 변수와 잘 작동합니다.

방금 Java를 설명했습니다. 또는 C #.

왜 바퀴를 재발 명합니까?

리턴 유형이 메소드 서명의 일부이고 하트 컨텐츠에 과부하 인지 확인하십시오 . 말할 필요가 없을 때 실제로 코드를 정리합니다.

function getThisFirstWay(int type)
{ ... }
function getThisSecondWay(int type, double limit)
{ ... }
function getThisThirdWay(int type, String match)
{ ... }

Grrr .. 아직 언급 할 권한이 없습니다 ..

@Mason Wheeler : 반환 유형에 과부하가 걸리는 Ada에주의하십시오. 또한 내 언어 Felix는 일부 컨텍스트에서, 특히 함수가 다른 함수를 반환하고 다음과 같은 호출이있을 때 그것을 수행합니다.

f a b  // application is left assoc: (f a) b

b의 유형은 과부하 해결에 사용될 수 있습니다. 또한 어떤 상황에서는 C ++이 반환 유형에서 오버로드됩니다.

int (*f)(int) = g; // choses g based on type, not just signature

실제로 유형 유추를 사용하여 반환 유형에 오버로드하는 알고리즘이 있습니다. 실제로 기계를 사용하는 것은 어렵지 않습니다. 문제는 인간이 기계를 찾는다는 것입니다. (나는 개요가 Dragon Book에 있다고 생각합니다. 알고리즘은 올바르게 기억하면 시소 알고리즘이라고합니다)

함수 오버로딩 구현에 대한 유스 케이스 : 같은 방식으로 동작하지만 다양한 패턴으로 완전히 다른 인수 세트를 사용하는 25 개의 유사한 메소드.

함수 오버로딩을 구현하지 않는 유스 케이스 : 정확히 동일한 패턴으로 매우 유사한 유형의 세트를 가진 5 개의 유사한 이름의 메소드.

하루가 끝나면 두 경우 모두 생성 된 API에 대한 문서를 기대하지 않습니다.

그러나 어떤 경우에는 사용자가 무엇을 할 수 있는지에 관한 것입니다. 다른 경우에는 언어 제한으로 인해 사용자가해야 할 일입니다. IMO는 최소한 프로그램 작성자가 모호함을 만들지 않고 현명하게 과부하 될 수있는 가능성을 허용하는 것이 좋습니다. 당신이 그들의 손을 때리고 선택권을 빼앗을 때 당신은 기본적으로 모호함이 일어날 것이라고 보장하고 있습니다. 나는 항상 잘못된 일을 할 것이라고 가정하는 것보다 올바른 일을하도록 사용자를 신뢰하는 것에 관한 것입니다. 내 경험상, 보호주의는 언어 공동체의 행동을 더욱 악화시키는 경향이있다.

필자는 필자의 언어로 일반적인 오버로드 및 다중 유형 유형 클래스를 제공하기로 결정했습니다.

나는 특히 많은 숫자 유형 (Felix는 모든 C의 숫자 유형을 가짐) 인 언어에서 오버로드가 필수적이라고 생각합니다. 그러나 템플릿을 사용하여 오버로드를 악용하는 C ++과 달리 Felix 다형성은 매개 변수입니다. C ++의 템플릿은 잘못 설계되었으므로 C ++의 템플릿에 대해 오버로드가 필요합니다.

유형 클래스도 Felix에서 제공됩니다. C ++을 알고 있지만 Haskell을 이해하지 못하는 사람들에게는 C ++을 오버로드로 묘사하는 사람들을 무시하십시오. 오버로드와 같은 것이 아니라 템플릿 전문화와 비슷합니다. 구현하지 않은 템플릿을 선언 한 다음 필요에 따라 특정 사례에 대한 구현을 제공합니다. 타이핑은 파라 메트릭 방식으로 다형성이며, 구현은 임시 인스턴스화에 의한 것이지만 제한되지는 않습니다. 의도 된 의미를 구현해야합니다.

Haskell (및 C ++)에서는 의미를 설명 할 수 없습니다. C ++에서 "개념"아이디어는 대략 시맨틱을 근사하려는 시도입니다. Felix에서는 공리, 축소, 명예 및 정리로 의도를 근사 할 수 있습니다.

주 및 단지 펠릭스처럼 잘 원칙 언어로 오버로드 (개방)의 장점은 프로그램 라이터 및 코드 검토를 위해 모두 쉽게 라이브러리 함수 이름을 기억 할 수 있다는 것입니다.

오버로드의 주요 단점은이를 구현하는 데 필요한 복잡한 알고리즘입니다. 또한 형식 유추와 잘 어울리지 않습니다. 두 가지가 완전히 배타적이지는 않지만 두 가지를 수행하는 알고리즘은 프로그래머가 아마도 결과를 예측할 수 없을 정도로 복잡합니다.

C ++에서는 조잡한 일치 알고리즘이 있고 자동 유형 변환도 지원하기 때문에 문제가됩니다. Felix에서는 자동 유형 변환없이 정확한 일치를 요구하여이 문제를 "고정"했습니다.

그래서 당신은 내가 생각하는 선택이 있습니다 : 과부하 또는 타입 추론. 추론은 귀엽지 만 충돌을 올바르게 진단하는 방식으로 구현하기도 매우 어렵습니다. 예를 들어, Ocaml은 충돌이 감지되는 위치를 알려 주지만 예상되는 유형을 유추 한 위치는 알려주지 않습니다.

오버로드는 모든 후보를 알려주는 양질의 컴파일러가 있더라도 후보자가 다형성인지 읽기가 어려울 수 있으며 C ++ 템플릿 해커 인 경우 더 나빠질 수 있습니다.

상황에 따라 달라 지지만 다른 사람이 작성한 것을 사용하면 오버로드가 클래스를 훨씬 유용하게 생각합니다. 종종 중복성이 줄어 듭니다.

C 계열 언어에 익숙한 사용자를 원한다면 사용자가 기대하기 때문에 그래야합니다.