Clojure는 지속적 데이터 구조, 벡터, 맵 및 세트 중 일부에 대해 일시적인 아날로그가 있습니다. 벡터의 경우 pop! 및 conj! 함수가 있으며 지속 벡터의 경우 pop 및 conj과 유사하지만 peek!은 없습니다.왜 엿봄이 없습니다! 클로저의 과도 벡터에 대한 함수?
peek!을 효율적으로 구현할 수없는 기술적 인 이유가 있습니까? 아니면 과도 벡터에 대한 대부분의 유스 케이스에서 필요하지 않은가? 항상 할 수 있습니다
(defn peek! [tvec] (get tvec (dec (count tvec))))
하지만 기본 제공되는 솔루션이 없다는 것이 이상하게 보입니다. 정말 가장 ggroup로 이동 디자인 질문
하지만 FWIW, 내가 peek/peek! 얼마 전에 및 peek!이 과도 벡터 구현을 clojure.lang.IPersistentStack 병렬 새로운 clojure.lang.ITransientStack 인터페이스를 생성하고있는의 간단한 문제가 될 것으로 보인다 제공하는 조사 않았다 그것.
내 생각에 그런 인터페이스가 이미 사용 가능하지 않고 (과도기에 의해 사용되는 경우) 우선 순위가 중요합니다. 싱글 스레드 고속 스택 구현은 Clojure에서 이미 java.util.Stack 형태로 사용 가능하므로 많은 기능을 여기에 놓치지 않았습니다. 통어론적인 편의성과 영구 벡터로의 원활한 변환은 아마도 Clojure-in-Clojure에서 이루어질 것이다.
(투자 수익이 높으면 최종적으로 Java 코드베이스의 관련 부분을 삭제하고 Clojure의 구현으로 대체하는 것이 최종 목표 인 경우에도 Clojure의 Java 측 개선은 의미가 있습니다. 기대 수익률이 낮을수록 프로토콜이 더 보편적으로 사용될 때까지 기다리는 것이 더 합리적 일 수 있습니다. Clojure 자신의 필요에 따라 일시적 처리 기능을 제공하는 현재 사용 가능한 집합은 peek!에 대한 호출이 있었는지 확실하지 않습니다. ggroup - #cllojure와 관련하여 하나의 적절한 대화를 기억합니다. 따라서 수익률이 낮은 것으로 판단 될 수도 있습니다.하지만 풀뿌리 운동을 시작하면 변경할 수 있습니다. :-))
대단히 감사합니다. 도와 줬어. 나는 엿봄이 절실히 필요하지 않다! 기능이 변경되었지만 풀뿌리 캠페인을 시작하는 것이 좋습니다. 당분간 나는 현명한 BDFL이나 그의 중역을 괴롭히지 않을 것입니다. –