다가오는 3.9.0 릴리스에 into가 확정돼서, 제 코드 중 어디에 활용할 수 있을지 찾아보고 있어요.
궁금한 건 이거예요. 너무 많이 쓸 수도 있나요?
예를 들어 제가 만든 이런 확장을 보면요:
extension [Element](items: IterableOnce[Element])
...이걸 다음처럼 넓히면 단점이 있을까요:
extension [Element](items: into[IterableOnce[Element]])
...?
제 확장은 어차피 IterableOnce로 바꾸는 given 변환이 있으면 동작해요. into를 쓰면 경고가 안 뜬다는 차이뿐이고요. 그게 바람직하지 않은 걸까요? 간단히 말해, 유연성을 더 얻으려고 코드 곳곳에 into를 넣으면 안 되는 이유가 뭔가요?
With into now settled for the forthcoming 3.9.0 release, I'm trying to identify parts of my code that could take advantage of it.
What I'm wondering is: Can it be used too much?
As an example, consider these extensions of mine:
extension [Element](items: IterableOnce[Element])
...Would there be a downside to broadening that to:
extension [Element](items: into[IterableOnce[Element]])
...?
My extensions would work regardless with given conversions into IterableOnce. With into, the difference is simply that no warning appears. Is that undesirable? In short, why shouldn't I scatter into throughout my code to gain more flexibilty?
아직 이어진 답글이 없습니다.
안녕하세요, 제가 코드를 바꿀 수 없는 패키지에 다음과 같은 클래스 계층이 있어요: 편하게 쓰려고 Inner를 감싸는 래퍼를 추가하려는데, Inner가 바깥 인스턴스에 의존해서 지금까지는 바깥 클래스의 서브클래스 안에 넣는…
아래 두 표현식을 보니 그리고 똑같이 동작하더군요. 정리를 증명할 때도 마찬가지예요. 서로 바꿔 써도 되나요? 차이가 뭔가요?
각 항목이 문자열 배열을 담는 Map을 만들고 있어요. 타입 선언과 초기화를 한 문장으로 같이 하려면 어떻게 하나요? 제 (단순한) 시도는 이랬어요: 그랬더니 이렇게 나와요:
