On Tue, Jan 2, 2018 at 11:33 PM, Dave Cheney <d...@cheney.net> 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/to
>>>>> pic/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/to
>>> pic/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+unsubscr...@googlegroups.com.
> 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.
