If your struct need special initialization, provide a factory function
(search for New* or Make* for examples) and don't export the special
fields. If not, the zero value is obviously fine.
Recursive application of this simple and widely used rule negates the
problem you seem to be having; F apparently needs special initialization,
so it should provide an appropriate factory, then E needs special
initialization (as it uses F), so it should provide… and so forth. Until
the user just uses NewF, which will take care of recursive initialization.
No one needs to know anything about any package they are not directly
importing.
Note, that there is zero difference here, between a language with or
without constructors, in terms of which code needs to be aware of what. The
difference only is, that the constructors are explicit and people need to
be aware of how to construct values.
On Fri, Jan 13, 2017 at 3:39 PM, hui zhang <fastfad...@gmail.com> wrote:
> I just list A B C D E F as an example.
> In real project we will use struct in struct .
> when the struct goes deeper, and it may be managed by other people,
> if the deepest struct need a default value. F{x:1}
> The upper struct user "must" known the detail.
> here below I just figure out a way below to do that, but it's not a common
> way, just I know it .
> Other people who use my lib may not . So he maybe use the zero value F{}
> not F{x:1}
> type F struct {x int32}
> var FDefault = F{x:1}
> type E struct {f F}
> var EDefault = E{f: FDefault}
> type D struct {e E}
> var DDefault = D{e: EDefault}
>
> 在 2017年1月13日星期五 UTC+8下午5:49:46，Egon写道：
>
>>
>>
>> On Friday, 13 January 2017 11:26:29 UTC+2, hui zhang wrote:
>>>
>>> thank u very much. I know they all have work around. and I also write
>>> some util my own.
>>> I just wish go to make it more simpler, wish the code could be clean and
>>> short .
>>> Right now go let programer do repeat and Mechanical work
>>>
>>> the top 3 are bothering me most
>>> [1],[2] let me do many type cast all the time.
>>> [3] let me have to do initialize default for each struct.
>>> right now I am solving [3] like this.
>>> type F struct {x int32}
>>> var FDefault = F{x:1}
>>> type E struct {f F}
>>> var EDefault = E{f: FDefault}
>>> type D struct {e E}
>>> var DDefault = D{e: EDefault}
>>>
>>>
>> What is the actual code that you are working on? I doubt you have structs
>> named F, E, D.
>>
>> It's very hard to suggest a better model for "something" without knowing
>> what that "something" is.
>>
>> + Egon
>>
>>
>>>
>>>
>>> 在 2017年1月13日星期五 UTC+8下午4:39:55，Egon写道：
>>>>
>>>> As Shawn mentioned, most of these were decided against for varying
>>>> reasons. I'll try to give as much info as I can remember.
>>>>
>>>> On Friday, 13 January 2017 09:44:10 UTC+2, hui zhang wrote:
>>>>>
>>>>> Disadvantage of Go
>>>>> 1 No Generic For Now
>>>>>
>>>> That make user coding repeat code many times, even for basic type such
>>>>> as int float bool
>>>>> It is not easy , even to make a generic min function.
>>>>>
>>>> using interface will always check type casting.
>>>>> and for []interface{} in generic function, u can't do cast
>>>>>
>>>>
>>>> You cannot cast []interface{} to []float64 because they have different
>>>> memory layouts.
>>>>
>>>>
>>>>>
>>>>> 2 Incomplete Type in Basic Lib
>>>>> Take math lib as an example, math.Max math.Min are only for float64
>>>>> ,
>>>>> you have do stupid conversion for other type.
>>>>>
>>>>
>>>>> 3 No Default Value for struct.
>>>>> Consider multilayer struct. A {B {C {D {E {F} } } }
>>>>> to init A to a default value will be complicated.
>>>>> And how about A[] slice
>>>>> And what if D E F are from third party lib ?
>>>>> You have to dig into 3rd party code just for its default value.
>>>>> For It may have none zero default value.
>>>>>
>>>>
>>>> All structs are zero initialized.
>>>>
>>>> If you had default-values for structs the overhead of constructing
>>>> something becomes non-obvious.
>>>>
>>>>
>>>>>
>>>>> 4 Can not Cycle import.
>>>>> package A B can not import each other at the same time.
>>>>> While other language can.
>>>>> It seems not a big deal just put the the common thing in a new package
>>>>> But when the package and project grow bigger, it just easy to say.
>>>>> This change will affect all caller.
>>>>>
>>>>
>>>> Structures that have cyclic dependencies have longer compile times,
>>>> init order becomes more confusing and prone for errors, and a program
>>>> having cyclic imports is harder to understand than one without it
>>>> (usually).
>>>>
>>>> Break cycles with DI.
>>>>
>>>>
>>>>> 5 Inconsistent type conversion
>>>>> bool type are normal type just like int and float ,
>>>>> but u can't do below. while other type can cast to others
>>>>> int(bool) bool(int)
>>>>>
>>>>>
>>>> https://github.com/golang/go/issues/9367#issuecomment-143128337
>>>>
>>>>
>>>>> 6 No multi casting expression
>>>>> func foo() (int16, int8)
>>>>> var i,j int32 = (int32,int32)(foo())
>>>>> Since go can't do this, why go provide multi return value.
>>>>>
>>>>
>>>> Why would you not return int32 immediately from `foo`?
>>>> Why would you write `foo` in the first place?
>>>>
>>>> 7 No Ternary Expression
>>>>> hardly find a language without it except go
>>>>>
>>>>
>>>>> 8 No Negative Index for slice
>>>>> all other script language support a[-1] as a[len(a)-1]
>>>>>
>>>>
>>>> In such situations, indexing that involves computation (e.g. `a[n-5]`)
>>>> can easily hide mistakes.
>>>>
>>>>
>>>>>
>>>>> When programing in go
>>>>> we have to do repeated type casting many times, due to the above.
>>>>> write long code for Ternary ,int(bool) a[-1] etc
>>>>>
>>>>
>>>> If you repeatedly need to use it, then:
>>>>
>>>> func ifthen(v bool, a, b int) { if v { return a; }; return b }
>>>> func asint(v bool) int { return ifthen(v, 1, 0) }
>>>>
>>>> x := ifthen(a < b, a, b)
>>>>
>>>> init big struct with default value.
>>>>> Which make Go not an Elegant and simple language.
>>>>> Once I thought go was a simple language,
>>>>> but in fact we write more code.
>>>>>
>>>>> All above are proposal for many times.
>>>>> And it is 6 years(or more).
>>>>> These basic functions are still not added. some of that should be add
>>>>> in version 1.0
>>>>> I belive most above could make go simpler,
>>>>> someone know a little programing could know how to use it.
>>>>> however someone still fear it make go complicate like c++
>>>>>
>>>>
>>>> But, it seems to me you are trying to use Go as a language that it is
>>>> not. Can you show the code where you are having problems with some/all of
>>>> these points, then we can discuss how to avoid these situations in the
>>>> first place.
>>>>
>>>> If you try to use any language in a way that it was meant to, you will
>>>> have problems.
>>>>
>>>> + Egon
>>>>
>>> --
> 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.
>
--
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.
