Grokbase › Groups › Go › golang-nuts › October 2014
FAQ
I never understood that[1]:

"Languages with methods typically fall into one of two camps: prepare
tables for all the method calls statically (as in C++ and Java), or do
a method lookup at each call (as in Smalltalk and its many imitators,
JavaScript and Python included) and add fancy caching to make that
call efficient. Go sits halfway between the two: it has method tables
but computes them at run time. I don't know whether Go is the first
language to use this technique, but it's certainly not a common one.
(I'd be interested to hear about earlier examples; leave a comment
below.)"

What means "it has method tables but computes them at run time."?

If I understand clearly:
- method names are checked (ie. "static duck typing") on compilation (static)
- but not the content of methods (dynamic)

Right?


[1] http://research.swtch.com/interfaces

--
Sebastien Douche <[email protected]>
Twitter: @sdouche / G+: +sdouche

--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Ian Lance Taylor at Oct 2, 2014 at 11:45 pm ⇧

    On Thu, Oct 2, 2014 at 4:31 PM, Sebastien Douche wrote:
    I never understood that[1]:

    "Languages with methods typically fall into one of two camps: prepare
    tables for all the method calls statically (as in C++ and Java), or do
    a method lookup at each call (as in Smalltalk and its many imitators,
    JavaScript and Python included) and add fancy caching to make that
    call efficient. Go sits halfway between the two: it has method tables
    but computes them at run time. I don't know whether Go is the first
    language to use this technique, but it's certainly not a common one.
    (I'd be interested to hear about earlier examples; leave a comment
    below.)"

    What means "it has method tables but computes them at run time."?
    Go uses method tables, so that a method call is a fetch of a known
    offset in a table, just like a C++ virtual call. However, in C++, the
    virtual table can be constructed entirely at compile time, because the
    relationship between the real type of the object and the type of the
    reference is always known at compile time. In Go this is not true,
    because Go does not require types to declare which interfaces they
    satisfy, and Go permits dynamic conversions from one interface type to
    another. When such a conversion occurs, the Go runtime needs to build
    a new method table, and that can only be done dynamically.

    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Sebastien Douche at Oct 2, 2014 at 11:54 pm ⇧

    On Fri, Oct 3, 2014 at 1:45 AM, Ian Lance Taylor wrote:
    What means "it has method tables but computes them at run time."?
    Go uses method tables, so that a method call is a fetch of a known
    offset in a table, just like a C++ virtual call. However, in C++, the
    virtual table can be constructed entirely at compile time, because the
    relationship between the real type of the object and the type of the
    reference is always known at compile time. In Go this is not true,
    because Go does not require types to declare which interfaces they
    satisfy, and Go permits dynamic conversions from one interface type to
    another. When such a conversion occurs, the Go runtime needs to build
    a new method table, and that can only be done dynamically.
    Understood, Thanks Ian.


    --
    Sebastien Douche <[email protected]>
    Twitter: @sdouche / G+: +sdouche

    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • ⚛ at Oct 3, 2014 at 12:25 pm ⇧
    Just a note. The current Go implementation does not allow the program to
    create new interface types at runtime. The set of interface types is
    statically known at compile-time. In theory, the compiler could create
    precomputed tables that would allow conversions to be performed without
    dynamically creating new data at runtime. As far as I know, this approach
    hasn't been tried yet so we do not know how it would impact memory
    consumption and program size.
    On Friday, October 3, 2014 1:46:46 AM UTC+2, Ian Lance Taylor wrote:

    On Thu, Oct 2, 2014 at 4:31 PM, Sebastien Douche <[email protected]
    <javascript:>> wrote:
    I never understood that[1]:

    "Languages with methods typically fall into one of two camps: prepare
    tables for all the method calls statically (as in C++ and Java), or do
    a method lookup at each call (as in Smalltalk and its many imitators,
    JavaScript and Python included) and add fancy caching to make that
    call efficient. Go sits halfway between the two: it has method tables
    but computes them at run time. I don't know whether Go is the first
    language to use this technique, but it's certainly not a common one.
    (I'd be interested to hear about earlier examples; leave a comment
    below.)"

    What means "it has method tables but computes them at run time."?
    Go uses method tables, so that a method call is a fetch of a known
    offset in a table, just like a C++ virtual call. However, in C++, the
    virtual table can be constructed entirely at compile time, because the
    relationship between the real type of the object and the type of the
    reference is always known at compile time. In Go this is not true,
    because Go does not require types to declare which interfaces they
    satisfy, and Go permits dynamic conversions from one interface type to
    another. When such a conversion occurs, the Go runtime needs to build
    a new method table, and that can only be done dynamically.

    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Oct 3, 2014 at 1:20 pm ⇧

    On Fri, Oct 3, 2014 at 5:25 AM, ⚛ wrote:
    Just a note. The current Go implementation does not allow the program to
    create new interface types at runtime. The set of interface types is
    statically known at compile-time. In theory, the compiler could create
    precomputed tables that would allow conversions to be performed without
    dynamically creating new data at runtime. As far as I know, this approach
    hasn't been tried yet so we do not know how it would impact memory
    consumption and program size.
    Pedantically speaking, you only have all the information at link time.

    The gccgo compiler statically computes, at compile time, the interface
    method tables that it knows will be required. However, it still needs
    to dynamically allocate an interface method table when a type defined
    in one package is converted to an interface defined in another package
    via a second interface type, such that the compiler never sees the
    actual association of static and dynamic types.

    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Kevin Gillette at Oct 3, 2014 at 4:49 pm ⇧

    On Friday, October 3, 2014 7:20:35 AM UTC-6, Ian Lance Taylor wrote:
    Pedantically speaking, you only have all the information at link time.
    Unlike machine code, afaict, Go method tables have a simple, uniform
    structure which might not be too awkward for a linker to generate. Doing so
    could allow some optimizations that may or may not already be done at
    runtime, such as packing io's Reader and Writer tables for a given type
    into the ReadWriter table. However, it's doubtful that this would have
    measurable benefit on typical platforms, and it may be altogether useless
    if we ever add runtime library/plugin loading.

    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 2, '14 at 11:32p
activeOct 3, '14 at 4:49p
posts6
users4
websitegolang.org

4 users in discussion

Ian Lance Taylor: 2 posts Sebastien Douche: 2 posts Kevin Gillette: 1 post ⚛: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase