Re: [go-nuts] Reference to type satisfying a specified interface
On Tuesday, September 4, 2018 at 7:13:50 AM UTC-4, Jan Mercl wrote: > > I'm worried the suggested editing pass could make the docs better for > newbies and less useful for non-newbies in the same time. Maybe the docs > for beginner's should be the edited, but separate _version_ of the current > docs. > Dangerous. Remember the Single Point of Truth rule. No, it could be done right so that the outside-in view adds value without cruftifying. I know this because my brain automatically composes those edits as soon as I have the knowledge to do it. -- 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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Friday, August 31, 2018 at 6:55:28 AM UTC-4, ohir wrote: > > On Thu, 30 Aug 2018 18:41:48 -0700 (PDT) > Eric Raymond > wrote: > > > Oh, actually, I have one other issue; how to translate virtual methods > in a > > Python base class into Go's object model. > > Inheritance based domain models do not translate directly to go's > composition > based ones. Forget "virtual". Forget inheritance. > Most of your advice is helpful. This is not. Helpful advice would begin with a topic sentence something like "Here is how to use composition to emulate superclass behavior." Remember, I'm not writing code de novo. I'm translating a large existing codebase. The distance I can wander away from its present factoring/organization without triggering a dangerous complexity explosion is very limited. -- 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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Tue, Sep 4, 2018 at 1:05 PM Eric Raymond wrote: > For me personally this is a relatively minor problem - not my first rodeo of this kind nor even my dozenth, I have broad experience and know how to adapt and persist. > For most newbies it's going to be a serious blocker. I can recommend a fix: the team could hire a tech writer with an outside-in view (and no prior knowledge of Go) > to do a serious editing pass on the documentation. I'm worried the suggested editing pass could make the docs better for newbies and less useful for non-newbies in the same time. Maybe the docs for beginner's should be the edited, but separate _version_ of the current docs. -- -j -- 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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Friday, August 31, 2018 at 12:06:44 AM UTC-4, Nigel Tao wrote: I'm only guessing, but I think Ian's "which docs did you look at" was referring to your previous "I was unable to extract this enlightenment from the documentation, despite sweating over it pretty hard" Well, that could be. I grovelled through a lot of the official Go documentation, also third-party stuff I found with search engines. And yes, it did include reading "The Laws of Reflection". Which didn't enlighten me, but did adequately prepare me for the short explanation upthread that did, so there's that. It's difficult for me to be specific about how much coverage I achieved, because "the documentation", outside of the library pages, is kind of a poorly organized blob. Many individual parts are excellent, but it is difficult to know where to find things until one is already familiar enough with the territory that finding things has fallen down one's list of concerns. There's also a pervasive problem with the style. The Go documentation is insular and hieratic. It tends to explain things very well if you already inhabit the mindset of a Go programmer, but to not be very good at providing an entry into that mindset to people who do not already inhabit it. I've seen this movie before, it's a common problem in complex software with documentation written by its developers from the inside out. For me personally this is a relatively minor problem - not my first rodeo of this kind nor even my dozenth, I have broad experience and know how to adapt and persist. For most newbies it's going to be a serious blocker. I can recommend a fix: the team could hire a tech writer with an outside-in view (and no prior knowledge of Go) to do a serious editing pass on the documentation. -- 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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Thu, 30 Aug 2018 18:41:48 -0700 (PDT) Eric Raymond wrote: > Oh, actually, I have one other issue; how to translate virtual methods in a > Python base class into Go's object model. Inheritance based domain models do not translate directly to go's composition based ones. Forget "virtual". Forget inheritance. There is a go generate[1] that helps with rewriting polymorphic constructs. There is a whole python->go transpiler [2] too that can help with code snippets. (Seems stale though). [Personal (perl->go) story/thoughts/notes ahead. YMMV.] For me at way less daunting task the short focused transpilers written in a language I was fluent with helped significantly **to get things work** in go as they were in perl. When I had ugly but working (passing comparative tests) translation I could refactor it over time touching only transpiler templates as I learned more about new language's constructs and idioms. Then there was a point I was ready to re-write more and more in hand-written go. Lessons learned: * Do NOT emulate inheritance! Its dead end. * Do not use reflection unless you really are unable to find other ways. Its slow, its clumsy, it allows for shortcuts but through the swamps. * Translate every and each **class hierarchy** to a separate go package first. Then try to shrink exposed API. Ideas of how to do something go-way will emerge naturally in the process. * Type switch is fast but direct call is both faster and easier to grasp later[*]. * Never return interface. (Ok, unless you're a go guru making stdlibs). * Go's regexp engine is, umm, "other kind of". Do not use it unless your code has plenty of time to go ( ok, could be its a former camel pain ;) * Dig into source of go and highly revered libs (eg. [3]) for inspirations. * Do NOT emulate inheritance! Its a footcannon with cannonballs so huge that they can shoot away titanosaur's leg. :) [Criticism and addenums from more experienced gophers welcome!] [1] old but concise: https://blog.gopheracademy.com/advent-2015/reducing-boilerplate-with-go-generate/ https://github.com/myitcv/x/blob/master/gogenerate/_doc/README.md [2] https://github.com/rusthon/Rusthon [3] https://github.com/Workiva/go-datastructures [*] A dozen of func chkValid_MTxyOK (x typeMTxy) proved to be easier to maintain than a single chkValidMT(x MTcheckerInterface) one. Now common checks are factored out and all "checkable" structs have 'IsOK' methods that call relevant series of "generic" checks but this would not be done without previous translation from hierarchy to separate typed funcs) Good luck! -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- 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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Fri, Aug 31, 2018 at 11:41 AM Eric Raymond wrote: > On Thursday, August 30, 2018 at 8:31:44 PM UTC-4, Ian Lance Taylor wrote: >> Which docs did you look at? Just wondering what could be updated. > > This: https://research.swtch.com/interfaces I'm only guessing, but I think Ian's "which docs did you look at" was referring to your previous "I was unable to extract this enlightenment from the documentation, despite sweating over it pretty hard", before https://research.swtch.com/interfaces was mentioned. -- 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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Thursday, August 30, 2018 at 8:31:44 PM UTC-4, Ian Lance Taylor wrote: > > > That was helpful. I feel like I have a more solid grasp now, though > I'm a > > bit worried about what details might have changed. Is there any chance > of > > getting the author to update this and add it to the official Go > > documentation? > > Conceptually speaking, nothing has changed. > > Which docs did you look at? Just wondering what could be updated. > This: https://research.swtch.com/interfaces It did look rather like the abstractions had not changed, but I don't have the expertise to be sure. I'm successfully writing type switches on my Events now, so that is significant progress. I expect the rest of the translation to be tedious but not conceptually difficult. All 13KLOC of it, ouch. Oh, actually, I have one other issue; how to translate virtual methods in a Python base class into Go's object model. I'll start another thread about that. -- 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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Thu, Aug 30, 2018 at 4:50 PM, Eric Raymond wrote:
>
> On Thursday, August 30, 2018 at 7:25:10 PM UTC-4, Nigel Tao wrote:
>>
>> On Fri, Aug 31, 2018 at 4:18 AM Burak Serdar wrote:
>> > If b is an interface to a *Blob, what's stored in the slice is {Type:
>> > *Blob, Value: pointer to the object}. A copy of this interface value
>> > is also in the map. So you have two copies of the interface value,
>> > both pointing to the same Blob object.
>>
>> Yes, the details might have changed slightly since 2009, but
>> https://research.swtch.com/interfaces might help grok the mental model
>> for Go interfaces.
>
>
> That was helpful. I feel like I have a more solid grasp now, though I'm a
> bit worried about what details might have changed. Is there any chance of
> getting the author to update this and add it to the official Go
> documentation?
Conceptually speaking, nothing has changed.
Which docs did you look at? Just wondering what could be updated.
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.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Reference to type satisfying a specified interface
On Thursday, August 30, 2018 at 7:25:10 PM UTC-4, Nigel Tao wrote:
>
> On Fri, Aug 31, 2018 at 4:18 AM Burak Serdar > wrote:
> > If b is an interface to a *Blob, what's stored in the slice is {Type:
> > *Blob, Value: pointer to the object}. A copy of this interface value
> > is also in the map. So you have two copies of the interface value,
> > both pointing to the same Blob object.
>
> Yes, the details might have changed slightly since 2009, but
> https://research.swtch.com/interfaces might help grok the mental model
> for Go interfaces.
>
That was helpful. I feel like I have a more solid grasp now, though I'm a
bit worried about what details might have changed. Is there any chance of
getting the author to update this and add it to the official Go
documentation?
--
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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Fri, Aug 31, 2018 at 4:18 AM Burak Serdar wrote:
> If b is an interface to a *Blob, what's stored in the slice is {Type:
> *Blob, Value: pointer to the object}. A copy of this interface value
> is also in the map. So you have two copies of the interface value,
> both pointing to the same Blob object.
Yes, the details might have changed slightly since 2009, but
https://research.swtch.com/interfaces might help grok the mental model
for Go interfaces.
--
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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Thursday, August 30, 2018 at 3:00:18 PM UTC-4, Burak Serdar wrote: > > If you're porting from another language, you're likely to encounter > this situation soon, if not already. > Right, and because Python code often makes aggressive use of runtime polymorphism it's *particularly *likely to come from that direction. I don't think my case is at all a strange outlier. Maybe there ought to be a FAQ entry on this addressed to Python programmers? -- 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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Thu, Aug 30, 2018 at 12:49 PM Eric Raymond wrote:
>
>
>
> On Thursday, August 30, 2018 at 2:18:38 PM UTC-4, Burak Serdar wrote:
>>
>> If b is an interface to a *Blob, what's stored in the slice is {Type:
>> *Blob, Value: pointer to the object}. A copy of this interface value
>> is also in the map. So you have two copies of the interface value,
>> both pointing to the same Blob object.
>
>
> Thank you! That is the answer I was looking for!
>
> I note that I was unable to extract this enlightenment from the
> documentation, despite sweating over it pretty hard.
>
> Either I'm stupid or this is a documentation/tutorial issue that could stand
> to be addressed better. And I don't think I'm stupid.
I agree. This should be explained better. I myself didn't understand
it completely when I first started working with go, then I had a
day-long debugging session, which ended when I discovered this:
https://golang.org/doc/faq#nil_error
If you're porting from another language, you're likely to encounter
this situation soon, if not already.
>
> --
> 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.
--
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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Thursday, August 30, 2018 at 2:18:38 PM UTC-4, Burak Serdar wrote:
>
> If b is an interface to a *Blob, what's stored in the slice is {Type:
> *Blob, Value: pointer to the object}. A copy of this interface value
> is also in the map. So you have two copies of the interface value,
> both pointing to the same Blob object.
>
Thank you! That is the answer I was looking for!
I note that I was unable to extract this enlightenment from the
documentation, despite sweating over it pretty hard.
Either I'm stupid or this is a documentation/tutorial issue that could
stand to be addressed better. And I don't think I'm stupid.
--
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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Thu, Aug 30, 2018 at 12:09 PM Eric Raymond wrote:
>
>
>>
>> If Event is your interface and EventImpl is your struct, what you need
>> is a map[string]Event, not map[string]*Event. Make sure you put
>> {} to your slices and maps, not EventImpl{}
>>
>
> Here'a what is confusing me. Yes, I can write
>
> _mark_to_object map[string]Event
>
>
> and
>
> b.repo._mark_to_object[mark] = b
>
> for b a pointer to Blob, with Blob satisfying Event. This compiles without
> error.
>
> But what actually happens here? Is the new value a pointer to the same Blob
> instance that is in the main list, or does the code dereference b and put a
> *copy* of the blob in the map? The first behavior (reference) is what I want.
If b is an interface to a *Blob, what's stored in the slice is {Type:
*Blob, Value: pointer to the object}. A copy of this interface value
is also in the map. So you have two copies of the interface value,
both pointing to the same Blob object.
>
> --
> 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.
--
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.
Re: [go-nuts] Reference to type satisfying a specified interface
>
> If Event is your interface and EventImpl is your struct, what you need
> is a map[string]Event, not map[string]*Event. Make sure you put
> {} to your slices and maps, not EventImpl{}
>
>
Here'a what is confusing me. Yes, I can write
_mark_to_object map[string]Event
and
b.repo._mark_to_object[mark] = b
for b a pointer to Blob, with Blob satisfying Event. This compiles without
error.
But what actually happens here? Is the new value a pointer to the same Blob
instance that is in the main list, or does the code dereference b and put a
*copy* of the blob in the map? The first behavior (reference) is what I
want.
--
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.
Re: [go-nuts] Reference to type satisfying a specified interface
Basically you almost never want pointer-to-interface in practice. The temptation is to have a struct which satisfies your interface, and then you end up with thinking you want pointer-to-interface. Instead, make pointer-to-struct satisfy the interface, and then you don't need pointer-to-interface any more. On Thu, Aug 30, 2018 at 10:34 AM Eric Raymond wrote: > > > On Thursday, August 30, 2018 at 1:14:25 PM UTC-4, Jan Mercl wrote: > >> On Thu, Aug 30, 2018, 18:57 Eric Raymond wrote: >> >>> I'm trying to translate this to Go in a type-safe way. To do this, I >>> need to be able to write two declarations: "Slice of pointers to objects >>> satisfying the Event interface" >>> >> >> []*Event, but quite probably []Event is what is really needed. >> >> and "map of string keys to pointers to objects satisfying the Event >>> interface". >>> >> >> map[string]*Event, but once again, my bet is on map[string]Event. >> >> My attempts so far have yielded very cryptic error messages and no >>> success. >>> >> >> It would probably help your case if you could provide some self-contained >> example reproducing the errors and post a link to the Go Playground. >> > > That's hard. The structures are intertwingled parts of ab only partly > translated 14KLOC program But I can isolate some key declarations. If > Event is my interface type, and I write > > events []Event > _mark_to_object map[string]*Event > > as member declarations in the Repository class, and b is a pointer to a > just-allocated instance of a Blob object satisfying the Event interface, > and I write this > > b.repo._mark_to_object[mark] = b > > I get this message: > > cannot use b (type *Blob) as type *Event in assignment: > *Event is pointer to interface, not interface > > Note that the map values really do need to be pointers, because I need the > map to refer to the mutable data in the event list, not a local copy of it > in the map. What's stumping me is how to communicate this to the compiler. > > -- > 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. > -- 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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Thu, Aug 30, 2018 at 11:34 AM Eric Raymond wrote:
>
>
>
> On Thursday, August 30, 2018 at 1:14:25 PM UTC-4, Jan Mercl wrote:
>>
>> On Thu, Aug 30, 2018, 18:57 Eric Raymond wrote:
>>>
>>> I'm trying to translate this to Go in a type-safe way. To do this, I need
>>> to be able to write two declarations: "Slice of pointers to objects
>>> satisfying the Event interface"
>>
>>
>> []*Event, but quite probably []Event is what is really needed.
>>
>>> and "map of string keys to pointers to objects satisfying the Event
>>> interface".
>>
>>
>> map[string]*Event, but once again, my bet is on map[string]Event.
>>
>>> My attempts so far have yielded very cryptic error messages and no success.
>>
>>
>> It would probably help your case if you could provide some self-contained
>> example reproducing the errors and post a link to the Go Playground.
>
>
> That's hard. The structures are intertwingled parts of ab only partly
> translated 14KLOC program But I can isolate some key declarations. If Event
> is my interface type, and I write
>
> events []Event
> _mark_to_object map[string]*Event
If Event is your interface and EventImpl is your struct, what you need
is a map[string]Event, not map[string]*Event. Make sure you put
{} to your slices and maps, not EventImpl{}
>
> as member declarations in the Repository class, and b is a pointer to a
> just-allocated instance of a Blob object satisfying the Event interface, and
> I write this
>
> b.repo._mark_to_object[mark] = b
>
> I get this message:
>
> cannot use b (type *Blob) as type *Event in assignment:
> *Event is pointer to interface, not interface
>
> Note that the map values really do need to be pointers, because I need the
> map to refer to the mutable data in the event list, not a local copy of it in
> the map. What's stumping me is how to communicate this to the compiler.
>
> --
> 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.
--
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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Thursday, August 30, 2018 at 1:14:25 PM UTC-4, Jan Mercl wrote: > > On Thu, Aug 30, 2018, 18:57 Eric Raymond > > wrote: > >> I'm trying to translate this to Go in a type-safe way. To do this, I need >> to be able to write two declarations: "Slice of pointers to objects >> satisfying the Event interface" >> > > []*Event, but quite probably []Event is what is really needed. > > and "map of string keys to pointers to objects satisfying the Event >> interface". >> > > map[string]*Event, but once again, my bet is on map[string]Event. > > My attempts so far have yielded very cryptic error messages and no success. >> > > It would probably help your case if you could provide some self-contained > example reproducing the errors and post a link to the Go Playground. > That's hard. The structures are intertwingled parts of ab only partly translated 14KLOC program But I can isolate some key declarations. If Event is my interface type, and I write events []Event _mark_to_object map[string]*Event as member declarations in the Repository class, and b is a pointer to a just-allocated instance of a Blob object satisfying the Event interface, and I write this b.repo._mark_to_object[mark] = b I get this message: cannot use b (type *Blob) as type *Event in assignment: *Event is pointer to interface, not interface Note that the map values really do need to be pointers, because I need the map to refer to the mutable data in the event list, not a local copy of it in the map. What's stumping me is how to communicate this to the compiler. -- 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.
Re: [go-nuts] Reference to type satisfying a specified interface
On Thu, Aug 30, 2018, 18:57 Eric Raymond wrote: > I apologize if this seems like an elementary question, but web searches > and reading the Go documentation is not turning up an answer. > > I'm in the process of translating reposurgeon, an editor for > version-control histories, from Python into Go for improved performance, > .The central data structure is Repository, which consists mainly of a list > of events such as commits and tags. In Python, I use the language's late > binding and simply declare a list of containing multiple object types named > Commit, Tag, etc. There are also a number of lookup maps pointing at > objects in the main event list. Because objects in Pytron are passed by > reference everything is fairly straightforward. > > I'm trying to translate this to Go in a type-safe way. To do this, I need > to be able to write two declarations: "Slice of pointers to objects > satisfying the Event interface" > []*Event, but quite probably []Event is what is really needed. and "map of string keys to pointers to objects satisfying the Event > interface". > map[string]*Event, but once again, my bet is on map[string]Event. My attempts so far have yielded very cryptic error messages and no success. > It would probably help your case if you could provide some self-contained example reproducing the errors and post a link to the Go Playground. > Is it actually possible to restrict the main list's polymorphism in this > way and avoid casts? > I believe it is and that no conversions/type assertions are necessary to invoke the interface declared methods accros any instance satisfying Event in the list or map declared as suggested above. > > -- -j -- 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.
Re: [go-nuts] Reference to type satisfying a specified interface
Did you try something like this? What errors did you get?
type Event interface {
...
}
type EventImpl struct {
...
}
eventSlice:=make([]Event,0)
eventMap:=make(map[string]Event)
event:={}
eventSlice=append(eventSlice,event)
eventMap["key"]=event
On Thu, Aug 30, 2018 at 10:57 AM Eric Raymond wrote:
>
> I apologize if this seems like an elementary question, but web searches and
> reading the Go documentation is not turning up an answer.
>
> I'm in the process of translating reposurgeon, an editor for version-control
> histories, from Python into Go for improved performance, .The central data
> structure is Repository, which consists mainly of a list of events such as
> commits and tags. In Python, I use the language's late binding and simply
> declare a list of containing multiple object types named Commit, Tag, etc.
> There are also a number of lookup maps pointing at objects in the main event
> list. Because objects in Pytron are passed by reference everything is fairly
> straightforward.
>
> I'm trying to translate this to Go in a type-safe way. To do this, I need to
> be able to write two declarations: "Slice of pointers to objects satisfying
> the Event interface" and "map of string keys to pointers to objects
> satisfying the Event interface". My attempts so far have yielded very
> cryptic error messages and no success.
>
> Is it actually possible to restrict the main list's polymorphism in this way
> and avoid casts?
>
>
>
>
>
>
>
>
> --
> 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.
--
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.
[go-nuts] Reference to type satisfying a specified interface
I apologize if this seems like an elementary question, but web searches and reading the Go documentation is not turning up an answer. I'm in the process of translating reposurgeon, an editor for version-control histories, from Python into Go for improved performance, .The central data structure is Repository, which consists mainly of a list of events such as commits and tags. In Python, I use the language's late binding and simply declare a list of containing multiple object types named Commit, Tag, etc. There are also a number of lookup maps pointing at objects in the main event list. Because objects in Pytron are passed by reference everything is fairly straightforward. I'm trying to translate this to Go in a type-safe way. To do this, I need to be able to write two declarations: "Slice of pointers to objects satisfying the Event interface" and "map of string keys to pointers to objects satisfying the Event interface". My attempts so far have yielded very cryptic error messages and no success. Is it actually possible to restrict the main list's polymorphism in this way and avoid casts? -- 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.
