Blog - Title

November, 2008

철수네 소프트웨어 세상 [마이크로소프트 지점]

Blog - Post Feedback Form(CAPTCHA)
  • 철수네 소프트웨어 세상 [마이크로소프트 지점]

    Dynamic Language 소식(20081128)

    • 0 Comments
    DLR Hosting and related stuff...  DLR v0.9 beta released in CodePlex

    DevHawk - Early Christmas from Iron Languages and DLR

    Visual Studio팀 내에 Dynamic Language 팀의 소식들입니다.

    우선 이 팀의 코어 부분인 DLR(Dynamic Languages Runtime)이 CodePlex에 새 둥지를 틀었습니다. 이전에는 IronPython등의 일부로 기생(?)하면서 살고 있었는데, 드디어 집을 찾았습니다. 현재 공개된 버젼은 0.9의 베타 버젼으로 IronPython과 같은 비트를 사용하기 위해서 일단 베타버젼을 공개하였고, IronPython의 스케줄에 맞춰서 0.9의 정식 버젼이 나오게 됩니다. Release Note에서 좀 더 많은 정보를 찾을 수 있습니다.

    참조 구현인 ToyScript도 DLR의 다운로드에 포함됩니다. 또한 DLR을 위한 둥지가 마련되면서 이번에 부가적으로 DLR 문서들이 몇개 올라왔습니다.

    이 DLR 0.9 베타에 맞춰서 공개된 IronPython은 2.0의 RC(출시 후보) 2입니다. RC1을 출시로 잇고자 했지만, 문제가 될만한 버그가 몇개 발견되어 두번째 RC를 공개하였습니다. 대략 2주 안에 정식버젼을 출시한다고 되어있고 문제가 있더라도 연내에 정식버젼이 나오지 않을까 생각됩니다.

    참고로, 지난주에는 IronRuby의 Alpha 2버젼이 공개되었습니다. RubyForge에서 다운로드 받을 수 있습니다.

  • 철수네 소프트웨어 세상 [마이크로소프트 지점]

    드디어, 한글 Silverlight Tools를 받을 수 있습니다~

    • 1 Comments

    다운로드 세부 정보: Silverlight Tools

    그동안 RC 버젼에 런타임만 바꿔서 사용하고 계셔서 약간 언짢으신 분들이 계셨었죠? 문제가 조금 있어서 예상보다 더 걸렸습니다만, 그저께 한글 SDK 다운로드가 Live되었고, 오늘부터는 Silverlight Tools 한글 버젼을 다운로드 할 수 있게 되었습니다. 영문 버젼의 경우 RC와의 차이는 버젼으로 인한 호환성 차이 정도였습니다만, 한글 버젼의 경우 SDK가 영문 SDK가 아닌 한글 SDK가 들어가게 되어 번역된 내용들이 포함되었기 때문에 영문보다는 차이가 있다고 하겠습니다.

    드디어 Silverlight 2에 관한 모든 비트가 완료되었고, 이제는 다음 버젼만이 남았네요.

  • 철수네 소프트웨어 세상 [마이크로소프트 지점]

    Azure(애저) 정리

    • 2 Comments

    이름들이 뭐가 그리 많은지…다 아시는 내용들이겠지만 한번 정리해봤습니다. 내부에서 사용하는 공개되지 않은 용어들은 배제했습니다. 일반 사용자가 사용할 내용은 실제 Azure을 사용하여 만든 서비스에 국한되고 아래의 내용은 대부분 개발자들을 위한 내용입니다.

    Azure

    마케팅 브랜드 우산(umbrella)으로 정확히 하면 Azure™입니다. 마이크로소프트 전체 클라우드 관련 내용들은 대부분 애저(Azure)라는 브랜드 아래에 들어갑니다. 통상 Azure라고 하면 Azure Services Platform이라고 하는 플랫폼을 지칭하는데 같은 이야기입니다. 이를 ASP라고 줄여 부르면 기존 용어와 완전 대혼란일게 뻔하기 때문에 ASP가 아니고 그냥 Azure입니다. 사이트의 정의를 살짝 베껴오면:

    The Azure™ Services Platform (Azure) is an internet-scale cloud services platform hosted in Microsoft data centers, which provides an operating system and a set of developer services that can be used individually or together.

    Azure는 일반적으로 3가지로 구분되어있습니다. 가장 기반이 되는 Azure Runtime(Windows Azure), 이들을 사용하여 확장한 Azure Services들 그리고 이들을 사용하여 만든 외부 서비스.

    Windows Azure

    코드명이 유출되면 불편한 것이 실제 브랜드명과 헷갈리게 된다는 것인데, 전에 Red Dog이라는 코드명으로 알려져 있어서 조금 아시는 분들은 아직 헷갈리고 있는 것 같습니다. 게다가 도중에 Stratus라는 브랜드를 사용하려고 했다가 브랜드 충돌이 있어서 Windows Azure로 바뀌었습니다. 가장 흔히 쓰이는 그림으로 살펴보면 다음과 같습니다:

    The Cloud Computing and Services Platform Diagram

    Azure는 클라우드를 위한 OS(운영체제)라고 표현하기도 하는데 이해를 위해 컴퓨터와의 Analogy를 사용한 것입니다. 말그대로 다른 서비스들을 제공하기 위해서 기반이 되는 구성요소들이 되겠습니다. 데이타베이스나 파일등을 위한 스토리지라든가 호스팅 기반이라든가 혹은 컴퓨팅/관리를 위한 인프라등등이 여기에 해당됩니다. 위의 그림에서 각각의 흰 네모들은 Azure Services라고 하고 이들을 엮은 전체를 Azure Services Platform이라고 합니다. 윗쪽 Azure Services를 헷갈리지만 Cloud Services라고 부르기도 합니다. 맨 아랫단에 Windows Azure가 있고 이를 Azure Runtime이라고 부르기도 하며 이는 Windows Azure SDK를 사용하여 접근할 수 있습니다.

    컴퓨터에 올려진 OS의 경우에는 응용프로그램(Application)과 API 호출 혹은 IPC나 syscall같은 방법을 사용하지만, (당연하지만) 애저에서는 REST방식이나 SOAP혹은 XML, 또는 다른 HTTP를 사용한 프로토콜들을 포함하는 인터넷 프로토콜들을 사용합니다. 물론 Azure Services Platform과 외부 서비스와의 통신도 동일한 방법을 사용합니다. 위의 그림에서는 Windows Live, Office Live등의 마이크로소프트 서비스들을 보여줬지만, 실제로는 Azure를 사용한 다양한 사이트들이 생겨나겠죠.

    Live Services

    Live Services는 이름에서 유추할 수 있듯이 기존의 Windows Live에서 API로 제공하던 내용들을 하나의 이름 아래에 통합한 것입니다. Live Services SDK 문서를 보면 Live Services API들의 목록을 볼 수 있습니다. 예를 들어 Live ID를 사용하기 위한 API들이라든가 Virtual Earth를 사용하기 위한 API라든가 등등이 포함되어있습니다. 이들은 Windows Live에서 분리하여 사용할 수 있는 것들이죠.

    Live Mesh는 여러 디바이스/클라우드/기계들의 데이타를 자연스럽게(?) 동기화하는 응용프로그램으로 시작하여 서비스로 확장한 Live Framework이 되었습니다. 데이타를 동기화하는 시나리오는 굉장히 많은데 Synchronizing Life라는 제목의 프로모션 비디오를 참고하시면 나름 어떤 느낌인지 와닿을 것 같습니다. Live Framework은 단순히 파일을 동기화하는 것이 아니라 여러가지 리소스 모델들을 동기화합니다. 파일 이외에 데이타베이스처럼 테이블의 데이타라든가, 혹은 피드들도 동기화할 수 있습니다. 앞으로 차차 Live Services에서 Live Framework이 중심 프레임웍으로 전환될 예정입니다.

    SQL Services

    기존의 데이타베이스가 하던 여러가지 기능들이 온라인으로 제공되는 서비스들에 사용하는 브랜드입니다. 이 이름 아래에 있는 서비스들 중에서 현재 공개된 서비스는 이전에 SSDS(SQL Server Data Service)라고 불리던 SDS(SQL Data Services)입니다. SDS는 기존의 관계형 데이타베이스 형태로 관리되는 데이타를 위한 스토리지 서비스로 SQL Server를 기반으로 만들어졌습니다. 클라우드를 생각하지 않더라도 세상에는 데이타를 관리하는 솔루션은 다양하고, 마찬가지로 SDS도 여러가지 관리 방법 중에서 SQL Server의 기능에 집중한 서비스입니다. 헷갈릴 수도 있겠지만, 이런 이유로 이외에도 다양한 다른 방식의 스토리지 서비스들이 Azure에 존재합니다.

    SQL Services에서 제공될 다른 서비스들은 여기서 보실 수 있습니다. 모두 새로 오픈한 SQL Services Lab에서 인큐베이팅 중입니다.

    .NET Services

    굳이 이름을 .NET Services로 했지만, .NET에 국한되기 때문에 이런 이름을 사용한 것이 아니라 .NET의 기능에 맞게 분류했기 때문에 이 이름을 사용한 것 같습니다. 이전에는 BizTalk Labs에서 Biztalk Services라는 이름으로 연구개발을 하던 서비스들로 Azure 아래로 통합되었습니다. 보시면 Java나 Ruby용 SDK도 제공하고, 굳이 SDK를 사용하지 않고 직접 호출해서 사용할 수도 있습니다.

    .NET Services에서 현재 제공하는 서비스들은 이전과 비슷하게 다음과 같습니다:

    • Access Control(접근 제어) – 사용자를 확인하고 할 수 있는 일들을 구분해줍니다.
    • Service Bus – 응용프로그램들을 연결해주는 매개역할을 합니다.
    • Workflow Service – 클라우드에서 워크플로를 사용할 수 있도록 합니다.

    다시 Windows Azure

    Windows Azure 서비스들을 사용하거나 보완하여 위에서 설명한 여러 Azure Services들이 동작하지만, 그렇다고 Windows Azure이 가려져있는 것은 아닙니다. 사용할 수 있는 Windows Azure는 다음의 여러 서비스들로 이뤄져 있습니다:

    • Windows Azure Storage Services – 파일과 같은 바이너리(Blobs), 서비스간의 메시징 큐(Queues), 데이타베이스와 같은 테이블(Windows Azure Tables)등의 서비스를 제공합니다.
    • Compute 서비스 – 실제로 CPU를 소비하는 로직을 위한 서비스입니다. 개발된 응용프로그램이 데이터센터로 배포되어 통신을 담당하는 부분과 작업을 담당하는 두부분으로 나뉘어 동작하게 됩니다. (아래 “기타”에 설명되는 Azure Fabric에 해당하는 부분입니다.)

    내부적으로는 fabric이라는 용어를 사용합니다.

    기타

    이름이 무슨무슨 Services이기 때문에 Azure의 내용 같아서 헷갈릴 수 있는 것으로 ADO.NET Data Services가 있습니다. 이전에 Astoria라는 코드명으로 불리던 것으로 Azure Services의 컴포넌트로가 아니라 이런 REST 기반의 서비스를 쉽게 만들 수 있도록 해주는 (WCF를 사용하여 만들어진) 기반 기술입니다. Azure Services가 ADO.NET Data Services로 만들어져 있을 수도 있고, 혹은 ADO.NET Data Services를 염두에 두고 만들어진 서비스라면 연동이 될 수도 있을 것일테죠.

    웹에 호스팅되는 서비스를 만드는 회사들은 일반적으로 로컬 개발 –> 테스트 호스팅 환경 –> 운영 환경(운영계)의 단계로 만든 서비스를 확인하면서 최종 배포를 하게 되는데, 이를 Staging이라고 합니다. Azure 서비스를 만들때에도 같은 방식을 사용하게 됩니다. 우선 Windows Azure Tools for Visual Studio를 사용하여 시뮬레이션을 하면서 개발을 합니다. 이때 데이터센터에 있는 서비스들을 직접 사용하는 것이 아닌 시뮬레이션 되는 환경을 Development Fabric이라고 합니다. 반대로 개발된 내용을 운영 환경으로 올린(배포/퍼블리싱) 경우에 실제로 사용하는 환경을 Windows Azure Fabric 혹은 Hosted Services Fabric이라고 합니다. Development Fabric에서는 시뮬레이션만 하지만 Windows Azure Fabric을 통해서는 서버간 배포와 버져닝, 로드 밸런싱이나 복구와 관리등의 작업들이 이루어집니다.

    --

    대표적으로 비교되는 타사 서비스라고 한다면 Amazon Web ServicesGoogle App Engine(Python)이나 Heroku(Ruby) 혹은 Ning(PHP)같을 것을 들 수 있겠습니다. 혹은 위에서 소개한 각각의 서비스와 경쟁하는 회사 서비스들도 있습니다. 각기 다른 비즈니스 모델과 수익 모델을 생각하기 때문에 비슷하게 대응되는 서비스들이 있기도 하고 없기도 합니다. 대충 클라우드 컴퓨팅 플랫폼이라고 하는 다가오는 환경의 맛보기라고나 할까요.

    혹자 우리가 사용하는 모든 웹서비스들과 bittorrent나 SETI@home같은 아키텍쳐를 포함하여 클라우드 컴퓨팅이라고 한다고 미래의 다른 가능성도 포함하여 정의하지만 산업 전반을 이야기하는 용어로 사용하기보다는 여기서는 플랫폼으로서의 클라우드 컴퓨팅으로 개인적으로 인프라/플랫폼등을 포함한 “기능을 (호스팅 기반의) 인터넷 기반의 서비스로 제공하는 모델”이라고 보는 것이 일단은 무난하지 않나 생각됩니다. 어떤 경우든 클라우드 컴퓨팅의 시대가 도래했다는 것은 맞는 말이겠지만요.

    위에서 정리한 Azure 서비스들은 앞으로 계속해서 나올 서비스들의 흐름을 보여주는 것으로, Windows Live 자체도 위의 모델로 바뀌어 갈 것이고 위의 서비스들의 모양들로 유추할 수 있듯이 기존 소프트웨어의 강력함을 계속 가져가는 S+S(Software plus Services) 모델도 계속해서 마이크로소프트의 한 축으로 계속될 것이라 생각됩니다.

  • 철수네 소프트웨어 세상 [마이크로소프트 지점]

    C# 4.0 새기능들(2008년10월CTP버젼)

    • 1 Comments

    개발자 분들을 위한 내용들을 적는 블로그임에도 불구하고 소식들과 가십들을 위주로 적다보니 정작 코드를 적는 것은 굉장히 오랜만인 것 같습니다.^^ 드디어 조금 적을 기회가 왔습니다. C# 4.0에 관한 이야기를 적으면서 말이죠…

    C# 3.0의 주요 테마 중 한가지는 LINQ였습니다. 물론 각 기능들은 독립적인 유용성이 있었지만, LINQ를 구현하는 연장선상에서 여러가지 새 기능들이 설명될 수 있었고 그에 준하여 추가되었습니다. 이번 C# 4.0이 진행되는 동안 (물론 3.0을 개발하는 것과 동시에 시작되었죠) 재미난 영향들이 있었습니다.

    C#의 설계자들은 알려진대로 9년전부터 매주 몇번씩 C# 디자인 미팅을 가집니다(참고로 VB도 마찬가지지요). 마치 원탁의 기사들처럼 이 미팅에는 다양한 사람들이 참가하여 새기능과 기존 철학의 밸런스를 조절합니다. 근래의 주요 참가자들을 보면 당연히 C#의 Anders Hejlsberg와 Mads Torgersen가 있고, JScript등의 스크립팅의 Eric Lippert, VB의 Paul Vick 그리고 C# 3.0 이후로 Jim Hugunin이 참가를 하는데, Jim은 DLR(Dynamic Language Runtime) 전문이죠.

    Jim을 빼고는 오랫동안 이 멤버들이 참가를 했었지만, Jim의 DLR의 등장으로 인해 4.0이 되어서 한 테마로 떠오른 것이 기술들의 행복한(?) 조화였습니다. (물론 커뮤니티로부터의 커다란 피드백도 많은 영향을 미쳤습니다.) 동적(dynamic)인 요소는 이들이 잘 지내는데에 필수적인 요소였기 때문이랄까요? 아마도 이런 이유로 4.0의 새기능들 중에서 다음의 내용들이 주를 이룹니다:

    • dynamic이라는 키워드 –> DLR(IronPython/IronRuby등), COM과의 Interop
    • Optional/Named 파라미터, No PIA –> 좀 더 편해진 COM Interop, VB 기능과의 싱크

    모두가 다른 기술과 잘 지내보려는 개방의 노력이라고 할 수 있겠습니다. 다르게 이야기하면 다른 언어나 기술에서 제공하던 방식으로 상호연동(Interop)하기 위해서는 C#에서 제공하지 않는 것들은 포기해야하거나 혹은 C#의 방식대로 불편하게 사용해야하는 상황을 개선하고자 했다고 이야기할 수 있겠습니다.

    - dynamic 키워드

    다음의 C# 3.0 코드를 보시죠:

    var calc = new Calculator();

    int sum = calc.Add(10, 20);

    이 경우에는 var이라는 형식(type)이 존재하는 것이 아니고, 유추(infer)에 의해 Calculator라는 클래스임을 판단하고 calc의 형식을 정의하게 됩니다. 따라서 기존의 정적인 방식과 다름없이 컴파일시에 형검사가 이뤄지게 됩니다.

    반면 4.0에서 소개되는 dynamic이라는 형식(type)은 (여러가지 규칙이 있지만) 일반적으로 evaluation을 실행시간(runtime)으로 미루겠다는 표시입니다. Anders의 슬라이드에서 빌리자면:

    dynamic calc = GetCalculator();

    int sum = calc.Add(10, 20);

    calc는 정적(static) 언어의 의미로는 dynamic이라는 형식(type)을 가지는 변수입니다. 따라서 여기서 Add라는 메서드의 호출문은 컴파일러에 의한 형검사를 통하지 않고 실행시간(runtime)에 바인딩되어 동적으로 호출됩니다. (내부적으로는 호출 이전에 dynamic이라는 형식을 필요한 형식으로 대체를 하는 방식을사용하게 되며, 이로써 정적 언어에서 동적인 속성을 사용할 수 있는 방안을 제공하게 되는 것입니다.)

    dynamic 키워드가 없다면 위의 코드를 다음과 같은 방식으로 동적인 속성을 코딩해야할 것입니다:

    object calc = GetCalculator();

    Type calcType = calc.GetType();

    object res = calcType.InvokeMember("Add", BindingFlags.InvokeMethod, null, new object[] { 10, 20 });

    int sum = Convert.ToInt32(res);

    물론 이는 calc가 다른 외부의 객체 모델(OM, Object Model)을 대표하는 것이 아니라 .NET 객체를 사용한 경우의 예이고 다른 경우에는 다른 방식을 사용하겠죠.

    이런 Reflection을 사용하지 않는 구현을 위하여 IDynamicObject라는 인터페이스를 제공하며, 이는 정확히는 DLR에서 제공하는 인터페이스입니다. Anders의 PDC 세션에서는 HTML DOM도 AsDynamic()이라는 Extension 메서드를 통해 IDynamicObject로 래핑해서 dynamic으로 사용하는 것을 보여줍니다.

    이를 통하여 COM Interop에 몇가지 더 편리함을 제공하게 됩니다. 예를들어, Variant를 위해 사용하는 object 형식을 다시 해당하는 형식으로 cast하는 오버헤드가 없어집니다. C# 4.0 새기능 문서의 예제를 빌리면:

    ((Excel.Range)excel.Cells[1, 1]).Value2 = "Hello";

    excel.Cells[1, 1].Value = "Hello";

    이렇게 사용할 수 있습니다.

    - Optional / Named 인자

    이는 이전부터 구현의 이슈라기 보다는 언어의 철학에 관한 이슈였습니다. .NET Framework 디자인에 있어서 인자는 명백히 선언되어 호출시 명기해야하는 경우에 더 나은 코딩 방식으로 생각되어져 왔지만, 그동안 수많은 반대 피드백들이 있었습니다. 특히 COM Interop시의 Missing값 이슈는 VB에서는 제공하던 Optional 인자와 비교해서 코딩에 해를 주는 요소였습니다.

    이에 C# 4.0부터는 다음과 같이 정의시에 인자의 기본값을 지정하고, 호출시에 원하는 인자의 값을 지정할 수 있게 되었습니다(Anders의 강의에서 환호를 받았죠.^^):

    public StreamReader OpenTextFile( string path, Encoding encoding = null, bool detectEncoding = true, int bufferSize = 1024); // 뒤의 3 인자에 기본값 지정

    OpenTextFile("foo.txt", Encoding.UTF8); // 뒤의 2 인자 생략

    OpenTextFile("foo.txt", Encoding.UTF8, bufferSize: 4096); // 뒤의 2 인자 중 bufferSize만 지정

    OpenTextFile( bufferSize: 4096, path: "foo.txt", detectEncoding: false); // 각 인자를 순서에 관게없이 지정

    - Variance

    행복한 조화 분류에 속하지는 않지만, 중요한 결정 중 하나는 Variance입니다. Variance를 설명하는 것은 마치 입문자에게 포인터를 설명하는 것처럼 잘못 설명하면 헷갈리기 쉬운 것이라 조심스럽습니다만, 이번 4.0에서는 인터페이스와 delegate에 한하여 지원하므로 해결하고자 하는 문제에 한해 Anders의 설명방식으로 설명해봅니다.

    .NET 배열은 co-variant하기 때문에 어떤 객체에 더 구체적인 객체를 대입할 수 있습니다. 즉 object[]를 요하는 곳에 string[]를 사용할 수 있습니다. 쉽게 “아무 동물을 각 방에 넣어줘봐” 하면 닭들을 채워주는 것과 같은 것입니다. 반면, string[]을 대입했더라도 object[]인 것에는 변함이 없기 때문에 컴파일시에는 여기에 string이 아닌 다른 값을 대입해도 object에 대입한 것으로 간주하여 오류를 내지 않습니다. 대신 실행시간에 런타임오류가 발생하죠:

    object[] oa;
    oa = new string[10];
    oa[1] = new int(); // 컴파일되지만 런타임오류가 발생

    이런 문제에 type safety를 제공하기 위해서 Generics라는 훌륭한 기능이 들어옵니다만, 문제는 Generics는 invariant하다는 것입니다. 즉 List<object>에 List<string>을 대입할 수는 없습니다.

    List<object> ls;
    ls = new List<string>(10);

    위의 코드는 VS에디터에서 “Cannot implicitly convert type 'System.Collections.Generic.List<string>' to 'System.Collections.Generic.List<object>'라고 항변합니다. “object 리스트인데, 왜 string을 각 요소로 사용할 수 없는거지?”하는 불만이 생기게 되는 것입니다. 이 두가지 이슈의 완충 작용을 위해서 C# 4.0에서는 제한적으로 인터페이스/delegate에 covariance와 contravariance를 지정하는 방식을 도입합니다. 다음의 코드를 보시죠(아직 C# 4.0의 프로토타입 단계라 아래의 코드가 동작하는지는 모르겠습니다만 컨셉만 생각해보세요):

    List<string> strings = new List<string>(10);
    IEnumerable<object> objects = strings;

    objects에 strings가 대입되었지만, IEnumerable에 의해서 objects에 값을 지정할 수 있는 방법이 없게 됩니다. 즉, co-variance를 허용한 대신 값에 쓰는 방법을 제공하지 않는 것으로 safety를 제공하게 됩니다. 이는 다음과 같은 방법으로 정의함으로써 구현됩니다:

    public interface IEnumerable<out T> {
      IEnumerable<T> GetEnumerabor();
      T Current { get; }
      …
    }

    위의 코드에서는 out을 T에 붙임으로써 co-variant임을 지정합니다. 위의 코드에서 밑줄친 것과 같이 out을 붙임으로써 T의 사용은 output에 제한하게 됩니다. 즉, IEnumerable<T>는 co-variant하게 대입이 가능함과 동시에 이로 인해 발생할 수 있는 safety를 보장하도록 하는 장치를 가지게 됩니다.

    반대로:

    public interfact IComparer<in T> {
      int Compare(T x, T y);
    }

    에서처럼 T에 in을 붙임으로써 contra-variance를 지정하고 input에만 사용할 수 있는 제약을 둡니다(그렇지 않으면 컴파일 에러를 내겠죠). 다시 쉬운 예를 들면, 100원짜리가 들어갈 수 있는 저금통을 요구하는 사람에게 500원짜리가 더 큰 것이기에 500원짜리가 들어갈 수 있는 저금통을 줘도 괜찮은 것과 같을 수 있겠습니다 – 반대로 500원짜리만 넣겠다는 사람에게 100원만 들어가는 구멍의 저금통을 주면 contra-variant하기 때문에 안되겠죠. 즉, 여기서는 IComparer<object>를 IComparer<string>에 대입할 수 있게 되는 것이고, 그 safety가 컴파일시에 보장되는 것이죠. 인자로 string을 받아 비교하는 클래스이기 때문에 그 구현이 object라고 하더라도 명백히 호환이 되는 것이죠.

    물론 in과 out을 섞어서 활용할 수도 있겠습니다. Eric Lipper의 Co-variance와 Contra-variance에 관한 씨리즈를 참고하시면 좋을 것 같습니다. Wikipedia에도 이에 관해 잘 나와있습니다.

    - 정리

    C# 4.0의 새기능 문서를 보면 이외에도 VB의 기능과의 parity에 관한 이야기가 언급됩니다. C#의 dynamic과 VB의 Late Binding은 속성이 비슷하기 때문에 VB에서 DLR을 사용하도록 조절될 수 있고, Optional/Named 인자는 이미 VB에서 오랫동안 사용되었기 때문에 이를 바탕으로 C#의 기능을 설계하였고, 또한 NoPIA와 variance는 C# 뿐만 아니라 VB에도 추가되는 기능이라고 이야기합니다.

    이렇듯, C#의 방향성은 다른 기술과 잘 지내려고 하는 방향으로 흐르고 있고, 애초의 태생도 다양한 언어와 기술의 기반이 될 수 있는 CLR(.NET Framework)을 지원하는 언어로서의 역할을 위한 것이었기 때문에 이런 방향이 잘 설명될 수 있습니다. (반면 JavaVM은 Java를 위해서만 만들어졌기 때문에 이에 충실한 방향이었고, 이에 맞는 방향성과 동적언어등으로 인한 그 방향성의 변화도 설명될 수 있습니다.)

    위에서 설명한 DLR이나 COM Interop 혹은 스크립팅언어등 이외에도 CLR위에 F#과 같은 새로운 함수형 언어의 공식 지원으로 인한 변화와 병렬(Parellel) 환경 지원을 위한 CLR의 변화등도 함께 C#의 방향성에 영향을 주고 있으며, 이미 SQL과 같은 절차형이 아닌 선언형식의 언어적 요소를 위한 LINQ의 수용도 3.0이후에 이뤄지고 있습니다. 앞으로 계속되는 “정적(static) 언어”인 C#의 이런 요소들의 실용적인 섭렵을 계속 기대해봅니다.

Page 1 of 1 (4 items)