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 .AddObject type definition #34

Merged
merged 11 commits into from
Aug 30, 2024
Merged

Conversation

kineticwallet
Copy link
Contributor

No description provided.

@@ -1,4 +1,4 @@
type Constructable<T, Args extends Array<unknown>> = new (...args: Args) => T;
type Constructable<T> = new (...args: Parameters<T>) => T;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

O extends Constructable<T>,
M extends undefined | ExtractKeys<InstanceType<O>, () => void> | true,
I extends keyof U | undefined = undefined
>(object: O, methodName?: M, index?: I, ...args: ConstructorParameters<O>): InstanceType<O>;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth it to note that InstanceType<O> is equivalent to T.

>(object: Constructable<O, Args>, methodName?: M, index?: I, ...args: Args): O;
T,
O extends Constructable<T>,
M extends undefined | ExtractKeys<InstanceType<O>, () => void> | true,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be dropping ((this: O) => void) | ((_: O) => void) from here?

Though we should be using T, not O here if we keep it.

Might be more clear if we use ExtractKeys<T, () => void> rather than ExtractKeys<InstanceType<O>, () => void>

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at Janitor's internals, we don't need ((this: T) => void) | ((_: T) => void>:

https://github.com/howmanysmall/Janitor/blob/af930bf8939b7758b23bf62fb651ab5f348cdc52/src/init.luau#L252

we can see that Janitor warns if the method doesn't exist on the created instance, and it will later do nothing. We should explicitly ban this behavior from our consumers.

Copy link
Owner

@OverHash OverHash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like us to change these over to the explicit T type for clarity. Other than that, looks good 🚀

janitor/index.d.ts Outdated Show resolved Hide resolved
janitor/index.d.ts Outdated Show resolved Hide resolved
kineticwallet and others added 2 commits August 30, 2024 09:23
Co-authored-by: OverHash <46231745+OverHash@users.noreply.github.com>
Co-authored-by: OverHash <46231745+OverHash@users.noreply.github.com>
@kineticwallet
Copy link
Contributor Author

image
InstanceType is needed!?

@kineticwallet
Copy link
Contributor Author

There might be no difference between T and InstanceType, but some sources say its still needed in some cases.https://stackoverflow.com/questions/70364964/difference-in-typescript-between-types-instancetypetypeof-myclass-and-myc

@OverHash
Copy link
Owner

OverHash commented Aug 30, 2024

There might be no difference between T and InstanceType, but some sources say its still needed in some cases.https://stackoverflow.com/questions/70364964/difference-in-typescript-between-types-instancetypetypeof-myclass-and-myc

Sweet, my mistake. Let's use InstanceType then.

Also note that package-lock.json is needed to be updated via npm update.

@kineticwallet
Copy link
Contributor Author

done

@OverHash
Copy link
Owner

What are your thoughts on this? It would remove the need for us to have a useless T and IO type:

	public AddObject<
		O extends Constructable<unknown>,
		M extends undefined | ExtractKeys<InstanceType<O>, () => void> | true,
		I extends keyof U | undefined = undefined,
	>(object: O, methodName?: M, index?: I, ...args: ConstructorParameters<O>): InstanceType<O>;

@kineticwallet
Copy link
Contributor Author

Testing it

@kineticwallet
Copy link
Contributor Author

I would add IO back so its less boilerplate.

@OverHash
Copy link
Owner

I would add IO back so its less boilerplate.

I'd prefer if we keep it out for now -- that way we have three types corresponding to the three parameters. Maybe in the future we add it.

@kineticwallet
Copy link
Contributor Author

image
Having to define undefined is a bit annoying, but it works.

@OverHash
Copy link
Owner

OverHash commented Aug 30, 2024

Having to define undefined is a bit annoying, but it works.

It's required in the luau side, so yeah we have to have it:

local MyClass = {}
function MyClass.new(a, b, c)
	print(`Created with {a}, {b}, {c}`)
	return setmetatable({}, { __index = MyClass })
end

function MyClass:Destroy()
	print("Being destroyed")
end

local a = Janitor.new()
a:AddObject(MyClass, "Destroy", nil, 1, 2, 3)
a:Destroy()

@kineticwallet
Copy link
Contributor Author

the newest version should work, LGTM

@kineticwallet
Copy link
Contributor Author

IO stands for InstanceType of O

@OverHash
Copy link
Owner

OverHash commented Aug 30, 2024

IO stands for InstanceType of O

Can we make it just T? I'm happy to accept it as T.

@OverHash
Copy link
Owner

Thanks for your work ❤️

@OverHash OverHash merged commit 3889d32 into OverHash:master Aug 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants