> Its a judgement call, how much to minimize the API.
Yes, that's why we send API proposals on the dev list. And I don't think
I'm absolutely right. If we, as a community, want to have utilities as TS
API, that's what we should do. I'm disappointed that others don't join this
discussion, but if th
We could also change the API so it provided plugins with raw HTTP headers,
and let each plugin parse the headerd. Its a judgement call, how much to
minimize the API.
Scenario 1. We continue to write code without RAII. We have resulting
resource leaks. We (potentially) find a way to put RAII in
I don't see why we want to provide a helmet with TS API mark. Somebody may
make a third party helmet which is better than ours. Can we steal the
design? Can we make a much better one? I'm not sure because that may
require interface change and/or behavior change. Then ours would be
useless. It's not
The analogy I would make is to needing a helmet to ride a motorcycle. You
don' t need it in the strictest sense, but you need it for a reasonable
level of safety. You need RAII for a reasonable level of safety against
resource leaks.
On Thu, Aug 31, 2023 at 1:50 PM Masakazu Kitajo wrote:
> I s
I see your point, but I think we need to draw a line. High-priority
capability is blurry and questionable. We have not *needed* it for years.
> We could support RAII better, but I don't think it's feasible in 10.0.
This implies Cleanup.h will be unnecessary after we make it better.
Not discardin
The utilities in Cleanup.h add RAII capabilities to the TS API. I hope we
don't need to have a debate about the value of RAII.
Certainly, any API can become bloated with too many features. But RAII
seems like a high-priority capability to support. We could support RAII
better, but I don't think
