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 you have to write type matching code at each use site. Within a given
switch branch, it's safe.
On Tuesday, 5 April 2022 at 07:29:09 UTC+1 sam.a....@gmail.com wrote:
> 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/7eb21321-caaa-46be-9853-3c6b5e8f8a09n%40googlegroups.com.
