I think you are overcomplicating things for yourself. Just use the solution Jan has provided. If you don't want people to need to import time additionally, re-export the constants from your own package. No need to define a new type.
On Mon, Sep 26, 2016 at 11:17 AM, Ally Dale <vipa...@gmail.com> wrote: > In final words, the KEY problem of my topic is: > It's easy to extending exists public types by redefine or use struct's > no-name embeding in Golang. > The new types will inherit all data and public methods from the old > package. > But there is NO WAYS to inherit public consts and variables defined from > old package. > I don't understand what you mean by this. You can simply do const Foo = somepackage.Foo go get a constant in your package of the same type and value as the one from another package. Constants aren't bound to any type, they *have* a type. The type doesn't "know" what constants you define with it, just as variables don't know it. As such, talking about "inheriting constants or variables" doesn't make a lot of sense, they have nothing to do with types. So I wonder if Go authors can explain how can we achieve this demand. > I am not sure there really *is* a demand. You presented a problem and have been given a solution. I don't understand why you think that solution isn't good enough. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
