Hi Benjamin,
> your proposal tries to reify all the possible ways to compare two closures
> (listener code + environment) as data. Another approach, which I personally
> prefer, is to let users define their own matching criteria, i.e.
This is a C API, C doesn't have closures, and we're talking about changing a
minor part of a minor EPICS API. We don't have anything comparable to your
matcher routine in the rest of Base and it would be confusing to introduce
this kind of thing here. I only included all the possibilities I did because
there are valid use-cases to need both flag bits. I don't want to change the
listener API like your proposal does; there is no reason to break user code
unnecessarily, and my version is completely backwards-compatible for existing
errlog listener source code.
> IMO, removing only the first matching list element is unsafe and should
> not be supported.
That behavior is explicitly tested for and relied on in the epicsErrlogTest.c
code. The errlogRemoveListener() routine has behaved like that for a long
time and might actually be relied on in the wild for all we know...
- Andrew
--
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock
- Replies:
- Re: Problem in errlogRemoveListener Michael Abbott
- References:
- Re: Problem in errlogRemoveListener Andrew Johnson
- Re: Problem in errlogRemoveListener Benjamin Franksen
- Navigate by Date:
- Prev:
Re: Problem in errlogRemoveListener Benjamin Franksen
- Next:
PyEpics speed Jeremy Iken
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Problem in errlogRemoveListener Benjamin Franksen
- Next:
Re: Problem in errlogRemoveListener Michael Abbott
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|