5 ms·

Don't make T a pointer.

by icholy 4y ago

Groxx 4y ago
For a collection like this, definitely agreed. If the users of that circular buffer want to use pointers, they can just pass a pointer type. No need to force it on all cases.
ByteJockey 4y ago
I think they're using it so that they can use nil as the zero value to indicate the buffer is empty in cases where the zero value is a valid result. I feel like the comma ok idiom is a better idea here.
- Someone 4y ago
  I think so, too, but only because that’s idiomatic go. In general, it’s not a good idea to have functions that logically return a value or an error return a value and an error. If you use go, that’s what you do, though. I see that that was changed already (https://github.com/MoserMichael/rzgrep/commit/764b9ad61a5dbe6b23c97ce739ed770199e222c5 https://github.com/MoserMichael/rzgrep/commit/764b9ad61a5dbe...) I think I would not return “ctx.data[0]” for the value returned in case of error, though. That runs the risk of users processing items multiple times if they forget to check for errors. I would use either - a fresh new instance of T - a special instance of T created once (could be passed in to NewCBuf as a value with, to the user, obviously incorrect contents) The first is cleanest, but may not be performant if creating T’s is costly. The second may be risky if the returned items are mutable and the caller changes them.
  - MichaelMoser123 4y ago
    > think I would not return “ctx.data[0]” for the value returned in case of error, though. I am not to comfortable with this either, i wonder why golang doesn't have a Maybe/Option monad in its standard library, i mean that's a very widely used pattern, nowadays... or am I missing something here? Maybe/Option monads in other languages: https://www.scala-lang.org/api/2.13.3/scala/Option.html https://www.scala-lang.org/api/2.13.3/scala/Option.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional... https://wiki.haskell.org/Maybe https://wiki.haskell.org/Maybe I guess they didn't want to copy the T value into the Option instance, but yeah, otherwise you get something like this, or you have to return a pointer.
    - Someone 4y ago
      In C-like languages pointers are the Maybe/Option type. Go has that. The go error pattern would need Either, though. In C, that’s ‘union’, but go (rightly so, IMO) didn’t copy that. Problem is, once you have Either[T,U], you want Either[T,U,V] and then, you want pattern matching. That, like generics, complicates a language. The go developers don’t want to go there (¿yet?).
      - MichaelMoser123 4y ago
        > In C-like languages pointers are the Maybe/Option type. I think that's a bit of a stretch, operations on Maybe types can be chained or used with Java streams. You can't do a thing like that with pointers. They could have dome something like java streams, given that golang has lambdas, but I guess that would not be idiomatic, or something like that... You do have a point with pattern matching, they don't do that in go. Scala has it, Java is getting pattern matching as some recent addition, but they added the Optional type with java 8.
        Someone 4y ago
        Yes, it’s a bit of a stretch, but C-like languages don’t have objects you can call methods on, so they do not have call chaining.
MichaelMoser123 4y ago
I see, was under the influence of Java, where almost everything is an object reference. Now how do I return an error in the case that Pop is called on an empty buffer? I can return nil for a call on an empty buffer func (ctx *CBuf[T]) Pop() *T { but I could return any value for an error, and indicate with the second return value if the call succeeded. func (ctx *CBuf[T]) Pop() (T, bool) { I fixed the class, so now it looks as follows: https://github.com/MoserMichael/rzgrep/blob/master/src/cbuf/cbuf.go https://github.com/MoserMichael/rzgrep/blob/master/src/cbuf/... Thanks! Still, I am feeling a bit uncomfy with returning a garbage value with the the error indication, even if that counts as being more idiomatic. I keep wondering, why golang doesn't have an Optional monad in its standard library, like they do everywhere else.
- tgv 4y ago
  You can declare a "zero" initialized variable and return that var zero T return zero, false I see that you return .data[0] in your code. It seems to me that that would be out of bounds when someone accidentally creates a buffer with size 0.

Don't make T a pointer.

by icholy 4y ago

Don't make T a pointer.

For a collection like this, definitely agreed. If the users of that circular buffer want to use pointers, they can just pass a pointer type. No need to force it on all cases.

ByteJockey 4y ago

I think they're using it so that they can use nil as the zero value to indicate the buffer is empty in cases where the zero value is a valid result. I feel like the comma ok idiom is a better idea here.

Someone 4y ago
I think so, too, but only because that’s idiomatic go. In general, it’s not a good idea to have functions that logically return a value or an error return a value and an error. If you use go, that’s what you do, though. I see that that was changed already (https://github.com/MoserMichael/rzgrep/commit/764b9ad61a5dbe6b23c97ce739ed770199e222c5 https://github.com/MoserMichael/rzgrep/commit/764b9ad61a5dbe...) I think I would not return “ctx.data[0]” for the value returned in case of error, though. That runs the risk of users processing items multiple times if they forget to check for errors. I would use either - a fresh new instance of T - a special instance of T created once (could be passed in to NewCBuf as a value with, to the user, obviously incorrect contents) The first is cleanest, but may not be performant if creating T’s is costly. The second may be risky if the returned items are mutable and the caller changes them.
- MichaelMoser123 4y ago
  > think I would not return “ctx.data[0]” for the value returned in case of error, though. I am not to comfortable with this either, i wonder why golang doesn't have a Maybe/Option monad in its standard library, i mean that's a very widely used pattern, nowadays... or am I missing something here? Maybe/Option monads in other languages: https://www.scala-lang.org/api/2.13.3/scala/Option.html https://www.scala-lang.org/api/2.13.3/scala/Option.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional... https://wiki.haskell.org/Maybe https://wiki.haskell.org/Maybe I guess they didn't want to copy the T value into the Option instance, but yeah, otherwise you get something like this, or you have to return a pointer.
  - Someone 4y ago
    In C-like languages pointers are the Maybe/Option type. Go has that. The go error pattern would need Either, though. In C, that’s ‘union’, but go (rightly so, IMO) didn’t copy that. Problem is, once you have Either[T,U], you want Either[T,U,V] and then, you want pattern matching. That, like generics, complicates a language. The go developers don’t want to go there (¿yet?).
    - MichaelMoser123 4y ago
      > In C-like languages pointers are the Maybe/Option type. I think that's a bit of a stretch, operations on Maybe types can be chained or used with Java streams. You can't do a thing like that with pointers. They could have dome something like java streams, given that golang has lambdas, but I guess that would not be idiomatic, or something like that... You do have a point with pattern matching, they don't do that in go. Scala has it, Java is getting pattern matching as some recent addition, but they added the Optional type with java 8.
      - Someone 4y ago
        Yes, it’s a bit of a stretch, but C-like languages don’t have objects you can call methods on, so they do not have call chaining.

MichaelMoser123 4y ago

I see, was under the influence of Java, where almost everything is an object reference. Now how do I return an error in the case that Pop is called on an empty buffer? I can return nil for a call on an empty buffer func (ctx *CBuf[T]) Pop() *T { but I could return any value for an error, and indicate with the second return value if the call succeeded. func (ctx *CBuf[T]) Pop() (T, bool) { I fixed the class, so now it looks as follows: https://github.com/MoserMichael/rzgrep/blob/master/src/cbuf/cbuf.go https://github.com/MoserMichael/rzgrep/blob/master/src/cbuf/... Thanks! Still, I am feeling a bit uncomfy with returning a garbage value with the the error indication, even if that counts as being more idiomatic. I keep wondering, why golang doesn't have an Optional monad in its standard library, like they do everywhere else.

tgv 4y ago
You can declare a "zero" initialized variable and return that var zero T return zero, false I see that you return .data[0] in your code. It seems to me that that would be out of bounds when someone accidentally creates a buffer with size 0.