Hi Christopher, Sharp eyes! Yes, in the current shape example, they are the same and so Dynamic() is redundant. Thanks for pointing it out!
I have reviewed my projects and there are indeed some niche scenarios where I have the Dynamic() method of a descendant at, say, depth 2 return a VTable that points to its ancestor instead (that would be a descendant at depth 1). The actual reason in one such scenario has to do with the way I structure my code: the factory method at a greater depth enforces a more specific invariant on the data but ultimately the data has the same shape for all intent and purposes from the perspective of an external client. So returning a VTable pointing to the highest ancestor that has the right shape may make sense (e.g., the client may be serializing the data). If there is any interest, I should be able to come up with something using shape to demo this structure. Thanks! Maverick On Tuesday, March 13, 2018 at 5:53:05 PM UTC-4, Christopher Sebastian wrote: > > Hi Maverick, this is an interesting VTable pattern to think about. > > I have a question about your Dynamic() method. As far as I can see, these > two expressions would always be equal: > > myShape.Dynamic() > myShape.VTable > > ...So why go through the trouble of defining Dynamic() at all? Is there > some use-case I'm overlooking? > > Thanks, > ~Christopher > -- 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.
