Avoid Implementing String-based Property Access (a.b) for Type Safety and Performance

[yceffort-naver]

Lodash allows property access using string-based paths like a.b.c.
for example: https://lodash.com/docs/4.17.15#get
While this approach provides flexibility, it comes with significant trade-offs:

1. Performance Overhead: Parsing string paths and performing deep property lookups can be costly in terms of performance.
2. Type Safety Issues: In TypeScript, string-based paths bypass static type checking, reducing type safety and increasing the potential for runtime errors.
3. Limited IDE Support: IDE features like autocomplete, type inference, and error detection don't work well with string paths.

Considering these drawbacks, I propose that @naverpay/hidash should avoid implementing such string-based property access. Instead, we can focus on TypeScript-friendly alternatives that maintain type safety while still providing useful utility functions.

What do @NaverPayDev/frontend think?

[yujeong-jeon]

라이브러리가 지향하는 바에 따라 결정하면 되지만 lodash의 완벽한 대체재가 아니게 될 수는 있습니다.

🎯 Type Safety: Written in TypeScript with complete type definitions

README.md에서 소개한 타입 안정성을 보장하기 위해서라면 제거하는 편이 좋아보입니다.

(제안) A modern TypeScript-first, and performance-focused alternative for Lodash

• 타입스크립트를 우선하겠다는 표현도 들어갔으면 합니다.
  README.md에 차이점이 명시되어 있어야 할거 같습니다.

alternative / replacement 뉘앙스

구분	Alternative	Replacement
전제 조건	기존 옵션이 여전히 사용 가능	기존 옵션이 더 이상 사용되지 않거나 지원 종료
의도	추가적인 선택지를 제공	기존 옵션을 완전히 제거하거나 교체
관계	기존 옵션과 공존 가능	기존 옵션과 공존 불가능
예시	REST와 GraphQL은 대안 관계	HTTPS는 HTTP를 교체

• Alternative는 "추가적인 선택지"를 제공하는 뉘앙스
• Replacement는 "기존 것을 완전히 없애거나 교체"한다는 뉘앙스

[yujeong-jeon]

Translations

1. You can decide according to what the library is aiming for, but it may not be a perfect replacement for the loadash.

   🎯 Type Safety: Written in TypeScript with complete type definitions

   To ensure the stability of the type introduced by README.md , it seems better to remove it.

2. (Suggestions) A modern TypeScript-first, and performance-focused alternative for Lodash

   I hope there is also an expression that I will prioritize type scripts.
   I think the difference should be specified in README.md .