Goose 는 duck typing 의 duck 에서 따왔다. C++ 위에서 duck typing 을 구현해 행위 기반 다형성을 이루는 것을 목표로 하고 있다. 물론 referece counting 역시 지원한다. Duck 이 아니라 Goose 인 이유는 결국은 duck 이 되지 못할 것이라는 일종의 비관이 담겨 있기도 하다.
프로젝트 시작하던날 술기운에 약 700여줄의 코드를 작성했는데 그 결과 현재 C++ 위에서 뭔가 java 와 ruby 가 뒤섞인듯한 아래와 같은 문법을 지원한다.
using namespace gs;
var a = 10;
var b = 5;
var c = b;
a = a / c;
b = b % 1.2f;
var arr = new array;
arr[2] = a;
arr[3] = "Hi~";
arr[4] = new array( "Kwak~", "Kwak~~!" );
arr[5] = 7;
arr( erase, 5 );
var hs = new hash;
hs[0] = arr;
hs[1] = new hash;
hs[0][0] = 12345;
hs[1][0] = arr;
hs[1][0][0] = 66666;
a = a + hs[0][0];
for( int i = 0; i < (int)arr.size(); ++i )
{
printf( "%d. %s (%s)\n", i, arr[i].to_s().c_str(), arr[i].type() );
}
printf( "a(%s) %d %f\n", a.type(), a.to_n(), a.to_f() );
printf( "b(%s) %d %f\n", b.type(), b.to_n(), b.to_f() );
printf( "c(%s) %d %f\n", c.type(), c.to_n(), c.to_f() );
printf( "arr(%s) %d %s\n", arr.type(), arr.size(), arr.to_s().c_str() );
printf( "hs(%s) (%s)\n", hs.type(), hs[0].type() );
결과는 아래와 같다.
0. 66666 (fixnum)
1. nil (nil)
2. 2 (fixnum)
3. Hi~ (string)
4. Kwak~,Kwak~~! (array)
a(fixnum) 66668 66668.000000
b(floatnum) 0 0.200000
c(fixnum) 5 5.000000
arr(array) 5 66666,nil,2,Hi~,Kwak~,Kwak~~!
hs(hash) (array)
루비에서 많은 부분을 따 왔다. printf() 포메팅 사용시 to_xxx() 를 사용해야 하는 불편함은 4바이트 타입 및 문자열의 경우 해결될 수 있겠지만 과연 그래야 하는지는 의문이다.
static binding 으로부터 벗어나야하기에 메세징을 채용했는데 그 동작은 Objective-C 의 것과 유사해질듯 싶다. 객체가 처리하지 않는 메세지를 받을 경우 Objective-C 처럼 그냥 조용히 침묵해줄 예정이다. 대부분 메세지의 결과로 self reference 를 리턴할 것이기 때문에 루비에서 자주 사용했던 아래와 같은 문법들도 사용이 가능할 것이다.
int a = arr( unique )( sort )( reverse )( first ); // 배열에서 중복을 없앤뒤 정열하고 뒤집은 다음 첫번째 원소를 a 에 저장
int a = arr( unique )( sort )( reverse )[0]; // 마찬가지
receiver 가 괄호 안에 들어가면 아래와 같이 좀 더 예쁜 모양이 되었을 테지만 C++ 에서는 아래 문법을 지원해낼 방법이 없다.
( ( ( arr sort ) reverse ) first )
콤마를 사용해 아규먼트의 체인을 구성하는 것도 방법일것 같은데 한번 시도해볼 가치가 있을것 같다. 여튼 현재 메시징 방식 선택 문제 외에 여러 다른 숫자타입간의 정밀도를 유지하는 부분을 해결 중이며 남은 기술적 이슈들은 다음과 같다.
1. 해쉬 키를 좀 더 효율적인 녀석으로 교체
2. 메세지의 타입을 정하는 일 (스트링보다 빠르면서도 사용이 편해야 한다.. 결국 심볼의 문제다.)
3. 사용자 정의 타입 지원
4. mix-in 은 어떻게..?
5. 코드의 데이터화. 람다와 클로저..
심볼을 어떻게 해결할 것인지는 아직 별달리 뾰족한 방안이 떠오르지 않는다.
여튼 프로젝트가 성공적으로 완료된다면 게임 개발에 있어서 아이템 인벤토리라던가 스킬 퀵슬롯, 기타등등 성능은 전혀 중요하지 않지만 설계가 밥먹듯이 변경되는 그런 컨텐츠 코딩에 어쩌면 사용될 수도 있을거라고 본다. C++ 로 컨텐츠 프로그래밍을 하면서 컨테이너의 타입을 정의하고 관계를 설정하는 일이 정말 진저리가 났는데 BS 는 TC++PL 에서 클래스를 디자인하고 관계를 설정하고 계층을 고민하는 것이 유익할 것이라고 했지만 그것은 명세가 변하지 않을때의 이야기다. 게임 개발은 명세가 밥먹듯이 변하는 분야다. 물론 C++ 에서 이런 삽질을 하지 않고 스크립트로 뽑아낼 수는 있지만 스크립트 채용으로 인한 마샬링 비용 및 바인딩 역시 번거롭기는 마찬가지다.
* 위 글은 3/14 일에 작성하였던것인데 오늘 발굴해서 공개한다. Goose 는 요새 일이 바빠서 전혀 손을 못대고 있다. -_-;;;
트랙백 주소 :: http://testors.net/tt/trackback/943
댓글을 달아 주세요
구글이 뭐 다 그렇죠 뭐 <-
돈내고 쓰는 서비스라면 전화걸어서 욕이라도 해주겠는데, 구글 녀석들은 무료로 '영원한 베타' 를 들먹이며 우리의 정보만 스물스물 자기들 밑으로 가져가는데 심히 못마땅하다능... 그러다 가끔 정보를 송두리채 날리기도 하는데 연락해보면 1주일 있다가 '그럴리가 없다능! 우리능 완벽하다능!' 이라고 하는 경우도 있어서 대략 압뷁
그러려고 일부러 돈을 안받는거죠 :)