Replies: 2 comments
-
You can abstract that away from the user by adding a |
Beta Was this translation helpful? Give feedback.
-
I do think that would be a good approach. I'm just not sure if there's a need for it yet. I'm trying to keep YAGNI in mind and not introduce too many features that do not bring value, as they will introduce complexity and make testing, maintenance, and changes down the road harder. Just because we can build it doesn't mean we should 😛. I think for now I'll leave this discussion open and see if it gets any upvotes or other comments. This project is still new so it doesn't have a whole lot of community involvement/feedback yet (I really appreciate yours though santisq 😊), and I've just been going off my initial idea and gut feelings. There are other features that will provide more value that I'm going to prioritize while still mulling this over and waiting for more feedback. |
Beta Was this translation helpful? Give feedback.
-
This comment in issue #25 suggested converting the
TipCategory
enum to a flags enum so a tip can belong to multiple categories.If you would find this feature of a tip belonging to multiple categories useful, upvote this idea.
Hmmmm, that's not a bad idea. My main hesitation right now is I'm not yet certain how we will want to use Categories in the future. If we use a flags enum, then users will need to know that in order to properly work with Categories. That is, using your example above, if they did
Get-PowerShellTip -All | Where-Object { $_.Category -eq Performance }
that would not return your tip, since it has 2 categories defined. They would need to use$_.Category.HasFlag('Performance')
.It's not a big problem, but something they would need to be aware of. Changing the property name from
Category
toCategories
might be enough of an indicator to help make it more obvious. I'm going to think on this some more. Any other feedback is welcome 🙂Beta Was this translation helpful? Give feedback.
All reactions