Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go-Restructure: Sane regular expressions with struct fields

github.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Go-Restructure: Sane regular expressions with struct fields

#31

Post by donatj »

yalue wrote: post #17
iofj wrote: post #16

What's wrong with named capture groups ? http://www.regular-expressions.info/named.html

The support for named capture groups in Go's regular expressions is severely lacking, in the sense that it may as well not even exist. There's an API (SubexpNames) that returns an ordered list of the capture group names (if you provided them), but it's up to the user to implement some scheme for mapping a name to the contents of a capture group. At that point, it's probably going to be easier to just use the capture…

I actually use them quite extensively and I don't mind the implementation.

Re: Go-Restructure: Sane regular expressions with struct fields

#32

Post by arnehormann »

jerf wrote: post #29

I recommend that the first example be changed to use struct{} as well. The "strings" are still present in the struct footprint if you leave them there: http://play.golang.org/p/ZG1ULgzSwZ And people luuuuuv to pick up the one example where you did something a bit wrong and copy paste like mad.... I'd really rather see something that generates marshaling code based on a regex or something, though. This loads an awful…

It is specified - a struct tag is just a string literal after a struct field. See https://golang.org/ref/spec#String_literals

If you use backticks, the tag must not contain another backtick. On anything but a struct tag, you could get by by concatenating literals, but that's not allowed for struct tags: https://golang.org/ref/spec#Tag You could use double quotes instead of backticks, but that leads to a dark corner of escaping hell and an utterly unreadable mess.

Thankfully, the language strongly nudges you to very, very simplistic and light uses of struct tags.

Re: Go-Restructure: Sane regular expressions with struct fields

#33

Post by jerf »

arnehormann wrote: post #32
jerf wrote: post #29

I recommend that the first example be changed to use struct{} as well. The "strings" are still present in the struct footprint if you leave them there: http://play.golang.org/p/ZG1ULgzSwZ And people luuuuuv to pick up the one example where you did something a bit wrong and copy paste like mad.... I'd really rather see something that generates marshaling code based on a regex or something, though. This loads an awful…

It is specified - a struct tag is just a string literal after a struct field. See https://golang.org/ref/spec#String_literals If you use backticks, the tag must not contain another backtick. On anything but a struct tag, you could get by by concatenating literals, but that's not allowed for struct tags: https://golang.org/ref/spec#Tag You could use double quotes instead of backticks, but that leads to a dark corner o…

"It is specified - a struct tag is just a string literal after a struct field."

I meant the internals of a struct tag, not the grammar. The standard library implies some structure with things like `json:"name,omit_empty"` but that structure is not actually specified AFAIK. And I seem to recall finding a github issue where the core team said they don't intend to specify one, basically for the reason that they don't want struct tags to be used for things like this systematically, but I couldn't google it up. If they fully "specify" struct tags I think they fear massive metadata additions, instead of little annotations here and there. I'm not quite sure enough of this to state it without qualification, but I am pretty sure it is accurate.

Re: Go-Restructure: Sane regular expressions with struct fields

#34

Post by cypher543 »

jerf wrote: post #33
arnehormann wrote: post #32

Earlier quoted context omitted.

It is specified - a struct tag is just a string literal after a struct field. See https://golang.org/ref/spec#String_literals If you use backticks, the tag must not contain another backtick. On anything but a struct tag, you could get by by concatenating literals, but that's not allowed for struct tags: https://golang.org/ref/spec#Tag You could use double quotes instead of backticks, but that leads to a dark corner o…

"It is specified - a struct tag is just a string literal after a struct field." I meant the internals of a struct tag, not the grammar. The standard library implies some structure with things like `json:"name,omit_empty"` but that structure is not actually specified AFAIK. And I seem to recall finding a github issue where the core team said they don't intend to specify one, basically for the reason that they don't wa…

The reflect package specifies a "convention" which it uses to extract key-value pairs from a struct tag using the Get method:

https://golang.org/pkg/reflect/#StructTag

There's no need to parse the entire tag string yourself and it's safe to assume other libraries will work with the convention. If they don't, that's not your fault and it would break with other tags like "json" and "xml" anyway.

Re: Go-Restructure: Sane regular expressions with struct fields

#35

Post by arnehormann »

jerf wrote: post #33
arnehormann wrote: post #32

Earlier quoted context omitted.

It is specified - a struct tag is just a string literal after a struct field. See https://golang.org/ref/spec#String_literals If you use backticks, the tag must not contain another backtick. On anything but a struct tag, you could get by by concatenating literals, but that's not allowed for struct tags: https://golang.org/ref/spec#Tag You could use double quotes instead of backticks, but that leads to a dark corner o…

"It is specified - a struct tag is just a string literal after a struct field." I meant the internals of a struct tag, not the grammar. The standard library implies some structure with things like `json:"name,omit_empty"` but that structure is not actually specified AFAIK. And I seem to recall finding a github issue where the core team said they don't intend to specify one, basically for the reason that they don't wa…

A struct tag is just a string literal - according to the spec. The tags can only be accessed by reflect. The reflect api docs mention the convention. https://golang.org/pkg/reflect/#StructTag

Re: Go-Restructure: Sane regular expressions with struct fields

#36

Post by muraiki »

As someone who likes both Go and Perl 6, this reminds me a lot of Perl 6 grammars; I look forward to using this in Go. Here's a rough equivalent in P6, although I don't think the Go one or mine are completely legit in terms of internationalization and whatnot:

  grammar email-address {
      token TOP { ^  '@'  $ }
      token user { + }
      token hostname {  '.'  }
      token domain { \w+ }
      token TLD { \w+ }
  }

  if (my $email = email-address.parse('joe@猫.com')) {
      say $email;
      say $email;
      say $email;
  }
It's also possible to turn the captured parts into their own objects ($email has a type of Match; it's not just a hash).

Re: Go-Restructure: Sane regular expressions with struct fields

#37

Post by telotortium »

jerf wrote: post #33
arnehormann wrote: post #32

Earlier quoted context omitted.

It is specified - a struct tag is just a string literal after a struct field. See https://golang.org/ref/spec#String_literals If you use backticks, the tag must not contain another backtick. On anything but a struct tag, you could get by by concatenating literals, but that's not allowed for struct tags: https://golang.org/ref/spec#Tag You could use double quotes instead of backticks, but that leads to a dark corner o…

"It is specified - a struct tag is just a string literal after a struct field." I meant the internals of a struct tag, not the grammar. The standard library implies some structure with things like `json:"name,omit_empty"` but that structure is not actually specified AFAIK. And I seem to recall finding a github issue where the core team said they don't intend to specify one, basically for the reason that they don't wa…

The value of each key-value pair is documented to be a Go string literal: https://golang.org/pkg/reflect/#StructTag. In fact, `strconv.Unquote` is used to convert the value into a string in the code, which agrees with the documentation. In any case, I modified the library in the OP to use a key-value pair and the struct tag `restructure:"\\w+"` works as expected.

Re: Go-Restructure: Sane regular expressions with struct fields

#38

Post by ajanuary »

inglor wrote: post #26
ajanuary wrote: post #24

Earlier quoted context omitted.

JavaScript doesn't guarantee the order of keys. [edit] Also, the API makes less sense because JavaScript isn't statically typed so you can make up the result object on the fly. match('^(? \w+)@(? [^@]+)$', 'joe@example.com') => {'user': 'joe', 'host': 'example.com'}

Yes it does - it does for getOwnPropertyNames but not for Object.keys.

Seems I might be outdated, and ES6 does define an order.

Re: Go-Restructure: Sane regular expressions with struct fields

#39

Post by jernfrost »

elmin wrote: post #20
andmarios wrote: post #5

Very nice solution! I try to avoid using 3rd party libraries but this I would use without hesitation. Some benchmarks would be interesting.

Why do you avoid third-party libraries?

I don't know his reasons, but I also try to avoid third party because 1) Often you can do the same with the standard library with very little extra code. 2) Using lots of third party makes your code less maintainable. A lot of little libraries are not well maintained. 3) You are at the mercy of when the third party library updates to fit say latest language version or standard libraries. 4) Third party libraries can pull in a lot of unwanted complexity. You might only use a tiny tiny part of it. 5) By relying on third party you force other developers to know that library in addition to the standard library.

There is a certain amount of trigger happiness around when it comes to third party libraries. People tend to use third party libs WAY TOO much. Often they don't even check what is in the standard library.

I've thrown out over 50% of the third party libraries used in iOS projects I've taken over while simplifying and reducing the amount of code. The reason why using the third party libs grew the code was that third party libraries are usually quite generic, which requires more code to adapt to them. If your needs are quite simple, custom tailored code can take less space than utilising a third party library.

Post reply on HN