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

Proposal: A propertytype(s) function #55001

Open
Tortar opened this issue Jul 2, 2024 · 2 comments
Open

Proposal: A propertytype(s) function #55001

Tortar opened this issue Jul 2, 2024 · 2 comments
Labels
kind:feature Indicates new feature / enhancement requests

Comments

@Tortar
Copy link
Contributor

Tortar commented Jul 2, 2024

Just like propertynames, I think a propertytypes function could exist to be able to work in tandem with propertynames when one wants to provide/align to an interface by overloading when fieldtypes is not suitable. I think it should work as propertynames, namely by accepting an instance instead of type. And by default it could fallback to fieldtypes(typeof(x)).

@mikmoore
Copy link
Contributor

mikmoore commented Jul 2, 2024

An improvement over this FR might be to only define the singular Base.propertytype(type, property) = typeof(getproperty(type, property)) (fallback featured here) that returns the type of a specific single property. Given that there is no getproperties function that gets all properties, I don't imagine it's very useful to get the type of every property at once. It also seems like a maintenance annoyance to need to keep the property order matched for propertynames and propertytypes. And some types may have a large/indefinite list of dynamic properties, for which the plural propertytypes doesn't even make sense.

That said, I think that the getproperty overloading business is already messy as it is. One should overload propertynames whenever one changes the properties accessible to getproperty/setproperty (and if those disagree, which should be used to define the propertynames?). Adding yet another function to maintain seems annoying. It will take a lot of time and effort to bring existing types in the ecosystem (or even the majority of them) back to spec after such an addition as propertytypes.

In general, I find non-default property management very tedious and it's not something I use in my own code. X.Y just isn't much nicer than Y(X) yet it's much harder to code and maintain. So I can't say I'm the most relevant party to this discussion in the first place.

@Tortar
Copy link
Contributor Author

Tortar commented Jul 2, 2024

Now that I think at what you say, maybe propertytypes could default to Tuple(typeof(getproperty(x, n)) for n in propertynames(x)) which would be okay to many types which already overload propertynames or even to Tuple(propertytype(x, n)) for n in propertynames(x)) if propertytype is implemented.

@nsajko nsajko added the kind:feature Indicates new feature / enhancement requests label Jul 2, 2024
@Tortar Tortar changed the title Proposal: A propertytypes function Proposal: A propertytype(s) function Jul 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:feature Indicates new feature / enhancement requests
Projects
None yet
Development

No branches or pull requests

3 participants