I don’t agree with Rob’s assessment. Standardized interfaces is what has
allowed the Java 3P library ecosystem to be so robust.
It takes more design work upfront and you can get things wrong - but it’s a
price and risk worth taking in my opinion.
> On Aug 31, 2021, at 4:02 PM, Amit Saha wrot
On Tue, Aug 31, 2021 at 9:46 PM Robert Engels wrote:
>
> The io.Writer is too low level to be useful. Imagine a logger that wants to
> send an sms on severe errors only.
>
> The best solution is to declare your own logger interface - but similar to
> the collections discussion it would better if
For the specific case of managing long-running polling- or pubsub-based
tasks, I would suggest basically the same pattern that others on the thread
have already given: use a `sync.Map` to associate each task ID with a small
struct containing a `context.CancelFunc` and a channel that can be used
The io.Writer is too low level to be useful. Imagine a logger that wants to
send an sms on severe errors only.
The best solution is to declare your own logger interface - but similar to the
collections discussion it would better if the stdlib declared an ILogger
interface (or similar)
> On Au
I'm trying to learn how debugger works. With the help of this
blog
https://eli.thegreenplace.net/2011/01/27/how-debuggers-work-part-2-breakpoints
I'm able to set breakpoint and continue.
In the next step of learning, I wanted to learn how to extract values of
variables.
But, the dwarf output
Dug a bit further. The way our build works (debian build which copies files
into a build area) meant that 'go vet' was running on the files in 2
different locations. All worked fine in the build area, but in the source
area, it was generating the spurious 'undefined method' error. By filtering
If Logger was an interface it would be pretty large and to some extent
application-specific, which is undesirable.
Instead inject the sink (io.Writer).
This is preferable in every way:
* the interface is small and universal
* it eliminates the coupling with any specific library present and futu
Hmm ... obviously not as simple a problem as I first thought. I'll need to
start with the definitely failing code and reduce it to as simple a case as
possible that still exhibits the problem. Had (wrongly) assumed it would
happen in all cases hence the simple example given initially.
On Friday
