Ada의 심각한 단점: 패키지 이름을 타입 이름으로 사용할 수 없다
Ada를 쓰기로 마음먹었다면, 언젠가는 부딪혀야 할 가장 큰 장벽이자 가장 큰 짜증을 유발하는 문제가 있습니다.
Java나 C# 개발자라면, 같은 패키지(네임스페이스) 안에서 클래스들이 서로 상속받아 자연스러운 타입 계층을 만드는 것에 익숙합니다.
// Java/C# 스타일 의사 코드
// 'widget' 네임스페이스 안에서 타입들이 상속 관계를 형성
package com.example.widget;
public class Widget { /*...*/ }
public class Window extends Widget { /*...*/ }
public class Button extends Widget { /*...*/ }
public class ToggleButton extends Button { /*...*/ }
public class CheckedButton extends Button { /*...*/ }
Widget이라는 베이스 타입과 이를 상속받은 Window 타입이 Widget 이라는 같은 이름 공간에 공존하는, 지극히 상식적인 구조입니다. Ada에서는 이처럼 직관적인 타입 계층을 이름으로 표현하는 데 근본적인 한계가 있습니다.
계층 구조 비교: 직관적인 Java/C# vs 어색한 Ada
GUI 툴킷을 만든다고 가정하고 두 언어의 계층 구조를 다이어그램으로 비교해 보겠습니다. ToggleButton과 CheckedButton은 Button을, Button과 Window는 Widget을 상속받는 관계입니다.
Java / C#의 방식: 상속 기반의 타입 계층
하나의 패키지(네임스페이스) 안에서, 클래스들이 상속을 통해 직관적인 타입 계층을 형성합니다. 타입의 이름이 곧 개념을 나타냅니다.
Widget
/ \
Window Button
/ \
/ \
/ \
ToggleButton CheckedButton
Ada의 방식: 패키지 중심의 계층과 패키지 이름을 타입 이름으로 사용 불가
Ada는 모든 것을 별개의 패키지(모듈)로 분리해야 합니다. Window가 Widget을 상속받는 개념을 표현하기 위해, Widget.Window라는 별도의 자식 패키지를 만들어야 합니다. 또한 패키지 이름을 타입 이름으로 사용할 수 없기 때문에 object 인스턴스를 담을 별도의 타입을 선언해야 합니다. 여기서는 그 타입의 이름을 Object라고 하겠습니다.
Widget
|
Object
/ \
/ \
Window Button
| |
Object Object
/ \
/ \
ToggleButton CheckedButton
| |
Object Object
-- Object가 뒤따를 수 밖에 없는 변수 선언 예시
-- 참고로 with, use를 사용하면 일부 네임 스페이스를 생략할 수 있습니다.
my_widget : access Widget.Object;
my_window : access Widget.Window.Object;
my_button : access Widget.Button.Object;
my_toggle_button : access Widget.Button.ToggleButton.Object;
Widget.Window면 될 것을 Widget.Window.Object라고 써야 하는 이 모습은, 솔직히 말해 끔찍한 혼종처럼 보입니다.
결론: 울며 겨자 먹기로 Ada를 쓰는 이유
Ada의 이런 고집스러운 설계 철학은 정말 마음에 들지 않습니다. 코드는 장황해지고, 다른 언어의 직관적인 객체 지향 패턴을 포기해야 하는 대가를 치러야 합니다.
하지만 아이러니하게도, 저는 이 언어를 버릴 수 없습니다. 안전성/신뢰성을 보장해주는 선택지가 사실상 Ada가 유일하기 때문입니다. 컴파일 시점에는 컴파일러의 엄격한 검사를 하고 실행 시점에는 언어 자체에 내장된 강력한 런타임 검사가 실시간으로 오류를 검사하기 때문에, 저는 이 모든 불편함을 감수하는 것입니다.