문제는 .NET 에서 object 은근히 쓴다는것 히익 - return 0;
예) wpf 이벤트 메소드 첫 인자가... 으아니 object잖아 - return 0;
그런짓을 왜 해야되나.. 안 하는게 맞징
ㄴ ㅋㅋㅋ 당연하지 이거 제네릭으로 못만드는데? - dc App
아니 만들어도 이밴트끼리 호환이 안됨 - dc App
사실 꼭 그거 제네릭으로 할 필요 없음.. 그냥 caller 객체를 따로 정해서 그걸 인자로 보내주면 되지 object 굳이 쓴거임 - return 0;
먼 소리임 시그니쳐 써봐 - dc App
그리고 그 예제가 동적타입이잖아 sender에 뭐가 올지 모르니까 - dc App
새로 글 쌀테니 이따가 보셈
https://stackoverflow.com/questions/1437699/in-a-c-sharp-event-handler-why-must-the-sender-parameter-be-an-object
글 새로 쌀 필요도 없네 스택오버플로우에 관련 논의가 있음
이미 모든 클래스가 object를 상속 중인데 굳이 그걸 또 쓰는 싸이코 같은 새끼가 있냐?
아니 그러니까 그렇게 쓰면 이밴트끼리 호환이 안된다고 했잖아 - dc App
Click 이밴트를 타입마다 구현해야 한다고 - dc App
그러면 호환시키고 싶은 이벤트끼리 인터페이스 만들어서 묶으면 되지... 애초에 핸들러를 재탕삼탕 한다는거 자체가 그다지 바람직하다는 생각이 안 듬
그리고 그게 왜 제네릭으로 안됨? 그건 이해가 안되는데 .NET이 그걸 지원하느냐 마느냐를 떠나서 당연히 구현할 수 있지 않을까
아니 만들어도 이밴트끼리 호환이 안됨 | 이라고 위에서 말했음 - dc App
그렇게 묶어서 타입이 복잡해지는거보다 object, EventArgs 패턴으로 묶는게 더 좋다고 봤으니까 이렇게 만든거지 - dc App
그래 그게 마음에 안 든다는거임
ㅇㅇ 이게 맘에 안들면 못쓰겠네 FCL부터 UWP까지 다 이 패턴으로 통일했는데 - dc App
근데 시발 기호차이인걸 가지고 미개하다고 해야하냐 - dc App
아니 강타입 언어에서 그런 편의를 위해서 타입 시스템에 존나게 큰 구멍을 뚫어놓은거잖음. 그런거 봐주기 시작하면 자바도 할만한 언어임
뭐가 큰 구멍임 Object에선 항상 Type을 얻는데 is as쓰면 되잖아 - dc App
is as나 switch 안쓰고 걍 캐스팅 하는거면 지가 Exception 감당한다는거지 - dc App
Type 얻어서 다운 캐스팅 하고 이런 패턴이 Object 가 비판 당하는 제일 큰 이유인디. 그것 때문에 흑마술 부리기 시작하다가 코드 꼬이는..
그럼 아얘 다운캐스팅 없는 언어로 가야지 - dc App
다운캐스팅이 가능한거랑, 그걸 아예 강제/권장하는건 다르다고 봄. 내가 Object를 싫어하는 이유가 그거임. Up - Down 루틴을 강제함
Object로 통일하면 GetHashCode ToString GetType 같은걸 통합적으로 관리가 가능함 - dc App
그리고 C# 에서 권장하는 캐스팅은 is as처럼 type safe한 방식임 - dc App
패턴매칭같은거지 - dc App
그 점은 내가 C#이랑 Java랑 닮아서 둘다 싫어지는 부분..
물론 너 말하는거 처럼 단점도 있는데 분명 장점도 있음 - dc App
너는 그게 싫으니 안하는거고 나는 이게 좋으니 하는거뿐 - dc App
문제는 .NET 에서 object 은근히 쓴다는것 히익 - return 0;
예) wpf 이벤트 메소드 첫 인자가... 으아니 object잖아 - return 0;
그런짓을 왜 해야되나.. 안 하는게 맞징
ㄴ ㅋㅋㅋ 당연하지 이거 제네릭으로 못만드는데? - dc App
아니 만들어도 이밴트끼리 호환이 안됨 - dc App
사실 꼭 그거 제네릭으로 할 필요 없음.. 그냥 caller 객체를 따로 정해서 그걸 인자로 보내주면 되지 object 굳이 쓴거임 - return 0;
먼 소리임 시그니쳐 써봐 - dc App
그리고 그 예제가 동적타입이잖아 sender에 뭐가 올지 모르니까 - dc App
새로 글 쌀테니 이따가 보셈
https://stackoverflow.com/questions/1437699/in-a-c-sharp-event-handler-why-must-the-sender-parameter-be-an-object
글 새로 쌀 필요도 없네 스택오버플로우에 관련 논의가 있음
이미 모든 클래스가 object를 상속 중인데 굳이 그걸 또 쓰는 싸이코 같은 새끼가 있냐?
아니 그러니까 그렇게 쓰면 이밴트끼리 호환이 안된다고 했잖아 - dc App
Click 이밴트를 타입마다 구현해야 한다고 - dc App
그러면 호환시키고 싶은 이벤트끼리 인터페이스 만들어서 묶으면 되지... 애초에 핸들러를 재탕삼탕 한다는거 자체가 그다지 바람직하다는 생각이 안 듬
그리고 그게 왜 제네릭으로 안됨? 그건 이해가 안되는데 .NET이 그걸 지원하느냐 마느냐를 떠나서 당연히 구현할 수 있지 않을까
아니 만들어도 이밴트끼리 호환이 안됨 | 이라고 위에서 말했음 - dc App
그렇게 묶어서 타입이 복잡해지는거보다 object, EventArgs 패턴으로 묶는게 더 좋다고 봤으니까 이렇게 만든거지 - dc App
그래 그게 마음에 안 든다는거임
ㅇㅇ 이게 맘에 안들면 못쓰겠네 FCL부터 UWP까지 다 이 패턴으로 통일했는데 - dc App
근데 시발 기호차이인걸 가지고 미개하다고 해야하냐 - dc App
아니 강타입 언어에서 그런 편의를 위해서 타입 시스템에 존나게 큰 구멍을 뚫어놓은거잖음. 그런거 봐주기 시작하면 자바도 할만한 언어임
뭐가 큰 구멍임 Object에선 항상 Type을 얻는데 is as쓰면 되잖아 - dc App
is as나 switch 안쓰고 걍 캐스팅 하는거면 지가 Exception 감당한다는거지 - dc App
Type 얻어서 다운 캐스팅 하고 이런 패턴이 Object 가 비판 당하는 제일 큰 이유인디. 그것 때문에 흑마술 부리기 시작하다가 코드 꼬이는..
그럼 아얘 다운캐스팅 없는 언어로 가야지 - dc App
다운캐스팅이 가능한거랑, 그걸 아예 강제/권장하는건 다르다고 봄. 내가 Object를 싫어하는 이유가 그거임. Up - Down 루틴을 강제함
Object로 통일하면 GetHashCode ToString GetType 같은걸 통합적으로 관리가 가능함 - dc App
그리고 C# 에서 권장하는 캐스팅은 is as처럼 type safe한 방식임 - dc App
패턴매칭같은거지 - dc App
그 점은 내가 C#이랑 Java랑 닮아서 둘다 싫어지는 부분..
물론 너 말하는거 처럼 단점도 있는데 분명 장점도 있음 - dc App
너는 그게 싫으니 안하는거고 나는 이게 좋으니 하는거뿐 - dc App