Yes I understand the strict type checking. But in the absence of macros, the 
code becomes extremely awkward and sometimes  the simplicity that we beg for 
gets undermined. 
My intention trying to do this was two things:
1. Reduce my line length in the code
2. Avoid making changes to all parts of the code as I needed to use the same 
type in a different package. I could not make package inclusions without 
circular dependency.

A dynamic check by compiler to see if the type has been really modified would 
be great. Like a pre processor check to simply replace the definitions with 
original names could do this?

Any other way to achieve what I need?

Thanks
Rajesh

Sent from my iPhone

> On Feb 10, 2018, at 10:57 PM, Axel Wagner <axel.wagner...@googlemail.com> 
> wrote:
> 
>> On Sun, Feb 11, 2018 at 7:27 AM, rajesh nataraja <rnatar...@gmail.com> wrote:
>> Compiler does not allow this, aren't they essentially all the same? What is 
>> the reason this is not allowed?
> 
> Go is strictly typed. As such, it limits conversions (much more automatic 
> ones) between types that are not the same.
> Types are characterized by two things: The data they hold and the operations 
> you can do on them. The latter is, what you usually declare new types for. 
> So, for examples, if I do
> 
> type F struct{
>     *bytes.Buffer
> }
> 
> then an F is basically the same as a *bytes.Buffer - they have the same 
> representation in memory. But I can then do
> 
> func (f F) Write(p []byte) (n int, err error) {
>     n, err = f.Buffer.Write(p)
>     if err != nil {
>         log.Printf("Error writing to buffer: %v", err)
>     }
>     return n, err
> }
> 
> thus modifying the behavior of the type.
> 
> Different type-declarations usually imply different operations on the same 
> underlying data. In your case, it only makes sense to declare both T1 and T2, 
> if they are supposed to do different things, even if they have the same 
> structure. Different method-sets will usually use and enforce different 
> invariants, so there are usually severe problems with intermixing them.
> 
> So if what you want would be allowed - transparently converting between 
> values with the same representation - that would essentially negate most of 
> the point of the type-checker. By declaring two types you are explicitly 
> stating, that you want them to be treated as different and Go's strict typing 
> makes sure that you do.
> 
>> 
>> Thanks
>> Rajesh.
>> -- 
>> 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.

Reply via email to