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 hitting the sad, sad, reflective path...for now. On Saturday, April 2, 2022 at 4:37:36 AM UTC-5 Brian Candler wrote:
> 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 Set() and Get() methods, although these are not > compiled-time type safe as they accept and return interface{} > > On Friday, 1 April 2022 at 17:40:42 UTC+1 sam.a....@gmail.com wrote: > >> >> 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 >> introspective capability specific to the type and not using reflect >> On Friday, April 1, 2022 at 4:47:32 AM UTC-5 Brian Candler wrote: >> >>> 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 embedding before then Google for the details. >>> >>> You still cannot use one of these types transparently as a string, but >>> you can use >>> x.string >>> instead of >>> string(x) >>> to extract the value. >>> >>> On Friday, 1 April 2022 at 06:48:04 UTC+1 yan.z...@gmail.com wrote: >>> >>>> Hi Sam! Your solution does not seem to work: >>>> >>>> package main >>>> >>>> import( >>>> "fmt" >>>> "strconv" >>>> ) >>>> >>>> type <Purpose> 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 String ="452" >>>> >>>> n, _ := strconv.ParseInt(x, 10, 64) >>>> } >>>> >>>> 在2022年3月26日星期六 UTC+8 06:41:15<sam.a....@gmail.com> 写道： >>>> >>>>> >>>>> My workaround like is something like `type <Purpose>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 18, 2022 at 12:46:34 AM UTC-5 Henry wrote: >>>>> >>>>>> 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 types and achieve code reuse via inheritance. Since >>>>>> Go >>>>>> does not have inheritance, you can achieve a similar effect with >>>>>> standalone >>>>>> functions. >>>>>> >>>>>> On Friday, March 18, 2022 at 11:26:51 AM UTC+7 Ian Lance Taylor wrote: >>>>>> >>>>>>> On Thu, Mar 17, 2022 at 7:17 PM Zhaoxun Yan <yan.z...@gmail.com> >>>>>>> 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 discussion at https://go.dev/issue/21401. >>>>>>> >>>>>>> Ian >>>>>>> >>>>>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/21b04a4b-a9bb-4b83-8ddf-1ae3224fa8d5n%40googlegroups.com.
