Like, I get that the extra type-pointer for a declared struct of
float64+bool isn't that big of a deal, I do wish we could express tuple
types naturally. What you suggest is probably the closest we get for now.
For `if v, ok := value.(bool); ok && v`, the value is tuly 0. For `if v, ok
:=
I agree, and there's a clear benefit that it's harder to dereference a nil
interface than a nil pointer, when that interface has no methods. The
problem is that statically it doesn't tell you anything about the possible
contained type.
In comparison, a pointer tells you exactly the type
I get what you're saying, and for what it's worth, you're absolutely
correct. Something like above is a set of tradeoffs, and I guess all I can
assert is that it works for me. I do think it's a good design, given Go's
lack of a None type to enforce well-defined behavior on a nil pointer
I did look at the code briefly. The main thing I noticed was that the
return type of float8.Get() was an interface{} - so it's up to the caller
to check at runtime whether the value is nil, a float64, or a Status.
So you're right, it's not that they are compile-time unsafe, but rather
that
Uh, you should check the code:
github.com/jackc/pgtype/blob/master/float8.go If you know what you have and
what you're dealing with, and if you actually check the error result, you
do get safety. If you don't know what you've got, or if you're iterating
through the values, then you end up
Correct repository path is: https://github.com/jackc/pgtype
Interesting. These structs generally contain a Status value as well:
type Int8 struct {
Int int64
Status Status
}
where pgtype.go has:
type Status byte
const (
Undefined Status = iota
Null
Present
)
They also have
Thanks for clarifying that, @Brian. Yeah. It took a bit to warm up to that
approach, but the github.com/jackc/pgtypes convinced me that the results
were worth it. The benefits: A, package interpretation methods with a
piece of data, B, lazily valuate data when needed, and C, gain
That wasn't literal code with anglebrackets - you're supposed to fill that
in yourself. I think he meant something like:
type fooString struct{ string }
https://go.dev/play/p/4Q94xMZDciV
What this is doing is *embedding* a string value into a struct; if you have
not come across type
Hi Sam! Your solution does not seem to work:
package main
import(
"fmt"
"strconv"
)
type String struct{string}
func (s String) print(){
fmt.Println(s)
}
func main() {
var a String ="hello, world\n"
a.print()
fmt.Println(strconv.ParseInt("78",10, 64))
var x
This works:
n, _ := strconv.ParseInt(string(x), 10, 64)
Go intentionally does no automatic type conversion, not even this:
var a int32 = 1234
var b int64 = a// error: use int64(a) instead
It would be inconsistent if passing "mystr" to a function which accepts
My workaround like is something like `type String struct{string}.
It can be reasonably treated as a string for most cases in which as string
is needed, and it lets you convert back conveniently from any scope in
which it's reasonable for your program to know the difference.
On Friday, March
My own preference is to have a small number of methods and put the general
functionalities into functions. By putting the general functionalities into
functions, you allow code reuse. In object-oriented programming, you
normally attach as many functionalities as possible to their corresponding
On Thu, Mar 17, 2022 at 7:17 PM Zhaoxun Yan wrote:
>
> I just came across this taboo in golang - new methods cannot be added to an
> existing type:
Yes. If we didn't have this prohibition, then the set of interfaces
satisfied by a type would depend on which package was using the type.
See the
13 matches
Mail list logo
