글 수 429
아래에 쓰여있는게 Memory Context이긴 한데,
그냥 훅 포인트 한정으로 한개씩 주는게 아니라
제한없이 필터에서도 저 아래 '별명'을 추가할 수 있었으면 좋겠네요.
그렇게하면, 단일 코드로 모든 내용이 다 지나가는 경우더라도
필터로 걸러서 따로따로 처리할 수 있을것 같아서요
그냥 훅 포인트 한정으로 한개씩 주는게 아니라
제한없이 필터에서도 저 아래 '별명'을 추가할 수 있었으면 좋겠네요.
그렇게하면, 단일 코드로 모든 내용이 다 지나가는 경우더라도
필터로 걸러서 따로따로 처리할 수 있을것 같아서요
아랄
- 2009.12.14
- 22:18:20
네, 히데님도 같은 생각을 하셨군요 ^^
사실 두 방식을 두고 꽤나 고민을 했는데..
나름 장단점이 있습니다.
말씀하신 것처럼 컨텍스트를 사용자가 임의로 생성시켜서 링크하려면
모든 알고리즘 류의 플러그인은 현재 컨텍스트를 열거하는 기능을 가져야 하고, 컨테이너 또한 나름의 구조체를 정의해서 이를 넘겨줘야합니다.
또한 사용자가 삭제하려는 컨텍스트가 현재 어떤 알고리즘에서 사용중이라면 삭제하기 전에 이를 또 통보해줘야 하니 인터페이스가 좀 복잡해 지겠죠.
물론 이 방식은 더 논리적입니다. 말씀하신대로 번역하는 통로가 하나만 있으면 되는 경우 Main 하나만 설정하면 되니까요 ^^
논리성과 단순성 사이에서 저울질하다 현재 채택한 방식이 이겁니다. ㅜㅜ
더 좋은 아이디어가 생각나면 한번 논의해보죠.
사실 두 방식을 두고 꽤나 고민을 했는데..
나름 장단점이 있습니다.
말씀하신 것처럼 컨텍스트를 사용자가 임의로 생성시켜서 링크하려면
모든 알고리즘 류의 플러그인은 현재 컨텍스트를 열거하는 기능을 가져야 하고, 컨테이너 또한 나름의 구조체를 정의해서 이를 넘겨줘야합니다.
또한 사용자가 삭제하려는 컨텍스트가 현재 어떤 알고리즘에서 사용중이라면 삭제하기 전에 이를 또 통보해줘야 하니 인터페이스가 좀 복잡해 지겠죠.
물론 이 방식은 더 논리적입니다. 말씀하신대로 번역하는 통로가 하나만 있으면 되는 경우 Main 하나만 설정하면 되니까요 ^^
논리성과 단순성 사이에서 저울질하다 현재 채택한 방식이 이겁니다. ㅜㅜ
더 좋은 아이디어가 생각나면 한번 논의해보죠.
물론 플러그인 언로드 될 땐 DeleteTransCtx 를 호출해서 자신이 만든 컨텍스트를 지우시고요.
모든 Algorithm 타입의 플러그인이 현재 위의 방식을 사용합니다.
Algorithm 타입이라도 특별한건 없고 컨텍스트를 하나 이상 생성하고 그것을 소비(?)하는 종류의 모듈입니다.
오히려 번역 객체의 인터페이스들을 구현해야하는 필터나 번역 플러그인보다 간단한 구조입니다.
요약하자면 구현상 복잡성은
Algorithm Plugin < Filter Plugin = Translator Plugin
이렇게 됩니다.
필터 / 번역기의 구분은 플러그인의 성격을 직관적으로 나타내기 위한 것일 뿐 구조는 완전 같습니다.