You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Maybe we should ditch the idea of an Eventvalue, and simply have hardware, software, cache, and breakpoint methods directly on Builder. Whatever fields the Event enum variants had would become arguments to those methods.
What's important to preserve here is the property that you can't select an event kind without providing all the necessary information to get a meaningful result - like, say, a breakpoint without an address. If we just let people set perf_event_attr fields directly, that would be a risk. But by making people produce an Event the idea was that you'd make sure they'd filled everything in.
Replacing each Event variant with a method on Builder could accomplish the same goal, and remove the pointless indirection of "first we build the Event; then we wait for them to hand it to us (which is the only thing you can do with an Event anyway); then we move the fields into the perf_event_attr struct." Instead, you'd just have the one Builder method that just does the deed.
The text was updated successfully, but these errors were encountered:
As a user of the API, if you do this, please at least ensure that there is still a single method that can be used with all the event types. Being able to call builder.kind(<literally any event type>) is really quite nice and it would be a shame if that went away. Whether that happens through impl Into<Event> or another trait that's implemented for all events doesn't really matter.
Maybe we should ditch the idea of an
Event
value, and simply havehardware
,software
,cache
, andbreakpoint
methods directly onBuilder
. Whatever fields theEvent
enum variants had would become arguments to those methods.What's important to preserve here is the property that you can't select an event kind without providing all the necessary information to get a meaningful result - like, say, a breakpoint without an address. If we just let people set
perf_event_attr
fields directly, that would be a risk. But by making people produce anEvent
the idea was that you'd make sure they'd filled everything in.Replacing each
Event
variant with a method onBuilder
could accomplish the same goal, and remove the pointless indirection of "first we build theEvent
; then we wait for them to hand it to us (which is the only thing you can do with anEvent
anyway); then we move the fields into theperf_event_attr
struct." Instead, you'd just have the oneBuilder
method that just does the deed.The text was updated successfully, but these errors were encountered: