You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+86-3Lines changed: 86 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,87 @@
1
-
###28 Jun 2014
1
+
###30 Nov 2014 (v4)
2
+
3
+
To get the latest: `go get -u github.com/clipperhouse/gen`. Type `gen help` to see commands.
4
+
5
+
This release has several substantial changes.
6
+
7
+
####Type parameters
8
+
9
+
Tags now have support for type parameters, for example:
10
+
11
+
// +gen foo:"Bar[qux], Qaz[thing, stuff]"
12
+
// type MyType struct{}
13
+
14
+
Those type paramters (qux, thing, stuff) are properly evaluated as types. Which not only increases safety, but gives more information to typewriters.
15
+
16
+
####Type constraints
17
+
18
+
Speaking of above, types are evaluated for Numeric, Ordered and Comparable. Templates, in turn, can have type constraints.
19
+
20
+
So, you can declare your Sum template only to be applicable to Numeric types, and your Set to Comparable types.
21
+
22
+
####gen add
23
+
24
+
Third-party typewriters are added to your package using a new command, `add`. It looks like this:
25
+
26
+
gen add github.com/clipperhouse/setwriter
27
+
28
+
That’s a plain old Go import path.
29
+
30
+
After adding, you can mark up a type like:
31
+
32
+
// +gen set slice:"GroupBy[string], Select[Foo]"
33
+
// type MyType struct{}
34
+
35
+
As always, it’s up to the third-party typewriter to determine behavior. In this case, a “naked” `set` tag is enough.
36
+
37
+
We deprecated the unintuitive `gen custom` command, `add` replaces it.
38
+
39
+
####Explcitness
40
+
41
+
Previous versions of gen would generate a dozen or so LINQ-style slice methods simply by marking up:
42
+
43
+
// +gen
44
+
// type MyType struct{}
45
+
46
+
We’ve opted for explicitness moving forward – in the case of slices, you’ll write this instead:
47
+
48
+
// +gen slice:"Where, SortBy, Any"
49
+
// type MyType struct{}
50
+
51
+
In other words, only the methods you want.
52
+
53
+
####Projections
54
+
55
+
Certain methods, such as Select and GroupBy require an additional type parameter. I won’t bore you with the convoluted old way. Now it’s:
56
+
57
+
// +gen slice:"GroupBy[string], Select[Foo]"
58
+
// type MyType struct{}
59
+
60
+
Those type parameters are properly evaluated, and typewriters get full type information on them.
61
+
62
+
####slice
63
+
64
+
The main built-in typewriter used to be called `genwriter`, it is now called `slice`. Instead of the generated slice type being called Things, it’s now called ThingSlice.
65
+
66
+
[slice](https://github.com/clipperhouse/slice) is now the only built-in typewriter.
67
+
68
+
We’ve deprecated the built-in container typewriter, instead splitting it into optional [Set](https://github.com/clipperhouse/set), [List](https://github.com/clipperhouse/linkedlist) and [Ring](https://github.com/clipperhouse/ring) typewriters. How to add optional typewriters, you ask?
69
+
70
+
####Smaller interface
71
+
72
+
For those developing their own typewriters: the [`TypeWriter` interface](https://github.com/clipperhouse/typewriter/blob/master/typewriter.go) got smaller. It’s now:
73
+
74
+
type TypeWriter interface {
75
+
Name() string
76
+
Imports(t Type) []ImportSpec
77
+
Write(w io.Writer, t Type) error
78
+
}
79
+
80
+
`Validate` is gone, it was awkward. The easy fix there was to allow Write to return an error. `WriteHeader` is gone, there was little use for it in practice. `WriteBody` is now simply `Write`.
81
+
82
+
Let me (@clipperhouse) know if any questions.
83
+
84
+
###28 Jun 2014 (v3)
2
85
3
86
To get the latest: `go get -u github.com/clipperhouse/gen`. Type `gen help` to see commands.
4
87
@@ -12,8 +95,8 @@ Prior to this release, typewriters were simply part of the `gen` binary. Now, by
`gen` is a code-generation tool for Go. It’s intended to offer generics-like functionality on your types.
3
+
`gen` is a code-generation tool for Go. It’s intended to offer generics-like functionality on your types. Out of the box, it offers offers LINQ/underscore-inspired methods.
4
4
5
-
Out of the box, it offers LINQ/underscore/js-inspired methods as well as some handy containers.
6
-
7
-
It also offers third-party, runtime extensibility via [typewriters](http://godoc.org/github.com/clipperhouse/gen/typewriter).
5
+
It also offers third-party, runtime extensibility via [typewriters](https://github.com/clipperhouse/typewriter).
8
6
9
7
####[Introduction and docs…](http://clipperhouse.github.io/gen/)
It’s early days and the API is likely volatile, ideas and contributions are welcome. Have a look at the design principles below. Feel free to [open an issue](//github.com/clipperhouse/gen/issues), send a pull request, or ping Matt Sherman [@clipperhouse](http://twitter.com/clipperhouse).
15
+
####gen
18
16
19
-
## Design principles for contributors
17
+
This repository. The gen package is primarily the command-line interface. Most of the work is done by the typewriter package, and individual typewriters.
20
18
21
-
This library exists to provide readability and reduce boilerplate in users’ code. It’s intended to reduce the number of explicit loops, by instead passing func’s as you would with C#’s Linq, JavaScript’s Array methods, or the underscore library. If it feels like piping, that’s good.
19
+
####typewriter
22
20
23
-
It’s intended to fit well with idiomatic Go. Explicitness and compile-time safety are preferred. For this reason, we are not using interfaces or run-time reflection. (Though if a good case can be made, we’ll listen.)
21
+
The [typewriter package](https://github.com/clipperhouse/typewriter) is where most of the parsing, type evaluation and code generation architecture lives.
24
22
25
-
The goal is to keep the API small. We aim to implement the **least number of orthogonal methods** which allow the desired range of function.
23
+
####typewriters
26
24
27
-
It’s about types. If something would be expressed <T> in another language, perhaps it’s a good candidate for gen. If it would not be expressed that way, perhaps it’s not a good candidate.
25
+
Typewriters are where templates and logic live for generating code. Here’s [set](https://github.com/clipperhouse/set), which will make a lovely Set container for your type. Here’s [slice](https://github.com/clipperhouse/slice), which provides the built-in LINQ-like functionality.
28
26
29
-
We avoid methods that feel like wrappers or aliases to existing methods, even if they are convenient. A good proxy is to imagine a user asking the question ‘which method should I use?’. If that’s a reasonable question, the library should be doing less.
27
+
Third-party typewriters are added easily by the end user. You publish them as Go packages for import. [Learn more].
30
28
31
-
These guidelines are not entirely deterministic! There’s lots of room for judgment and taste, and we look forward to seeing how it evolves.
29
+
We’d love to see typewriter packages for things like strongly-typed JSON serialization, `Queue`s, `Pool`s or other containers. Anything “of T” is a candidate for a typewriter.
0 commit comments