type-embeded consts and variables request

[Ally Dale]

Hi all,

I want to know why Golang do not have type-embeded consts or variables (Just like static values and method build-in classes in object oriented languages like C++)

This feature helps us define type-shared valuse, and do not increase size of instanced objects. Unfortunately Golang do not have this feature, and this made us difficult to extend an exsists package outside the origin ones.

For example, type std.time.Duration is a well-designed type to mesure time, but package std.time has pre-defined time period consts from Nanosecond to Hour, but I found I need some more time period consts such as Day or Week.

So I tried to extend my own Duration type from std.time.Duration:

type Duration time.Duration

And then, I have my own wonderfull Duration type benefit from std.time.Duration.

But the trouble is, I can't inherit the corresponding consts defined for std.time.Duration in package std.time.

So I have to define my own time period consts like this:

const (

Nanosecond = Duration(time.Nanosecond)

Microsecond = Duration(time.Microsecond)

Millisecond = Duration(time.Millisecond)

Second = Duration(time.Second)

Minute = Duration(time.Minute)

Hour = Duration(time.Hour)

Day = 24 * Hour

Week = 7 * Day

)

This make my code ugly.

Exactly, I desired my extension code can be like this:

type Duration time.Duration

const Duration.Day = Duration(time.Duration.Hour*24)

const Duration.Week = Duration(Duration.Day*7)

[Jan Mercl]

On Sun, Sep 25, 2016 at 6:07 PM Ally Dale <vip...@gmail.com> wrote:

> Exactly, I desired my extension code can be like this:
type Duration time.Duration
const Duration.Day = Duration(time.Duration.Hour*24)
const Duration.Week = Duration(Duration.Day*7)

I'm perhaps missing something, but you can simply define your own typed constants (of type time.Duration) w/o "extending" type time.Duration.

        const (

                Day = time.Hour*24

                Week = Day*7

        )

BTW: Note that the above values of Day and Week constants are incorrect. That's why they do not exist in package time.

--

-j

[Ally Dale]

I think that is not a good idea.

First of all, I can't define these consts everywhere,so I have to create a new package(eg:mytime) to define them.

And then, client package may use like this:

import(

"time"

".../mytime"

)

dur2WeeksAnd7Hours := mytime.Week*2+time.Hour*7

I think this code may make the clients crazy...

在 2016年9月26日星期一 UTC+8上午12:21:55，Jan Mercl写道：

[Ally Dale]

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.

So I wonder if Go authors can explain how can we achieve this demand.

Or we need another enum type to instead current consts define style?like this,

type EnumDuration enum{

Nanosecond = 1

     Microsecond = 1000 * Nanosecond

     Millisecond = 1000 * Microsecond

     Second = 1000 * Millisecond

     Minute = 60 * Second

     Hour = 60 * Minute

}

And let the enum members use as raw-consts. Can assign to any type that has the corresponding well-known types?

在 2016年9月26日星期一 UTC+8下午5:06:18，Ally Dale写道：

[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> 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.

[Ally Dale]

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写道：

[Ian Lance Taylor]

On Tue, Sep 27, 2016 at 5:08 PM, Ally Dale <vip...@gmail.com> wrote:
>
> 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.

Well, then, you have to replicate all the constants and methods. The
methods on your new type can call the methods on time.Duration. You
can write the constants directly.

But this sounds like an XY problem. Why do you have to create a new
Duration type?

Ian