The simplest design I can think of (that does what you seem to
want) is to add parameterized packages. Here's a
stereotypical example:
========
package stack(T) // parameterized on stack element type
import "fmt"
type Type struct { rep []T
func New() *Type { &T{} }
func (stk *Type)Push(t T) { stk.rep = append(stk.rep, t) }
func (stk *Type)Pop()(T, error) {
var t T
ln := len(stk.rep)
if ln = 0 { return t, fmt.Errorf("Empty stack") }
t = stk.rep[ln-1]
stk.rep = st.rep[:ln-2]
return t, nil
}
========
package foo
import intstack "stack"(int) // stack of ints
import intstackstack "stack"(intstack.Type) // stack of stack of ints
var istk intstack.Type
var istkstk intstackstack.Type
...
istk.Push(5)
x, err := istk.Pop()
istkstk.Push(istk)
=========
Note that
- This adds only two syntax rules.
1. In the package header, its name can be followed by a
parenthesized list of names.
2. A package import must provide a complete list of types,
which are concrete or its own parameter types. And such
instantiated package must be given a local name.
- *All* we are doing is saving some typing.
- Given this, this feature can be expanded out via a preprocessor.
- Given this, no new semantics need be defined!
- Only one instance of a given type of package need be
generated and compiled.
- The intstackstack example is to show composability.
- This actually makes interface types more useful than now.
The last point is worth elaborating on. Currently the "io"
package defines a bunch of interface types such as Reader,
Writer and so on. These interface types allow you to use
objects of a variety of other types so as as they implement
relevant functions. But "io" interface types are primarily for
byte slices. If "io" was defined as a parameterized package,
one can have similar choices for other slice types. Currently
to provide similar set of useful interface types for other
slice types you would have to replicate a whole bunch of
packages.
Avoiding duplication of code should not be taken lightly.
Copies can diverge, bug fixes or peroformance improvements may
not be made consistently across all copies, newer copies may
not have as much testing, and as different copies may have
different bugs (and written by different people) each has to
be independently and thoroughly reviewed etc.
Go may not impress lanuage designers but it is a practical
language. IMHO the above has a similar feel for "generics" --
it is simple, very easy to teach, it is not turing complete or
anything fancy but takes care of most of the common use cases.
I had looked at previous formal proposals but none seemed
as simple as this.
Bakul
On Sat, 25 Mar 2017 20:57:51 EDT David Collier-Brown <davecb...@gmail.com>
wrote:
> Hmmn, we may be thinking different things... I *think* I'm looking for a
> way to say "an X of Y", and see composition as a possible approach.
> I just don't know if it will be a, the, or not the answer (;-))
>
> --dave
>
>
> On 24/03/17 11:21 PM, Michael Jones wrote:
> > I think I was saying that what I seem to want personally is the "simple,
> > weak, slight" thing that you likely see as failure.
> >
> > The opposite end of that--where everything is a list and can be composed
> > without special regard (lisp) or everything is an object that can
> > receive any message (smalltalk) are comfortable for me, but just not
> > what I find myself wanting very often.
> >
> > My own view is not important in the sense that a broad survey would be,
> > but since it seems much less than what people seem to dream of, I wanted
> > to share that maybe people could be happy with less than they seek.
> >
> > Or maybe that ultimate typeless generality is what others really need
> > somehow. I would not know.
> >
> > On Fri, Mar 24, 2017 at 6:13 PM David Collier-Brown <davecb...@gmail.com
> > <mailto:davecb...@gmail.com>> wrote:
> >
> > We still don't understand genrality: the current generics are
> > unimpressive. The proposals for Go are typically "let's do something
> > that has failed already, in hopes that trying it agin will have a
> > different result". That, alas, is one of the definitions of insanity.
> >
> > Due caution is advised!
--
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.
