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/ac1c5c49-2000-42d4-8c2b-7ff6562c5486n%40googlegroups.com.
