FAQ
In order to implement intrusive interfaces[1] I propose a new parent()
built-in that returns the parent of a struct member. It can be statically
checked and thus always work as long as the fallowing constraints are
followed:

parent() on the same type in the same function return the type (and
corresponding pointer offset) corresponding to the first call of parent()
on that type in the function

parent() on the same struct member (this always has the same address)
return the same result as the first call of parent() on this struct member.
-- this is only useful when the result of parent() isn't acutally the
parent, and thus is kinda gross, but allows Tree Root node accessors.

It would be expected that the compiler would optimize these calls into a
simple subtraction from a value that would be passed on the stack. Fuctions
would be tagged by the compiler as to what offsetof() result to give them.

I've written a redblack tree implementation that uses this
feature: https://github.com/shawnl/go/commit/c9269c57055e9d69593c2d9fb616e54f224c5710

I could write a linked-list that would use this and be simpler for a first
compiler target, based on this attempt to hack it in without compiler
support: https://godoc.org/github.com/tv42/intrusive

[1]
https://github.com/torvalds/linux/blob/master/Documentation/rbtree.txt#L140
https://godoc.org/github.com/tv42/intrusive

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Shawn Landden at Mar 26, 2015 at 1:38 am

    On Wednesday, March 25, 2015 at 6:32:58 PM UTC-7, Shawn Landden wrote:
    In order to implement intrusive interfaces[1] I propose a new parent()
    built-in that returns the parent of a struct member. It can be statically
    checked and thus always work as long as the fallowing constraints are
    followed:

    parent() on the same type in the same function return the type (and
    corresponding pointer offset) corresponding to the first call of parent()
    on that type in the function

    parent() on the same struct member (this always has the same address)
    return the same result as the first call of parent() on this struct member.
    -- this is only useful when the result of parent() isn't acutally the
    parent, and thus is kinda gross, but allows Tree Root node accessors.

    parent() can also be used to specify types in function declarations.
    Perhaps this should be unsafe.Parent() as it could be used to subvert the
    type system.
    It would be expected that the compiler would optimize these calls into a
    simple subtraction from a value that would be passed on the stack. Fuctions
    would be tagged by the compiler as to what offsetof() result to give them.

    I've written a redblack tree implementation that uses this feature:
    https://github.com/shawnl/go/commit/c9269c57055e9d69593c2d9fb616e54f224c5710

    I could write a linked-list that would use this and be simpler for a first
    compiler target, based on this attempt to hack it in without compiler
    support: https://godoc.org/github.com/tv42/intrusive

    [1]
    https://github.com/torvalds/linux/blob/master/Documentation/rbtree.txt#L140
    https://godoc.org/github.com/tv42/intrusive
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Mar 26, 2015 at 3:57 am

    On Wed, Mar 25, 2015 at 6:32 PM, Shawn Landden wrote:
    In order to implement intrusive interfaces[1] I propose a new parent()
    built-in that returns the parent of a struct member.
    I'm sorry, I don't understand what this means, and I don't understand
    your example. What is the parent of a struct member?

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Mar 26, 2015 at 4:10 am

    On Wed, 2015-03-25 at 20:57 -0700, Ian Lance Taylor wrote:
    I'm sorry, I don't understand what this means, and I don't understand
    your example. What is the parent of a struct member?
    I think he means something like

    type A struct {
      B int
    }

    Here the parent would be A, and B the child. Though the code he links is
    unclear.

    This idea has been put forward before by people wanting to simulate
    inheritance.


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Mar 26, 2015 at 2:50 pm

    On Wed, Mar 25, 2015 at 9:10 PM, Dan Kortschak wrote:
    On Wed, 2015-03-25 at 20:57 -0700, Ian Lance Taylor wrote:
    I'm sorry, I don't understand what this means, and I don't understand
    your example. What is the parent of a struct member?
    I think he means something like

    type A struct {
    B int
    }

    Here the parent would be A, and B the child. Though the code he links is
    unclear.

    This idea has been put forward before by people wanting to simulate
    inheritance.
    In a language like Go, you can't refer to B in the abstract. That
    doesn't make sense. You can only refer to B in the context of A. And
    Go already provides that operation: unsafe.Offsetof(A{}.B).

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Mar 26, 2015 at 7:57 pm
    Yes, just interpreting what the OP was saying.
    On 27/03/2015, at 1:20 AM, "Ian Lance Taylor" wrote:

    This idea has been put forward before by people wanting to simulate
    inheritance.
    In a language like Go, you can't refer to B in the abstract. That
    doesn't make sense. You can only refer to B in the context of A. And
    Go already provides that operation: unsafe.Offsetof(A{}.B).
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Shawn Landden at Mar 28, 2015 at 12:31 am

    On Thursday, March 26, 2015 at 7:50:33 AM UTC-7, Ian Lance Taylor wrote:
    On Wed, Mar 25, 2015 at 9:10 PM, Dan Kortschak
    <dan.ko...@adelaide.edu.au <javascript:>> wrote:
    On Wed, 2015-03-25 at 20:57 -0700, Ian Lance Taylor wrote:
    I'm sorry, I don't understand what this means, and I don't understand
    your example. What is the parent of a struct member?
    I think he means something like

    type A struct {
    B int
    }

    Here the parent would be A, and B the child. Though the code he links is
    unclear.

    This idea has been put forward before by people wanting to simulate
    inheritance.
    In a language like Go, you can't refer to B in the abstract. That
    doesn't make sense. You can only refer to B in the context of A. And
    Go already provides that operation: unsafe.Offsetof(A{}.B).
    I only want to use parent() in places where unsafe.Offsetof() could be used
    in the function that is calling the function that is calling parent, and
    the compiler would heave out the call to the calling function.
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Mar 28, 2015 at 12:51 am

    On Fri, Mar 27, 2015 at 5:31 PM, Shawn Landden wrote:
    On Thursday, March 26, 2015 at 7:50:33 AM UTC-7, Ian Lance Taylor wrote:

    On Wed, Mar 25, 2015 at 9:10 PM, Dan Kortschak
    wrote:
    On Wed, 2015-03-25 at 20:57 -0700, Ian Lance Taylor wrote:
    I'm sorry, I don't understand what this means, and I don't understand
    your example. What is the parent of a struct member?
    I think he means something like

    type A struct {
    B int
    }

    Here the parent would be A, and B the child. Though the code he links is
    unclear.

    This idea has been put forward before by people wanting to simulate
    inheritance.
    In a language like Go, you can't refer to B in the abstract. That
    doesn't make sense. You can only refer to B in the context of A. And
    Go already provides that operation: unsafe.Offsetof(A{}.B).
    I only want to use parent() in places where unsafe.Offsetof() could be used
    in the function that is calling the function that is calling parent, and the
    compiler would heave out the call to the calling function.
    In the example code you mentioned earlier you seem to be calling
    parent in type declarations. Now you are saying that you want to call
    it in functions, which seems like quite a different thing. Can you
    show a small standalone example of what Go code that uses parent would
    look like?

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Shawn Landden at Mar 28, 2015 at 2:27 am

    On Friday, March 27, 2015 at 5:51:46 PM UTC-7, Ian Lance Taylor wrote:
    On Fri, Mar 27, 2015 at 5:31 PM, Shawn Landden <shawnl...@gmail.com
    <javascript:>> wrote:
    On Thursday, March 26, 2015 at 7:50:33 AM UTC-7, Ian Lance Taylor wrote:

    On Wed, Mar 25, 2015 at 9:10 PM, Dan Kortschak
    wrote:
    On Wed, 2015-03-25 at 20:57 -0700, Ian Lance Taylor wrote:
    I'm sorry, I don't understand what this means, and I don't
    understand
    your example. What is the parent of a struct member?
    I think he means something like

    type A struct {
    B int
    }

    Here the parent would be A, and B the child. Though the code he links
    is
    unclear.

    This idea has been put forward before by people wanting to simulate
    inheritance.
    In a language like Go, you can't refer to B in the abstract. That
    doesn't make sense. You can only refer to B in the context of A. And
    Go already provides that operation: unsafe.Offsetof(A{}.B).
    I only want to use parent() in places where unsafe.Offsetof() could be used
    in the function that is calling the function that is calling parent, and the
    compiler would heave out the call to the calling function.
    In the example code you mentioned earlier you seem to be calling
    parent in type declarations. Now you are saying that you want to call
    it in functions, which seems like quite a different thing. Can you
    show a small standalone example of what Go code that uses parent would
    look like?
    I posted this topic when I first realized how to do it, but it is unclear
    and I realize it is not well understood. I will post a better write-up in a
    few days.
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at Mar 26, 2015 at 8:16 pm

    On Thursday, 26 March 2015 03:32:58 UTC+2, Shawn Landden wrote:
    In order to implement intrusive interfaces[1] I propose a new parent()
    built-in that returns the parent of a struct member. It can be statically
    checked and thus always work as long as the fallowing constraints are
    followed:

    parent() on the same type in the same function return the type (and
    corresponding pointer offset) corresponding to the first call of parent()
    on that type in the function

    parent() on the same struct member (this always has the same address)
    return the same result as the first call of parent() on this struct member.
    -- this is only useful when the result of parent() isn't acutally the
    parent, and thus is kinda gross, but allows Tree Root node accessors.

    It would be expected that the compiler would optimize these calls into a
    simple subtraction from a value that would be passed on the stack. Fuctions
    would be tagged by the compiler as to what offsetof() result to give them.

    I've written a redblack tree implementation that uses this feature:
    https://github.com/shawnl/go/commit/c9269c57055e9d69593c2d9fb616e54f224c5710
    Not quite sure why are you implementing redblack with an interface in the
    first place, so I really can't recommend anything exact. I would recommend
    writing the thing you actually need, instead of generic structures - it
    ensures that you get something useful in the end.

    I could write a linked-list that would use this and be simpler for a first
    compiler target, based on this attempt to hack it in without compiler
    support: https://godoc.org/github.com/tv42/intrusive
    You probably shouldn't be using linked-lists -
    https://www.youtube.com/watch?v=YQs6IC-vgmo.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 26, '15 at 1:33a
activeMar 28, '15 at 2:27a
posts10
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase