On Sun, Feb 11, 2018 at 4:52 PM, rajesh nataraja <rnatar...@gmail.com>
wrote:
> 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?
>
I really don't understand what you *are* trying to achieve. You have only
posted example code and from that, all I understand is that you are trying
to declare two different types but treat them as if they're the same. If
they are the same type, don't declare it twice. If they are not the same
type, it doesn't make any sense to treat them as if they were. It would
probably help, if you could explain a bit what you are actually trying to
do, because there is probably a better way to deal with this.
FWIW, there is one way that you can circumvent the type safety of Go and
that is by using unsafe. But it is very likely not what you actually should
be doing.
>
> 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.
