Thanks for replying.
But I'm sorry for perhaps I haven't describ clear enough.
The puzzle I have face to is that I HAVE TO create a new Duration type, and
HAVE TO inherit all methods and constants from std.time.Duration.
Because my DEMAND is to inherit and expand std.time.Duration and to hide
std.time.Duration for clients due to the follow limits:
// compile error: cannot define new methods on non-local type time.Duration
func (d time.Duration) Days() float64 {
return float64(d) / float64(Day)
}
I have uploading my code and test case here:
https://github.com/vipally/gx/blob/master/time/duration.go
https://github.com/vipally/gx/blob/master/time/duration_test.go
Could you check and give me some optimize suggestion?
Yet I have finish my demand in my own way, but I feel it not good enough
but I have no more ideas about this:
//re-export std.Duration.consts
const(
Nanosecond Duration = Duration(time.Nanosecond)
...
)
//re-export std.Duration.methods
//re-export std.Duration.Seconds
func (d Duration) Seconds() float64 {
return d.Std().Seconds()
}
So I have printed this topic to report my difficulty on this case by
golang, and hope to get some advises from go authors team.
Thanks again.
在 2016年9月26日星期一 UTC+8下午7:50:30，Axel Wagner写道：
>
> 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 <vip...@gmail.com
> <javascript:>> 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.
