FAQ
I agree with this.

I've thought before a third 'type' construct based on properties would
alleviate a lot of issues, similar to python duck typing.

Specifically, if you could do this:

type Sorter pmap {
    X int
    Y int
}

and this, as a valid type assertion on any type that had those properties,
without creating a dummy class:

func sort(t Sorter) { ... }

sort((&instance).(Sorter))

I know there a couple of things wrong with this, but it does achieve the
basic goals:

1) Type safe

2) Any type with a given 'property interface' can be passed into a generic
function without an extra class

3) Doesn't interfere with interfaces and try to 'add properties' to
interfaces (discussed else where)

Down sides:

1) Ambiguous in grammar how you distinguish between a property interface
type assert and a normal interface type assert.

2) Doesn't address return types (how would you write func
ApplyTransform(blah TValue) (TResult, error)? Cast the property interface?)

3) People will use property maps instead of interfaces for convenience sake

Just idle thoughts; but this seems a lot more low-impact on the existing go
type system than full blown generics.

~
Doug.
On Wednesday, May 22, 2013 7:33:39 AM UTC+8, Thomas Bushnell, BSG wrote:

I agree. I wasn't suggesting that Go's interfaces are a substitute for
typeclasses, only that I think the similarities suggest that they are the
right place to look for where generics might fit in.


On Tue, May 21, 2013 at 4:25 PM, Alexei Sholik <alcos...@gmail.com<javascript:>
wrote:
Typeclasses seem elegantly similar to Go's interfaces in just the right
ways. For a generic, you want a way to say "any type that can do this and
this and that".

The full power of type classes is only possible with type-generic
functions. Go doesn't have the latter.

data MyType a = One a | Two a deriving Show

instance Functor MyType where
fmap f (One a) = One $ f a
fmap f (Two a) = Two $ f a

*Main> fmap (+1) $ One 1
One 2

*Main> fmap (++" world") $ Two "Hello"
Two "Hello world"

In the example above, how would you define an instance of Functor if
there were no generics? You wouldn't be able to define fmap as taking a
function (a -> b). Essentially, you would need to write a separate fmap
implementation for each type. And each type would need to implement a
certain interface.

Other than that, type classes are indeed similar to Go's and Java's
interfaces, and C++'s abstract classes.

On Wed, May 22, 2013 at 1:02 AM, Thomas Bushnell, BSG <tbus...@google.com<javascript:>
wrote:
Typeclasses seem elegantly similar to Go's interfaces in just the right
ways. For a generic, you want a way to say "any type that can do this and
this and that".

Thomas



On Tue, May 21, 2013 at 6:54 AM, Ian Lance Taylor <ia...@golang.org<javascript:>
wrote:
On Tue, May 21, 2013 at 6:26 AM, roger peppe <rogp...@gmail.com<javascript:>>
wrote:
The names are used as archetypes of particular implementation
techniques rather than an exhaustive list, I think. If there's a
particular
language that uses some substantially different technique, we should
talk about that too.
Yes, I agree. In particular it's natural to talk about C++/Java/.NET
because those are three different styles of generics, and each could
be adapted to Go. Most compiled languages adopt one of those three
approaches.

A significant language with a different approach to generics is
Haskell, which actually has two different kinds of generics:
datatype-generic and type classes. Also, ML has a rather complex
concept called functors; this may be the most sophisticated form of
generics in a well-known programming language.

Ian

--
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...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.

--
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...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.



--
Best regards
Alexei Sholik
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2021 Grokbase