>
> 1. extend the `html.Tokenizer` with new methods of my own
> 2. while still able to access all existing html.Tokenizer methods in the
> mean time
You have this by struct embedding:
z := MyTokenizer1{html.NewTokenizer(r)}
// don’t take the address, a pointer to a struct of pointers doesn’t make
sense unless you are changing the pointers
// z.Next() works here, although maybe you need to do z.Tokenizer.Next()
// z.printElmt(depth, text) works here
3. define a function `WalkBody()` (or an interface method)
“or an interface method” doesn’t make sense to me.
By assigning z to a TokenVisitor interface var you lose all functionality
besides the TokenVisitor methods unless you use a type assertion or type
switch to convert the var back to a MyTokenizer1 in htmlWalk.
Instead of going back to the concrete type with the type assertion I
suggest you add the method “Next() html.TokenType” and the other needed
methods (printElmt, Err, TagName, VisitToken) to TokenVisitor.
4. in which an interface method of `VisitToken()` is used, which will
> behave differently for different types
You have this by defining different implementations for the TokenVisitor
interface methods.
Why do you need varying types if you are just using html.Tokenizer methods?
What is the difference between each type?
Matt
On Tuesday, January 2, 2018 at 10:52:37 PM UTC-6, Tong Sun wrote:
>
>
>
> On Tue, Jan 2, 2018 at 11:33 PM, Dave Cheney <da...@cheney.net
> <javascript:>> wrote:
>
>> Put your methods on *MyTokenizer.
>>
>
> Yeah, that works for the struct but not for interface:
>
> *TokenVisitor is pointer to interface, not interface
>
>
>
>> On Wednesday, 3 January 2018 14:52:41 UTC+11, Tong Sun wrote:
>>>
>>> I gave it a try, but unfortunately, it doesn't work for me.
>>>
>>> To begin with, this works,
>>>
>>> type MyTokenizer struct {
>>> *html.Tokenizer
>>> }
>>>
>>> func NewMyTokenizer(i io.Reader) *MyTokenizer {
>>> z := html.NewTokenizer(i)
>>> return &MyTokenizer{z}
>>> }
>>>
>>> However,
>>>
>>> On Tue, Jan 2, 2018 at 10:26 AM, <matthe...@gmail.com> 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
>>>>
>>>
>>>
>>> As soon as I tried above and turned
>>>
>>> type MyTokenizer struct
>>>
>>> to
>>>
>>> type TokenVisitor interface
>>>
>>> everything started to break down. Here is the code that I've put
>>> together so far:
>>>
>>>
>>> https://github.com/suntong/lang/blob/master/lang/Go/src/xml/htmlParserTokens2.go
>>>
>>> I got:
>>>
>>> ./htmlParserTokens2.go:82:10: z.Next undefined (type TokenVisitor has no
>>> field or method Next)
>>>
>>> So let me reiterate what I hope to achieve,
>>>
>>>
>>> 1. extend the `html.Tokenizer` with new methods of my own
>>> 2. while still able to access all existing html.Tokenizer methods in
>>> the mean time
>>> 3. define a function `WalkBody()` (or an interface method)
>>> 4. in which an interface method of `VisitToken()` is used, which
>>> will behave differently for different types
>>>
>>> The first two goals can be achieved by "type MyTokenizer struct", but
>>> as soon as I change that to the interface type to act as the base for the
>>> two different extended types, goal#2 breaks.
>>>
>>> So far this is only a small test example, in which
>>> only z.Next(), z.Err(), z.TagName() etc are currently used. But in real
>>> life I'll using all the html.Tokenizer methods, and published variables.
>>> I.e.,
>>>
>>> I'm not seeing the light at the end of the tunnel where all above 4 goal
>>> can be achieved together.
>>>
>>> Seem to me some compromise has to be made, what is the least compromise
>>> to make?
>>> Anybody can help please?
>>>
>>> Again, the code that I've put together so far is at:
>>>
>>>
>>> https://github.com/suntong/lang/blob/master/lang/Go/src/xml/htmlParserTokens2.go
>>>
>>> Thanks
>>>
>>>
>>> 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.
>>>> 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.
