[ruby-core:47289] Re: [ruby-trunk - Feature #6895] TracePoint API

(2012/08/23 1:22), trans (Thomas Sawyer) wrote:
>>  I understand your proposal.  I use "Thread.new (Thread.start)" analogy
>> >  (and current set_trace_func analogy).  I think two different behavior is
>> >  not good.  Which one do you like?
> Hmm... Well if we can only have one it would have to be the first b/c it gives most flexibility. But I don't understand why we can't have both when the second (TracePoint.trace) would just be a convenience shortcut to the first, i.e.
> 
>   def TracePoint.trace(*events, &block)
>     TracePoint.new(*events, &block).trace
>   end

In some cases, flexibility doesn't improve usability.

I understand that TracePoint.new API improves flexibility.  But it is
more difficult to retrieve it.  For example, users need to consider when
the trace activate.

And I doubt that the flexibility helps users.  Any use-case?


>> >  > Also, I assume that if no events are given as arguments, it includes all events?
>> >  Yes.
>> >  
>> >  >> `eventN' parameter for TracePoint.trace() is set of symbols.  You can specify events what you want to trace.  If you don't specify any events on it, then all events are activate (similar to set_trace_func).
>> >  
>> >  But there is an issue.  Now "all" means same events that set_trace_func
>> >  supports.  But if I add other events like "block invoke", then what mean
>> >  the "all"?
> "All" should mean all. If you add other events then those should be included too. Why would you think not to include your new events?

Compatibility.  But it can be avoid if we add about it in a document.

-- 
// SASADA Koichi at atdot dot net