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

Infer function types when no @param or @return tags are present #157

Open
YetAnotherClown opened this issue Oct 16, 2024 · 0 comments
Open
Labels
enhancement New feature or request extractor

Comments

@YetAnotherClown
Copy link
Collaborator

Allow the use of @function and @method to explicitly tell Moonwave whether an inferred function is a method or not by inferring types when no @param or @return tags are present within the doc comment.

Why

Currently, the way users tell Moonwave whether to infer the types of a function is by omitting the @function and @method tags. By doing this, users are left unable to explicitly state the name of their doc entry and whether it is a method or not. Sometimes, users do want the ability to do both of these things while still inferring the types of their functions.

Considerations

FunctionDeclarations with a Method Colon

In this case, it should infer the types, but it should not ignore the first parameter.

--- @method bar
--- @within foo
function foo:bar(a: number, b: string)

end

Moonwave should keep all parameters when parsing a FunctionDeclaration with a method colon.

Parameter/Return Tags with Empty Types

@parameter and @return tags should be ignored if their type field is empty. This is to retain the current behavior as seen below.

--- @within foo
--- @param a -- This is a comment
--- @param b -- This is another comment
function foo:bar(a: number, b: string)

end

Use Case Examples

Inlined Functions

A common pattern to inline functions makes it difficult to get desirable results from Moonwave doc comments.

Consider this use case from Jecs here, modified to have a Moonwave doc comment.

--- @within world
local function world_entity(world: World): i53
	local entityId = (world.nextEntityId :: number) + 1
	world.nextEntityId = entityId
	return entity_index_new_id(world.entityIndex, entityId + EcsRest)
end

Here is what we want:

  • This to be parsed as a method by Moonwave
  • The method name to be entity
  • Parameter and return types to be inferred, but ignore the first parameter

Currently, we're unable to get any three of these results with this pattern. We can fix all three with this change, by explicitly stating it is a method and explicitly stating the name in a @method. Moonwave will also know to ignore the first parameter if types are being inferred from a FunctionDeclarations with a method colon, e.g. function foo:bar().

Methods Within Type Definitions

While not supported by Moonwave, this could be worthwhile syntax to support in Moonwave and we should consider future possibilities.

type Foo = {
	--- @method bar
	--- @within foo
	bar: (self: Foo, a: number, b: string) -> ()
}

If Moonwave would be to support this syntax, without the --- @method bar with the changes proposed in this issue, it would not be obvious that this is meant to be a method. In this case, we can explicitly tell Moonwave we want this to be a method and to ignore self: Foo.

@YetAnotherClown YetAnotherClown added enhancement New feature or request extractor labels Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request extractor
Projects
None yet
Development

No branches or pull requests

1 participant