If the calling function needs more than the interface methods (such as
access to type-specific struct fields) then an approach is to use an
interface type switch for per-type
behavior: https://tour.golang.org/methods/16
Matt
On Tuesday, January 2, 2018 at 1:05:22 PM UTC-6, Tong Sun wrote:
>
> Oh Thanks Matt, when Ian explained to me, I didn't think it'd work, but
> on seeing your code illustration, I now think it works perfectly for
> *this* case.
>
> Just that this function approach will break if there are many base class
> member fields that need to be accessed, as type methods can access them
> internally, under the encapsulation. But that's a different story...
>
> Thanks again *everyone*!
>
>
> On Tue, Jan 2, 2018 at 10:26 AM, <matthe...@gmail.com <javascript:>>
> wrote:
>
>> You want different tokenizer types to be used in the same WalkBody
>> implementation. Interfaces abstract the implementation from the calling
>> computation.
>>
>> I think Ian did answer your question.
>>
>> type TokenVisitor interface {
>> VisitToken()
>> }
>>
>> func WalkBody(of TokenVisitor) {
>> // here you call of.VisitToken()
>> }
>>
>> type MyTokenizer1 struct {
>> *html.Tokenizer
>> }
>>
>> func (the MyTokenizer1) VisitToken() {
>>
>> }
>>
>> type MyTokenizer2 struct {
>> *html.Tokenizer
>> }
>>
>> func (the MyTokenizer2) VisitToken() {
>>
>> }
>>
>> // call WalkBody somewhere with either MyTokenizer1 or MyTokenizer2
>>
>> When I wanted to write one list of tests for two different set types I
>> added set.go and set_test.go here:
>> https://github.com/pciet/pathsetbenchmark
>>
>> Matt
>>
>> On Tuesday, January 2, 2018 at 8:45:56 AM UTC-6, Tong Sun wrote:
>>>
>>>
>>>
>>> On Mon, Jan 1, 2018 at 9:46 PM, Tong Sun <sunto...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I think I generally understand how embedding (
>>>> https://golang.org/doc/effective_go.html#embedding) works in GO.
>>>> However, when it comes to the following problem, I'm at lost again.
>>>>
>>>> I'm trying to extend the `html.Tokenizer` with new methods of my own:
>>>>
>>>> type MyTokenizer struct {
>>>> html.Tokenizer
>>>> }
>>>>
>>>>
>>>> func NewMyTokenizer(i io.Reader) *MyTokenizer {
>>>> z := html.NewTokenizer(i)
>>>> return *MyTokenizer(z)
>>>> return &MyTokenizer{z}
>>>> }
>>>>
>>>>
>>>>
>>>> so code like
>>>>
>>>> z := html.NewTokenizer(body)
>>>> ...
>>>> func parseBody(z *html.Tokenizer) {
>>>> tt := z.Next()
>>>> ...
>>>> testt := z.Token()
>>>> ...
>>>>
>>>>
>>>> can become:
>>>>
>>>> z := NewMyTokenizer(body)
>>>> ...
>>>> func (z *MyTokenizer) parseBody() {
>>>> tt := z.Next()
>>>> ...
>>>>
>>>> testt := z.Token()
>>>> ...
>>>>
>>>>
>>>>
>>>>
>>>> However, I'm really struggling to make it work as I was expected.
>>>>
>>>> Somebody help please, what's the proper way to extend a type with new
>>>> methods of my own, while still able to access all existing methods?
>>>>
>>>
>>>
>>> Thanks to Jason Phillips' help, the above part is solved:
>>>
>>> type MyTokenizer struct {
>>> *html.Tokenizer
>>> }
>>>
>>> func NewMyTokenizer(i io.Reader) *MyTokenizer {
>>> z := html.NewTokenizer(i)
>>> return &MyTokenizer{z}
>>> }
>>>
>>> What's remaining is,
>>>
>>> Further more, how to extend the above even further? --
>>>>
>>>> - I plan to define an interface with a new method `WalkBody()`, in
>>>> which a "virtual" method of `VisitToken()` is used.
>>>> - Then I plan to define two different type of MyTokenizer, with their
>>>> own `VisitToken()` methods, so the same `WalkBody()` method defined in
>>>> MyTokenizer will behave differently for those two different types.
>>>>
>>>> How to architect above in Go?
>>>>
>>>
>>> I've found this afterward,
>>>
>>> http://hackthology.com/object-oriented-inheritance-in-go.html
>>>
>>> I'll digest and try it out, and see how that can solve the above
>>> problem, because it builds bottom up (not mid-way up).
>>>
>>> Meanwhile, if someone can explain how to think and solve such problem in
>>> Go, that'd be much appreciated. Only at the architectural level would be
>>> fine for me, I can try it out myself. The real problem to me is that I have
>>> a *systematic *thinking in OO how to solve such kind of inherit &
>>> enhance problem, and there is a *practical *implementation in place for
>>> me, the virtual functions. But when it comes to Go, I still need help for
>>> how to *think*, and how to *do*.
>>>
>>> Thanks!
>>>
>>>
>>>>
>>>> For your convenience, you can use this as an easy start, when
>>>> demonstrating your architectural solution.
>>>>
>>>> https://github.com/suntong/lang/blob/master/lang/Go/src/xml/htmlParserTokens.go
>>>>
>>>>
>>>> Thx a lot!
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "golang-nuts" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/golang-nuts/FRE_A6cNzW8/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> golang-nuts...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/FRE_A6cNzW8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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.
For more options, visit https://groups.google.com/d/optout.
