글쎄, 약한 대 강한 타이핑은 꽤 모호하게 정의되어 있습니다. 또한, '강력한 타이핑'의 일반적인 사용이 가장 근접하기 때문에 타입을 캐스트하기 어렵게 만드는 것들을 언급하는 것이 더 강하므로 더 강력한 타입 시스템을 설명 할 수있는 것은 없습니다. 마치 30 파운드 미만을 운반 할 수 있다면 몸이 약하고 더 많이 들어 올릴 수있는 사람은 모두 같은 범주의 '강한'이라는 오해의 소지가 있습니다.
그래서 나는 정의를 선호한다 :
- 약한 유형의 시스템은 유형을 사용하여 실수와 같은 특정 작업을 수행하지 못하게합니다.
- 강력한 유형의 시스템은 유형을 사용하여 작업 을 수행합니다.
내가 당신을 위해 무엇을 의미합니까? 자, 서번트 프레임 워크에서 이미지 변환 API를 작성해 보도록하겠습니다 (하스켈에서, 실제로 따라야 할 것을 알 필요는 없습니다.).
{-# LANGUAGE
TypeOperators,
DataKinds
#-}
import Codec.Picture
import Data.Proxy
import Network.Wai.Handler.Warp (run)
import Servant
import Servant.JuicyPixels
main :: IO ()
main = run 8001 conversion
이것은 Servant 패키지와 JuicyPixels 플러그인을 포함하여 일부 모듈을 Servant에 필요로하며, 프로그램의 주요 진입 점은 Warp 백엔드를 사용하여 포트 8001에서 '변환'기능을 서버로 실행하는 것입니다. 언어 비트를 무시하십시오.
conversion :: Application
conversion = serve (Proxy :: Proxy ConversionApi) handler
이것은 변환 함수가 API가 'ConversionApi'유형과 일치해야하고 요청이 함수에 의해 처리되는 서버라고 말하고 있습니다. handler
type ConversionApi
= ReqBody '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE] DynamicImage
:> Post '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE] DynamicImage
ConvesionApi유형을 지정합니다 . '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE] 목록에 지정된 수신 컨텐츠 유형을 승인하고이를 DynamicImage로 처리해야하며 동일한 범위의 컨텐츠로 변환 된 DynamicImage를 리턴해야합니다. 유형. :>의 의미에 대해 정확히 걱정하지 말고 지금 당장 그것을 행복한 마술이라고 생각하십시오.
그래서 내가 선호하는 정의를 감안할 때 약한 유형의 시스템은 이제 다음과 같은 것을 보장 할 수 있습니다.
- 잘못된 발신 콘텐츠 유형을 반환하지 않습니다
- 수신 요청을 잘못된 컨텐츠 유형으로 구문 분석하지 않습니다.
- 서버가 더 복잡하다면 잘못된 URI를 만들 수는 없지만 실제로 링크를 포함하는 HTML 페이지를 반환하지는 않습니다.
- 정말 야심 찬 약한 타이핑 시스템은 모든 수신 및 발신 컨텐츠 유형을 철저하게 처리하고 있는지 확인하여 해당 유형이 제약 조건 대신 사양 문서로도 작동하도록 할 수도 있습니다.
위의 정의를 감안할 때 모든 높은 목표이지만 실제로 강력한 유형의 시스템으로 자격을 갖추기에 충분하지는 않습니다. 이제이 사양을 따르는 코드를 실제로 작성 하는 데 어려움 을 겪어야합니다. 정말로 강력한 타입 시스템에서 우리는 다음과 같이 씁니다.
handler = return
그리고 우리는 끝났습니다. 그게 다야, 더 이상 쓸 코드가 없습니다 . 이것은 완벽하게 작동하는 웹 서버입니다. 형식은 컴파일러가 정의하고 가져온 형식과 패키지 (기술적으로 모듈)에서 웹 서버를 만드는 데 필요한 모든 것을 컴파일러에 지시했습니다.
그렇다면 주요 응용 프로그램 규모에서이를 수행하는 방법을 어떻게 배울 수 있습니까? 음, 소규모 응용 프로그램에서 사용하는 것과 크게 다르지 않습니다. 절대 유형은 관련 코드 작성 량에 상관하지 않습니다.
런타임 형식 검사는 피하고 싶을 것입니다. 그 이유는 많은 이점을 없애고 형식을 단순화하는 대신 형식을 사용하여 프로젝트 작업을 더 복잡하게 만들 수 있기 때문입니다.
따라서 대부분 유형을 사용하여 모델링하는 연습 문제입니다. 사물을 모델링하는 두 가지 주요 방법 (또는 일반적인 사물 구축)은 상향식과 하향식입니다. 하향식은 최고 수준의 작업으로 시작하며 모델을 작성할 때 나중에 모델링을 연기하는 부분이 있습니다. 상향식 모델링은 기본 기능으로 시작하는 것처럼 기본 작업으로 시작한 다음 프로젝트 작업을 완전히 캡처 할 때까지 더 큰 모델을 빌드하는 것을 의미합니다. 상향식은 더 구체적이고 빌드하기가 더 빠르지 만 하향식은 모델이 실제로 어떻게 행동해야하는지에 대해 더 잘 알릴 수 있습니다.
유형은 프로그램이 말 그대로 수학과 관련되는 방식이므로 실제로 얻을 수있는 복잡성 또는 학습을 '완료'할 수있는 지점에 대한 상한은 없습니다. 상위 수준의 대학 과정 외부의 거의 모든 리소스는 유형이 특정 언어로 작동하는 방식에 전적으로 헌신되어 있으므로이를 결정해야합니다.
내가 제공 할 수있는 한 유형은 다음과 같이 계층화 될 수 있습니다.
- [] + {}가 정의 된 JavaScript와 같은 매우 약한 유형
- [] + {}를 수행 할 수없는 Python과 같이 약하게 입력되었지만 시도하기 전까지는 확인되지 않습니다.
- C 또는 Java와 같이 약하게 입력했지만 [] + {}를 수행 할 수는 없지만 컴파일 타임에 확인되지만 고급 유형 기능은 없습니다.
- C ++ 템플릿 메타 프로그래밍과 같은 약한 유형과 강력한 유형의 경계, 유형이 속성 만 적용하는 단순한 Haskell 코드
- 위에 표시된 것처럼 유형이 작업을 수행하는 더 복잡한 Haskell 프로그램과 같이 강력하게 입력됩니다.
- 유형과 값이 상호 작용하고 서로를 구속 할 수있는 Agda 또는 Idris와 같은 매우 강력한 유형입니다. 이것은 타입 시스템만큼 강력하며, 프로그래밍은 프로그램이하는 일에 대한 수학적 증거를 작성하는 것과 같습니다. 참고 : Agda로 코딩하는 것은 문자 그대로 수학 증명을 작성 하는 것이 아니며 유형은 수학 이론이며 이러한 유형의 함수는 해당 이론을 입증하는 건설적인 예입니다.
일반적으로이 목록을 아래로 내려 갈수록 유형이 더 많은 것을 할 수 있지만 맨 아래에는 성층권으로 올라가고 공기가 약간 얇아지고 있습니다. 패키지 생태계는 훨씬 작고 관련 라이브러리를 찾은 것보다 더 많은 것을 직접 작성해야합니다. 대규모 프로그램을 작성하기에 충분한 유형 시스템을 실제로 이해해야하므로 진입 장벽도 높아집니다.