duanshaiduhao2471 2016-11-17 12:13
浏览 79
已采纳

上下文接口设计

My question is about a design choice for the Context interface. If I want to create a child context from a parent I can do something like:

child, cancel := context.WithTimeout(parent, timeout)

Wouldn't it be nicer if WithTimeout was part of the interface, so that we could simply write:

child, cancel := parent.WithTimeout(timeout)

It seems so much cleaner to me. It is shorter, and there is no need to import context.

Why are the functions to produce child contexts not part of the Context interface?

  • 写回答

2条回答 默认 最新

  • dsqbh42082 2016-11-17 15:57
    关注

    This is the context.Context type:

    type Context interface {
        Deadline() (deadline time.Time, ok bool)
        Done() <-chan struct{}
        Err() error
        Value(key interface{}) interface{}
    }
    

    It's simple. If you were to write an implementation of it, could you do it? Yes, easily. As there are no "setter" methods, each method can just return a default / zero value, and it's a "valid" implementation. That's exactly what the background and TODO contexts do (context.Background() and context.TODO()).

    If you would add the functions that derive new context from an existing one (e.g. context.WithCancel(), context.WithDeadline() etc.) as part of the Context interface itself, that would require to provide a (valid) implementation for all, which is not feasible; and also all of them at the same time is rarely needed, so it would be a waste of resources.

    Extensions are responsible to add the implementations. If you look at how the context package is implemented: context/context.go, you'll see different context.Context implementations for the different "derivatives" or "extensions":

    // An emptyCtx is never canceled, has no values, and has no deadline. It is not
    // struct{}, since vars of this type must have distinct addresses.
    type emptyCtx int
    
    
    // A cancelCtx can be canceled. When canceled, it also cancels any children
    // that implement canceler.
    type cancelCtx struct {
        Context
    
        done chan struct{} // closed by the first cancel call.
    
        mu       sync.Mutex
        children map[canceler]bool // set to nil by the first cancel call
        err      error             // set to non-nil by the first cancel call
    }
    
    // A timerCtx carries a timer and a deadline. It embeds a cancelCtx to
    // implement Done and Err. It implements cancel by stopping its timer then
    // delegating to cancelCtx.cancel.
    type timerCtx struct {
        cancelCtx
        timer *time.Timer // Under cancelCtx.mu.
    
        deadline time.Time
    }
    
    // A valueCtx carries a key-value pair. It implements Value for that key and
    // delegates all other calls to the embedded Context.
    type valueCtx struct {
        Context
        key, val interface{}
    }
    

    Obviously we can make up other useful extensions for context.Context which are not in the context package. If you have a new idea, would you also add that to the Context interface? That would break all existing implementations, as obviously your new idea is not implemented in others' current implementations.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论
查看更多回答(1条)

报告相同问题?

悬赏问题

  • ¥60 pb数据库修改或者求完整pb库存系统,需为pb自带数据库
  • ¥15 spss统计中二分类变量和有序变量的相关性分析可以用kendall相关分析吗?
  • ¥15 拟通过pc下指令到安卓系统,如果追求响应速度,尽可能无延迟,是不是用安卓模拟器会优于实体的安卓手机?如果是,可以快多少毫秒?
  • ¥20 神经网络Sequential name=sequential, built=False
  • ¥16 Qphython 用xlrd读取excel报错
  • ¥15 单片机学习顺序问题!!
  • ¥15 ikuai客户端多拨vpn,重启总是有个别重拨不上
  • ¥20 关于#anlogic#sdram#的问题,如何解决?(关键词-performance)
  • ¥15 相敏解调 matlab
  • ¥15 求lingo代码和思路