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

customtype: add ability to register any custom type #27

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

bobheadxi
Copy link

@bobheadxi bobheadxi commented Jul 24, 2024

This change extends #25 to allow any type to be configured with a custom AST representation, and demonstrates this by migrating the existing time.Time handling to use this - see stdtypes.go for example. The existing time.Time asserts that the functionality remains unchanged.

This is useful for any type in the same situation as time.Time, including type aliases of time.Time

This could be useful for #21 and #11, allowing users to bring their own representations of types, though it currently does not allow you to override types that are already registered.

  • By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.


// Is indicates if the given reflect.Type has a custom AST representation
// generator registered.
func Is(rt reflect.Type) (func(any) ast.Expr, bool) {
Copy link
Member

Choose a reason for hiding this comment

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

How about keeping this in the same top-level valast package? e.g. valast.RegisterType, valast.IsType - that seems nicer to me

Copy link
Author

Choose a reason for hiding this comment

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

I'm not sure valast.IsType really works because this only applies to a super narrow subset of things right now 🤔 Additionally a subpackage keeps the scope of the access to the types map clear

But, WDYT about adding valast.RegisterType as an alias for customtype.RegisterType? I've seen this used in various libraries for exposing some internal stuff to consumers

Copy link
Author

Choose a reason for hiding this comment

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

Just pushed a commit, PTAL!

@slimsag
Copy link
Member

slimsag commented Jul 24, 2024

looks great, I only have one minor comment but otherwise happy with that approach. Let me know when you update & want this merged/a new version released.


t, ok := customTypes[rt]
return t, ok
}
Copy link
Member

Choose a reason for hiding this comment

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

sorry @bobheadxi I think I should've been more clear - my point is I'd rather not have a tiny 35-line one-file package and would prefer this just lives in the root under a customtype.go file

does that make sense?

Copy link
Author

@bobheadxi bobheadxi Jul 25, 2024

Choose a reason for hiding this comment

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

I mentioned some reasoning in #27 (comment) - it makes the interface to the rest of the valast codebase clear, and avoids adding globals to the root package internally. IMO that's a strong reason to make this a separate subpackage

bobheadxi added a commit to sourcegraph/sourcegraph-public-snapshot that referenced this pull request Aug 10, 2024
#63959)

This change follows
https://github.com/sourcegraph/sourcegraph/pull/63858 by making the
_all_ subscriptions APIs read and write to the Enterprise Portal
database, instead of dotcomdb, using the data that we sync from dotcomdb
into Enterprise Portal.

With this PR, all initially proposed subscriptions APIs are at least
partially implemented.

Uses hexops/valast#27 for custom `autogold`
rendering of `utctime.Time`

Closes https://linear.app/sourcegraph/issue/CORE-156
Part of https://linear.app/sourcegraph/issue/CORE-158

## Test plan

- [x] Unit tests on API level
- [x] Adapters unit testing
- [x] Simple E2E test:
https://github.com/sourcegraph/sourcegraph/pull/64057
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