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/f5ce43c5-f120-47b2-8955-7005432416ban%40googlegroups.com.
