taylorchu / generic Goto Github PK

If the new package starts with ".", output filename will be added "package name" prefix to prevent conflicts.

Can generic specified output filename for manually preventing conflicts？

For example, I use .IntQueue for top level identifier prefix, but the output filename is "IntQueue_queue", looks weird.

Instead of putting complex rewriting syntax in a go file, lets replace it another yaml config file with clarity.

This removes random syntax that I created 1 year ago.

For normal rewrite, the output is a package dir. It is easy to remove by simply removing that dir. However, for local rewrite, there are many output files. Lets concat all files into one.

I had tried your example, I think is a nice project.

I test the use case that using package name started with ".", it seems that the result is TypeXXX, for example, TypeQueue rewrite to intTypeQueue. It's a bit strange. Can I specifed the string replacing the "Type" prefix to get "intQueue"?

This is kinda important, because when you use typed collections you definitely need the original doc.

If the new package starts with ".", All top-level identifiers will have prefixes to prevent conflicts, and their uses will also be updated.

for example, I use ".int" package name to generalize queue, the "New" function will rewrite to "intNew", this changed the visibility of the template function "New". If I used ".Int", it may changed the visibility of those identifiers started with lower case character. So I recommend to keep the visibility of the top-level Identifiers.

I recently started noticing gorewrite has a non-deterministic behavior: in one project, it fails to generate the correct output often, with a failure rate of about 80% in that project; however, it will eventually succeed in generating the correct output if I run it enough number of times (and so I have a script to check after each run and repeat if necessary).

The project is somewhat big and so I am still finding time to pare it down to a toy example to show the problem. Plus, since I can manage to get the correct output by repeating runs until success, it is not super high priority to me due to delivery deadlines.

With some preliminary investigations, I notice all the failures has to do with extra line breaks after return. Examples of bad output:

Example 1. (bad)

	return

	sb.String()

Example 2. (bad)

			return
			i - 1

In general, I am noticing a lot of extra line breaks in the generated code. Most of them are survivable in Go's syntax, but some like the above are not.

Example 3. (survivable)

			rv = append(
				rv,
				a)

Since I think this may hit some other users and maybe you have insights into this issue, may I ask if you have any advice on where such non-determinism can creep in and how I would troubleshoot this? I realize it could totally be a bug in go/ast, but I thought I could check with you first since I first encounter it in gorewrite.

Thanks!

P.S. A bit of information for repro in the future:

$ go version
go version go1.10 darwin/amd64

My genericis at git cd81575 and golang.org/x/tools is at 96caea4.

Hi, I have two files in an otherwise-empty $GOPATH:

src/generic/client/client.go
src/generic/container/container.go

with client.go being:

//go:generate generic generic/container result TypePayload->generic/client:client.Payload

package client

type Payload struct {
    x, y, z float32
}

and container.go being:

package container

type TypePayload struct {
    x int
}

type Node struct {
    TypePayload
    name string
}

func (n *Node) SetName(s string) {
    n.name = s
}

When I run go generate inside src/generic/client, I get:

package result

import "generic/client"

type client BadExpr

type Node struct {
    client.Payload
    name    string
}

func (n *Node) SetName(s string) {
    n.name = s
}
5:12: expected type, found '.'
client.go:1: running "generic": exit status 1

What would be the correct way to specify the rewrite target in the go:generate line so as to eliminate theBadExpr? Thanks!

Hi taylorchu :)
while generating a local code the command gorewrite returns the error:

2018/04/03 19:42:47 GOPACKAGE cannot be empty

You can checkout the test setup in the attachment.

On the other side generating a separate package doesn't give such error.

Keep up the great work,
Enrico Bonetti Vieno

P.S.: I do like a lot the elegance of your program - big fun here 👍 - in my opininion with some minor refinments and integrated in the toolchain could be a real substitute for the generics.

Current implementation allows you to declare simple types like

type TypeValue int64
type TypeKey string

// A "thread" safe map of type TypeKey:TypeValue.
// To avoid lock bottlenecks this map is dived to several (SHARD_COUNT) map shards.
type ConcurrentMap []*ConcurrentMapShared

// A "thread" safe TypeKey to TypeValue map.
type ConcurrentMapShared struct {
    items        map[TypeKey]TypeValue
    sync.RWMutex // Read Write mutex, guards access to internal map.
}

which wll generate fine code. However, when you need to have set of methods on your type, this becomes nontrivial:

type TypeValue int64
type TypeKey string

func (t *TypeValue) GetValue() string {
    return "place_holder"
}

// A "thread" safe map of type TypeKey:TypeValue.
// To avoid lock bottlenecks this map is dived to several (SHARD_COUNT) map shards.
type ConcurrentMap []*ConcurrentMapShared

// A "thread" safe TypeKey to TypeValue map.
type ConcurrentMapShared struct {
    items        map[TypeKey]TypeValue
    sync.RWMutex // Read Write mutex, guards access to internal map.
}

I would like to replace func (t *TypeValue) GetValue() string with mytype implementation, but currently it just copies the original, so I'm stuck with two implementations - from mytype and TypeValue one.

Relevant code:

package main

type mytype int64

func (t *mytype) GetValue() string {
    return "Hello World!"
}

//go:generate generic github.com/streamrail/concurrent-map .result TypeKey->[32]byte TypeValue->mytype
func main() {
}

This is the task after #9.

In some of my packages, I need to use generic to rewrite multiple packages. Because we currently do type-checking for each package, go type-checker often complains due to missing identifiers.