froydnj opened PR #1389 from define-function-trap-sink
to master
:
Experience with the
define_function
API has shown that returning borrowed slices ofTrapSite
is not ideal: the returned slice represents a borrow on the entireModule
, which makes calling back into methods taking&mut self
a bit tricky.To eliminate the problem, let's require the callers of
define_function
to provideTrapSink
instances. This style of API enables them to control when and how traps are collected, and makes theobject
andfaerie
backends simpler/more efficient by not having to worry about trap collection.This has been discussed in #1184 and #1214. I opted not to go this route because I thought the
&[TrapSite]
version was easier. Experience has shown that was a mistake.
froydnj requested pchickey for a review on PR #1389.
froydnj updated PR #1389 from define-function-trap-sink
to master
:
Experience with the
define_function
API has shown that returning borrowed slices ofTrapSite
is not ideal: the returned slice represents a borrow on the entireModule
, which makes calling back into methods taking&mut self
a bit tricky.To eliminate the problem, let's require the callers of
define_function
to provideTrapSink
instances. This style of API enables them to control when and how traps are collected, and makes theobject
andfaerie
backends simpler/more efficient by not having to worry about trap collection.This has been discussed in #1184 and #1214. I opted not to go this route because I thought the
&[TrapSite]
version was easier. Experience has shown that was a mistake.
pchickey submitted PR Review.
froydnj closed without merge PR #1389.
froydnj reopened PR #1389 from define-function-trap-sink
to master
:
Experience with the
define_function
API has shown that returning borrowed slices ofTrapSite
is not ideal: the returned slice represents a borrow on the entireModule
, which makes calling back into methods taking&mut self
a bit tricky.To eliminate the problem, let's require the callers of
define_function
to provideTrapSink
instances. This style of API enables them to control when and how traps are collected, and makes theobject
andfaerie
backends simpler/more efficient by not having to worry about trap collection.This has been discussed in #1184 and #1214. I opted not to go this route because I thought the
&[TrapSite]
version was easier. Experience has shown that was a mistake.
froydnj merged PR #1389.
Last updated: Nov 22 2024 at 16:03 UTC