Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #998 - Resolved parameter properties by TMP. #999

Merged
merged 1 commit into from
Mar 7, 2024
Merged

Conversation

samchon
Copy link
Owner

@samchon samchon commented Mar 7, 2024

When declare a class type with public parameter properties, and the class type has some private member variables too, the public parameter properties had not identified by typia when the class type casted to a pritmitive object type through TMP type like Primitive or Resolved.

It was because TypeScript compiler API still consider the public members as parameter properties even when converted to the primitive object type through TMP (type meta programming) like Resolved<T>. Ths PR fixes the bug, by considering the special case of the TypeScript compiler API, so that same bug would not be occured more.

For reference, if there's not any private members or no parameter properties being utilized in a class type, no error be occured. This is the extremely rare case I hadn't known. Thanks for @hambergerpls to reporting such special case.

class Foo1 {
  private _y: string;
  constructor(public readonly x: string) {
    this._y = "y";
  }
}
const foo: Foo1 = new Foo1("x");
const cloned: Resolved<Foo1> = typia.misc.clone(foo);

// it came error because `typia` could not identify
// the pritmive type cased parameter propertized class type
// through TMP (type meta programming)
typia.assertEquals(cloned);

When declare a class type with public parameter properties, and the class type has some private member variables too, the public parameter properties had not identified by `typia` when the class type casted to a pritmitive object type through TMP type like `Primitive` or `Resolved`.

It was because TypeScript compiler API still consider the public members as parameter properties even when converted to the primitive object type through TMP (type meta programming) like `Resolved<T>`. Ths PR fixes the bug, by considering the special case of the TypeScript compiler API, so that same bug would not be occured more.

For reference, if there's not any private members or no parameter properties being utilized in a class type, no error be occured. This is the extremely rare case I hadn't known. Thanks for @hambergerpls to reporting such special case.

```typescript
class Foo1 {
  private _y: string;
  constructor(public readonly x: string) {
    this._y = "y";
  }
}
const foo: Foo1 = new Foo1("x");
const cloned: Resolved<Foo1> = typia.misc.clone(foo);

// it came error because `typia` could not identify
// the pritmive type cased parameter propertized class type
// through TMP (type meta programming)
typia.assertEquals(cloned);
```
@samchon samchon added bug Something isn't working enhancement New feature or request labels Mar 7, 2024
@samchon samchon self-assigned this Mar 7, 2024
@samchon samchon merged commit 28b7489 into master Mar 7, 2024
2 of 3 checks passed
@samchon samchon deleted the features/meta branch March 7, 2024 19:19
samchon added a commit to samchon/nestia that referenced this pull request Mar 7, 2024
…adjustment.

As that issue is extremely rare case but critical when used in the SDK level, adjust and enforce latest version of `typia`.
samchon added a commit to samchon/nestia that referenced this pull request Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant