[제안] @reservedWord 메서드의 네이밍 변경

[BOBx5]

제안

새롭게 적용한 @예약어(e.g. @byte(...)) 방식을

PascalCase + 동사형 (e.g AppendByte(...)) 으로 변경 제안합니다.

사유

사용자 적응 방해

개인적으로 라이브러리의 사용자 인기 및 적용은

BCL 사용 경험과 가장 유사할수록 유리하다고 생각합니다.

그에 반해, 예약어를 메서드로 사용하는 개념이 기존 사용경험과 달라 굉장히 이질적으로 느껴집니다.

라이브러리 유지보수 측면

라이브러리 자체적으로 제안하는 내부 코드컨벤션으로 예약어의 메서드 사용이 제안되지 않는 상태에서,

일부분에 대해서만 예약어를 메서드로 사용하는 것이 라이브러리의 일관성을 해칠 수 있다고 생각합니다.

합리적인 이유로 내부 코드컨벤션으로 제안되고 합당하다면,

해당 내용을 문서화하여 사용자에게 전달하는 것이 더 바람직하다고 생각합니다.

제안 사항

예약어 메서드 변경

BCL에서 제안하는 PascalCase + 동사형 메서드 형태로의 변경을 제안합니다.

• @short(...) => AppendShort(...)
• @int(...) => AppendInt(...)
• @long(...) => AppendLong(...)
• @ushort(...) => AppendUshort(...)
• @uint(...) => AppendUint(...)
• @ulong(...) => AppendUlong(...)
• @byte(...) => AppendByte(...)
• @bytes(...) => AppendBytes(...)
• @class(...) => AppendClass(...)
• @string(...) => AppendString(...)

예약어 메서드의 적용

예약어를 사용한 메서드 설계가 어떤 부분에 있어선 매우 직관적이고 편리할 수 있다는 점을 수용하되,

본 라이브러리가 아닌 Extension형 누겟 패키지로 별도로 생성하고

사용자 편의에 따라 추가하여 사용할 수 있도록

동일한 네임스페이스 내에서 Extensions 메서드로 사용될 수 있도록 하는게 좋을 것 같습니다.

using BytePacketSupport;
using BytePacketSupport.Extensions.ReservedWords;

namespace Sample;
public static class Program
{
    public static void Main()
    {
        var packet = new PacketBuilder()
            // BytePacketSupport
            .AppendShort(1) 
            .AppendInt(2) 
            .AppendLong(3) 
            .AppendUshort(4) 
            .AppendUint(5) 
            .AppendUlong(6) 
            .AppendByte(7) 
            .AppendBytes(new byte[] { 8, 9, 10 }) 
            .AppendString("Hello, World!") 
            .AppendClass(new SampleClass()) 

            // BytePacketSupport.Extensions.ReservedWords
            .Short(1) 
            .Int(2) 
            .Long(3) 
            .Ushort(4) 
            .Uint(5) 
            .Ulong(6) 
            .Byte(7) 
            .Bytes(new byte[] { 8, 9, 10 }) 
            .String("Hello, World!") 
            .Class(new SampleClass());
            // or
            .@short(1) 
            .@int(2) 
            .@long(3) 
            .@ushort(4) 
            .@uint(5) 
            .@ulong(6) 
            .@byte(7) 
            .@bytes(new byte[] { 8, 9, 10 }) 
            .@string("Hello, World!") 
            .@class(new SampleClass());
    }
}

참조 문서

일반적인 C# 코드 규칙

.NET C# Coding Style

[lukewire129]

어느정도 납득이 가는 말씀이셔서..
으으음...

[dimohy]

관련 내용을 제안한 입장에서 조금 주장을 해보자면,

메서드 호출의 느낌 보다는 패킷을 조합하는 느낌으로 (예를 들어 에뮬레이터에서 옵코드를 동일한 개념으로 메서드로 표현하기도 합니다) 바라보면 어떨까 합니다.

   pb
   .@byte (1)
   .@byte (2)
   .@byte (3)

은 3회의 메서드 호출이 아니라 (byte)[1, 2, 3]를 의미한다고 보는 것이죠.

이런 형태가 일반적인 메서드 네이밍은 아니고 이렇게 표현하는 것이 어색한 분들도 꽤 있을 것 같지만
패킷을 구성한다는 관점에서 이것만큼 직관적일 수 있나 싶을 정도로 저는 괜찮습니다. 물론 일반 메서드 네이밍과 이질적으로 다르기 때문에 불편한 분도 꽤 있을 것 같습니다.

이와 다르게 byte[] 확장 메서드의 경우 byte[]의 의미는 패킷만을 의미하지 않기 때문에 @byte()는 부적절하고 AppendByte()으로 사용하는 것이 어떨까 생각합니다.

---

그나저나 @BOBx5 님이 애정을 가지고 아이콘을 추천해주셨는데 너무 마음에 듭니다. 기여자로 포함되어야 할 것 같은데 @lukewire129 님 생각은 어떠세요?

[lukewire129]

저는 개인적으로
@byte든 AppendByte든 둘 다 안고 가는 편이 좋다고 생각이듭니다.

@BOBx5 님께서 말씀해주신 기존 BCL 라이브러리를 얘기해주시면 예를 들었고

@dimohy 님께서 제시해주신 @예약어방식으로는 기존에 사용해왔던 느낌보단 직관적이다보니 요즘 스타일느낌이
들었습니다.

@예약어와 Append** 타입을

확장메서드와 PacketBuilder클래스와 관계없이 둘 다 사용하는건 불가능하진 않아서 둘다 그냥 공존하면 안될까? 라는 생각이 들었거든요..

---

이와 다르게 byte[] 확장 메서드의 경우 byte[]의 의미는 패킷만을 의미하지 않기 때문에 @byte()는 부적절하고 AppendByte()으로 사용하는 것이 어떨까 생각합니다.6bce7)

AppendHelper 클래스에 있는 확장 메서드쪽에 @예약어 대신 Append*말씀하시는거죠?

[lukewire129]

@BOBx5 컨트리뷰터든...뭐든 이 저장소에 이름을 남겨드리고싶은데.. 시간되시면 리드미에 점 하나만이라도...

[lukewire129]

#9

투표 진행 중입니다.! 서두르세요~!

[RainyLens]

혹시 Append<T>(T value)는 어떨까요?
T의 제약 사항을 struct 내지는 IFormattable로 하는 방법도 있지 않을까 싶습니다.

[lukewire129]

예를들면

Append(0x50)

이런식으로 말씀이신가요??

[RainyLens]

넵 맞습니다!
내부로는 Append<byte>((byte)0x50)의 느낌이 되지 않을까 싶어요.

[RainyLens]

저도 CLS Compliant의 느낌으로 제안을 드리긴 했었는데요,
그게 @BOBx5 님께서 말해주신 BCL style 을 따르자고 하신 의견에 동의하는 의견이었습니다....만!
가만 생각해보니까 굳이 그렇게 해야 하나? 라는 생각도 조금 들었구요.
게다가 @lukewire129 님께서 처음 닷넷데브에 예시로 보여주신 코드는 전부 Append() 였기도 하고요.
기본 빌트인으로 제공하는 type 외에를 사용하려면 커스텀화도 고려해서 Append<T>(func<PacketBuilder,T>)를 받아서 미들웨어처럼 동작하게 되어도 될 것 같다는 느낌도 들었습니다.
(물론 기본값은 Serialize를 거쳐서 넣겠지만... 혹시 모르잖아요?)

[lukewire129]

Append(0x50)

엇 왜이렇게 써져있지..모바일로 써서그런가..
아무튼..

혹시 미들웨어처럼 동작한다는게
좀 깊이 어떻게 동작이된다는건지좀알수있을까요..!

[RainyLens]

제안사항이 어쩌다보니 두개가 되어버렸네요..

이 토픽에 대한 의견

저는 AppendUInt64()을 좀 더 선호하고
확장메서드로 @ulong() 으로 두는 것을 지지합니다.

대체 제안

결론부터 말씀드리자면

Append()의 꼴을 버리지 않을 수도 있지 않을까요?

입니다.

Append<T>(T value)  where T : struct, IFormattable

으로,
예전에 기존 예시로 올려주셨던 것과 같이 Append()의 모양을 보존하는 건 어떨까요? 의 맥락이었습니다.
인 경우에는 T value의 T만 자명해지면 생략 가능해질 테니까요.

추가 사항

라이브러리에서 제공하는 직렬화 외에도

Func<T,TResult>() , (즉 이 경우엔 T : typeof(value), TResult : Byte)
등을 이용해

임의 추가하는 인터페이스를 노출하는 것도 괜찮지 않을까 하여 제안드린거였습니다.

class Something
{
    public int Value1 { get; set; }
    public int Value2 { get; set; }
}

이 중에서 Value1만 직렬화 하고 싶은 경우도 있을테니까요.
단순한 케이스엔 Append(Something.Value1) 로 해도 되긴 하지만요.

• 사용 예시(메서드명은 임의입니다.)

 var packet = new PacketBuilder()
 .Append(1)
 .AppendAs((something) => (Byte)something.Value1)

[lukewire129]

Append를 두게되면..많은 편안함을 느낄 수 도있겠군요..
그치만 지금 Appendulong AppendInt64, @Ulong 이런식의 3가지의 타입이 존재하고있는 상태에서

Append의 도입은..혼란을 야기할것같네요...

ps..추가사항 때문에 무조건 있는게 맞을거 같기도하고...

[lukewire129]

3.0.0 버전부터는
AppendInt, @int, AppendInt32를 기본으로 가기보단

Append 로 기본으로 가고 확장으로 전부 이동하였습니다.