FAQ
Some programming languages (C, C++, Python, etc...) are defined based on
the "object" concept, which essentially refers to a region of memory
storage.

Yet, Go supports zero-size variables[1], and in the language's specs the
word "object" only appears in a reference to "higher-dimensional
objects"[2].

Considering this, does Go have objects? If it has, how are they defined?


Thanks in advance,
Rui Maciel

[1] http://golang.org/ref/spec#Size_and_alignment_guarantees
[2] http://golang.org/ref/spec#Slice_types

--

Search Discussions

  • Minux at Jan 9, 2013 at 11:28 am

    On Wed, Jan 9, 2013 at 7:12 PM, Rui Maciel wrote:

    Some programming languages (C, C++, Python, etc...) are defined based on
    the "object" concept, which essentially refers to a region of memory
    storage.

    Yet, Go supports zero-size variables[1], and in the language's specs the
    word "object" only appears in a reference to "higher-dimensional
    objects"[2].
    why having support for zero-size variables has something to do with the
    object concept?
    why there couldn't be zero-sized object?
    Considering this, does Go have objects? If it has, how are they defined?
    What's your definition of object?

    --
  • Rui Maciel at Jan 9, 2013 at 12:37 pm

    On 01/09/2013 11:28 AM, minux wrote:
    On Wed, Jan 9, 2013 at 7:12 PM, Rui Maciel wrote:

    Some programming languages (C, C++, Python, etc...) are defined based on
    the "object" concept, which essentially refers to a region of memory
    storage.

    Yet, Go supports zero-size variables[1], and in the language's specs the
    word "object" only appears in a reference to "higher-dimensional
    objects"[2].
    why having support for zero-size variables has something to do with the
    object concept?
    why there couldn't be zero-sized object?
    I've explained that in the post you've answered to.

    Considering this, does Go have objects? If it has, how are they defined?
    What's your definition of object?
    It's irrelevant if I, personally, even have a definition for an object.
    The only thing that matters is if Go has them, and if it has what's
    Go's definition.


    Rui Maciel

    --
  • Nate Finch at Jan 9, 2013 at 1:11 pm
    Go has structs which hold data and can have functions associated with
    them. They can be passed by value or by address as a pointer. You can also
    create a custom type that is basically just a renamed basic type (like int)
    and create functions for it. So, for example, you could have CustomInt
    which is an int, and create the function Square() for it. You can use it
    exactly like an int, but it also has this method on it that can be called.

    There is no one base type that all types inherit from, like there is in
    some languages (like C# or Java or to a certain extent Python).

    Go does not use the word object because that word is fairly heavily laden
    with implications that are not always true in Go.

    If you're asking if Go can support object oriented programming, the answer
    is yes, though with some qualifications.
    On Wednesday, January 9, 2013 7:37:01 AM UTC-5, Rui Maciel wrote:


    On 01/09/2013 11:28 AM, minux wrote:
    On Wed, Jan 9, 2013 at 7:12 PM, Rui Maciel wrote:

    Some programming languages (C, C++, Python, etc...) are defined based
    on
    the "object" concept, which essentially refers to a region of memory
    storage.

    Yet, Go supports zero-size variables[1], and in the language's specs
    the
    word "object" only appears in a reference to "higher-dimensional
    objects"[2].
    why having support for zero-size variables has something to do with the
    object concept?
    why there couldn't be zero-sized object?
    I've explained that in the post you've answered to.

    Considering this, does Go have objects? If it has, how are they
    defined?
    What's your definition of object?
    It's irrelevant if I, personally, even have a definition for an object.
    The only thing that matters is if Go has them, and if it has what's
    Go's definition.


    Rui Maciel
    --
  • Ian Lance Taylor at Jan 9, 2013 at 2:34 pm

    On Wed, Jan 9, 2013 at 4:37 AM, Rui Maciel wrote:
    It's irrelevant if I, personally, even have a definition for an object. The
    only thing that matters is if Go has them, and if it has what's Go's
    definition.
    I don't understand why that is an interesting question to ask, but I
    think the answer is clear: Go does not have a definition of "object."

    As this e-mail thread shows, in programming the term "object" is
    overloaded and can be confusing. Go can reasonably claim to be an
    "object-oriented language," but the details of the claim depend on the
    details of the language. It's better to describe those details
    precisely than to rely on an overloaded term like "object."

    Ian

    --
  • Ian Lance Taylor at Jan 9, 2013 at 2:29 pm

    On Wed, Jan 9, 2013 at 6:26 AM, Ian Lance Taylor wrote:
    Go can reasonably claim to be an "object-oriented language," but the details of the claim depend on the
    details of the language.
    Let me rephrase that in a way that makes more sense: Go can reasonably
    claim to support "object-oriented programming."

    Ian

    --
  • Steve wang at Jan 9, 2013 at 3:27 pm
    So does it have an official name of coding style?
    A type-oriented language? I guess over 90% of Go programmers have to type
    "type" when coding.
    :D
    On Wednesday, January 9, 2013 10:28:58 PM UTC+8, Ian Lance Taylor wrote:
    On Wed, Jan 9, 2013 at 6:26 AM, Ian Lance Taylor wrote:

    Go can reasonably claim to be an "object-oriented language," but the
    details of the claim depend on the
    details of the language.
    Let me rephrase that in a way that makes more sense: Go can reasonably
    claim to support "object-oriented programming."

    Ian
    --
  • Ian Lance Taylor at Jan 9, 2013 at 3:58 pm

    On Wed, Jan 9, 2013 at 7:12 AM, steve wang wrote:
    So does it have an official name of coding style?
    A type-oriented language? I guess over 90% of Go programmers have to type
    "type" when coding.
    "Programming."

    Ian

    On Wednesday, January 9, 2013 10:28:58 PM UTC+8, Ian Lance Taylor wrote:
    On Wed, Jan 9, 2013 at 6:26 AM, Ian Lance Taylor wrote:

    Go can reasonably claim to be an "object-oriented language," but the
    details of the claim depend on the
    details of the language.
    Let me rephrase that in a way that makes more sense: Go can reasonably
    claim to support "object-oriented programming."

    Ian
    --
    --
  • Rui Maciel at Jan 9, 2013 at 8:04 pm

    On 01/09/2013 02:26 PM, Ian Lance Taylor wrote:
    I don't understand why that is an interesting question to ask, but I
    think the answer is clear: Go does not have a definition of "object."

    As this e-mail thread shows, in programming the term "object" is
    overloaded and can be confusing.
    This isn't true. I've referred to a hand full of programming languages
    whose specifications include an objective and precise definition of
    what, according to them, represents an object. With that, if you use
    one of those languages and you refer to objects, you are referring to
    specific concepts whose meaning is well defined and quite clear.

    Go can reasonably claim to be an
    "object-oriented language,"
    If you read the post that started this discussion you will notice that
    the concept of an "object" I referred to is completely independent and
    well separated from the object-oriented programming paradigm. You
    referred to an entirely different thing than the one that has been
    referred here.

    but the details of the claim depend on the
    details of the language. It's better to describe those details
    precisely than to rely on an overloaded term like "object."
    The concept I referred to is already well defined. Read up on a
    specification of any of the programming languages I've mentioned to
    understand what's been talked about. As a hint, it isn't
    object-oriented programming.


    Rui Maciel

    --
  • Itmitica at Jan 9, 2013 at 8:24 pm
    In programming, any programming, an object is something you process. Its
    particulars (like having a zero size) are not demoting its classification
    in any way.

    I would Go on a limb here and say that the simplest 0, for example, as a
    constant token, it's an object, since it's internal software representation
    and its hardware projection relies on a complete set of mechanisms and
    concepts.

    So in my opinion, Go is nothing but objects.

    --
  • Kyle Lemons at Jan 9, 2013 at 8:29 pm
    On Wed, Jan 9, 2013 at 3:04 PM, Rui Maciel wrote:
    On 01/09/2013 02:26 PM, Ian Lance Taylor wrote:

    I don't understand why that is an interesting question to ask, but I
    think the answer is clear: Go does not have a definition of "object."

    As this e-mail thread shows, in programming the term "object" is
    overloaded and can be confusing.
    This isn't true. I've referred to a hand full of programming languages
    whose specifications include an objective and precise definition of what,
    according to them, represents an object. With that, if you use one of
    those languages and you refer to objects, you are referring to specific
    concepts whose meaning is well defined and quite clear.



    Go can reasonably claim to be an
    "object-oriented language,"
    If you read the post that started this discussion you will notice that the
    concept of an "object" I referred to is completely independent and well
    separated from the object-oriented programming paradigm. You referred to
    an entirely different thing than the one that has been referred here.
    but the details of the claim depend on the
    details of the language. It's better to describe those details
    precisely than to rely on an overloaded term like "object."
    The concept I referred to is already well defined. Read up on a
    specification of any of the programming languages I've mentioned to
    understand what's been talked about. As a hint, it isn't object-oriented
    programming.

    I think this is a restatement of what Ian said. Within the confines of a
    particular language, the term "object" might have well-defined meaning, but
    would it make sense to carry the Ada98 meaning of an object into a Python
    context? You will have to define what you want "object" to mean in a Go
    context before you can answer your question. You have provided a few
    definitions from other languages so far: memory region (applies to
    Go), "run-time
    entity that contains (has) a value of the type" (sounds more like a
    variable to me, but sure Go has them). Because Go itself would seem to
    favor avoiding baggage from other languages' idea of an "object" by using
    the term itself, you will have to provide your own.

    My suspicion is that there is some more fundamental question for which
    you'd like an answer, and which is orthogonal to the terms used to describe
    semantics. Are you looking for whether Go supports particular design
    patterns? Are you looking for what other languages' definitions of objects
    might be closely aligned enough that porting would be easy? Are you
    looking for a description of the type system which will help your C++ or
    Java coworkers understand it? If you really are concerned with
    terminology, I think you will find that defining most aspects of Go in
    "industry standard" terms is going to be unsatisfying. Go has interfaces
    which are radically different from the way they are used in Java, Go does
    not have classes in the way a C++ programmer might expect, and Go
    incorporates the principles of CSP in a way that is subtly different from
    what Hoare or an Occam programmer would use. If you could give us more
    insight into what you seek to learn by asking your question, we might be
    able to give you a more satisfying answer.

    --
  • Bryan Mills at Jan 9, 2013 at 8:34 pm

    On Wednesday, January 9, 2013 3:04:17 PM UTC-5, Rui Maciel wrote:
    On 01/09/2013 02:26 PM, Ian Lance Taylor wrote:
    I don't understand why that is an interesting question to ask, but I
    think the answer is clear: Go does not have a definition of "object."

    As this e-mail thread shows, in programming the term "object" is
    overloaded and can be confusing.
    This isn't true. I've referred to a hand full of programming languages
    whose specifications include an objective and precise definition of
    what, according to them, represents an object. With that, if you use
    one of those languages and you refer to objects, you are referring to
    specific concepts whose meaning is well defined and quite clear.

    Go can reasonably claim to be an
    "object-oriented language,"
    If you read the post that started this discussion you will notice that
    the concept of an "object" I referred to is completely independent and
    well separated from the object-oriented programming paradigm. You
    referred to an entirely different thing than the one that has been
    referred here.

    but the details of the claim depend on the
    details of the language. It's better to describe those details
    precisely than to rely on an overloaded term like "object."
    The concept I referred to is already well defined. Read up on a
    specification of any of the programming languages I've mentioned to
    understand what's been talked about. As a hint, it isn't
    object-oriented programming.
    I'm pretty sure Ian is already quite familiar with the specifications for C
    and C++. (http://research.google.com/pubs/author37504.html)
    You haven't really defined what you mean by "object".

    With regard to "regions of memory storage", Go does have a notion of
    "addressable operands" (http://golang.org/ref/spec#Address_operators) which
    seems to be similar to the concept you're asking about. Why does it matter
    whether they're called "objects" or not?

    --
  • Bob Hutchison at Jan 15, 2013 at 4:26 pm

    On 2013-01-09, at 3:04 PM, Rui Maciel wrote:


    On 01/09/2013 02:26 PM, Ian Lance Taylor wrote:
    I don't understand why that is an interesting question to ask, but I
    think the answer is clear: Go does not have a definition of "object."

    As this e-mail thread shows, in programming the term "object" is
    overloaded and can be confusing.
    This isn't true. I've referred to a hand full of programming languages whose specifications include an objective and precise definition of what, according to them, represents an object. With that, if you use one of those languages and you refer to objects, you are referring to specific concepts whose meaning is well defined and quite clear.
    Here's part of your original post:
    Some programming languages (C, C++, Python, etc...) are defined based on the "object" concept, which essentially refers to a region of memory storage.
    This use of 'object' is a very *old* way of talking about things in programming languages. Basically it's a memory location containing a value that has an identifier (the identifier bit matters here). This is a pre OO thing (I'm trying to dredge it up from more than 30 years ago). Furthermore, no programming language is defined based on that 'object' concept, at most the programming language definition will indicate which entities must be/can be 'objects'. The compiler may or may not be free to optimize these 'objects' away. This kind of 'object' is a 'detail' and isn't very interesting for the most part to a programmer in the language.

    No OO language would use the old definition of 'object' anywhere in its specification unless it 'leaked' into the definition… doing so would be a guaranteed ambiguity.

    If this is the definition of 'object' you want to use, then of course Go has 'objects'… and I'd expect you already know that if you understood your own question.

    Yet, Go supports zero-size variables[1], and in the language's specs the word "object" only appears in a reference to "higher-dimensional objects"[2].
    The Go specification uses the word 'objects' exactly once and it isn't clear if it is referring to 'object' or just some value (and it doesn't matter since the usage in the spec is quite informal).
    Considering this, does Go have objects? If it has, how are they defined?
    As I said before, of course Go has 'objects' by the old definition. And they are defined as I said above. The language spec doesn't use the word 'object', and really doesn't even bother with the concept, but it shouldn't difficult to work out what are or could be objects. Enumerating them would be kinda boring and pointless though. And for what it's worth, using the word 'object' in the sense you're talking about really should be avoided (witness this thread) -- whether you like it or not, the meaning of the word has changed.

    Even though you aren't interested, as far as the current meaning of 'object', in my opinion, there's nothing in Go that is an object in the sense implied by object-oriented.
    but the details of the claim depend on the
    details of the language. It's better to describe those details
    precisely than to rely on an overloaded term like "object."
    The concept I referred to is already well defined. Read up on a specification of any of the programming languages I've mentioned to understand what's been talked about. As a hint, it isn't object-oriented programming.
    You might want to re-read those specifications carefully yourself.

    Cheers,
    Bob

    Rui Maciel

    --
    --
  • Jeremy Wall at Jan 9, 2013 at 4:39 pm

    On Wed, Jan 9, 2013 at 6:37 AM, Rui Maciel wrote:
    On 01/09/2013 11:28 AM, minux wrote:
    On Wed, Jan 9, 2013 at 7:12 PM, Rui Maciel wrote:

    Some programming languages (C, C++, Python, etc...) are defined based on
    the "object" concept, which essentially refers to a region of memory
    storage.

    Yet, Go supports zero-size variables[1], and in the language's specs the
    word "object" only appears in a reference to "higher-dimensional
    objects"[2].
    why having support for zero-size variables has something to do with the
    object concept?
    why there couldn't be zero-sized object?

    I've explained that in the post you've answered to.


    Considering this, does Go have objects? If it has, how are they defined?
    What's your definition of object?

    It's irrelevant if I, personally, even have a definition for an object. The
    only thing that matters is if Go has them, and if it has what's Go's
    definition.
    Go doesn't necessarily have a definition of an object in the
    Specification if that's what you mean.

    However Go does fit the Classical definition of an object as an entity
    that can respond to messages and store state.
    If the goal of your question is to understand how Go approaches Object
    Oriented programming then that would be your answer.

    Any type that has methods is an Object when instantiated. Code reuse
    is accomplished by composing Objects. State can be stored in the
    Object
    but the type system doesn't enforce that an object *must* store state.

    Rui Maciel

    --
    --
  • André Moraes at Jan 9, 2013 at 11:51 am
    Go have types and types can have methods.

    Having that said,

    The basic definition of an "object" (oo thinking) is something that
    CAN have storage and CAN respond to messages:
    Under this definition, anything can be a object in Go, as long, it's
    type have the methods.

    Others consider objects to be "regions of memory" that are handled
    together (struct, slices, arrays, maps):
    Under this definition, go also have objects. And unlike Python/Java,
    in Go, your struct object take the size that you declared. This mean
    that a empty struct (struct{}) don't take any space.

    Slices/maps when empty do take space (just a little)

    Arrays only take the space that you declared (I don't see why somebody
    will create an array with 0 size)

    http://research.swtch.com/godata
    http://research.swtch.com/interfaces

    --
    André Moraes
    http://amoraes.info

    --
  • Chris dollin at Jan 9, 2013 at 11:54 am

    On 9 January 2013 11:12, Rui Maciel wrote:
    Some programming languages (C, C++, Python, etc...) are defined based on the
    "object" concept, which essentially refers to a region of memory storage.
    That's one way of looking at it. Another way is to say that
    an object is something that can respond to messages -- it
    /might/ have an associated region of storage, or it might not.
    The "region of memory" is a very C[++] view.
    Yet, Go supports zero-size variables[1],
    Regions can be empty ...
    and in the language's specs the
    word "object" only appears in a reference to "higher-dimensional
    objects"[2].

    Considering this, does Go have objects?
    Suppose I said "yes". What would the consequences be?

    Suppose I said "no". What would the consequences be?
    If it has, how are they defined?
    Not formally.

    Chris

    --
    Chris "allusive" Dollin

    --
  • Aram Hăvărneanu at Jan 9, 2013 at 11:41 am
    iridium:aram$ cat a.cc
    #include <stdio.h>

    class T {
    int z[0];
    };

    int
    main() {
    printf("%ld\n", sizeof(T));
    }
    iridium:aram$ g++ a.cc
    iridium:aram$ a.out


    --
    Aram Hăvărneanu

    --
  • Rui Maciel at Jan 10, 2013 at 3:28 am

    On 01/09/2013 11:40 AM, Aram Hăvărneanu wrote:
    iridium:aram$ cat a.cc
    #include <stdio.h>

    class T {
    int z[0];
    };

    int
    main() {
    printf("%ld\n", sizeof(T));
    }
    iridium:aram$ g++ a.cc
    iridium:aram$ a.out
    Your code is broken. The C++ standard states the following [8.3.4]

    <quote>
    8.3.4 Arrays

    In a declaration T D where D has the form
    D1 [ constant-expressionopt ] attribute-specifier-seqopt

    (...)

    If the constant-expression (5.19) is present, it shall be an integral
    constant expression and its value shall be greater than zero.
    <quote/>

    Here's what clang++ says about your code:

    <quote>
    rui@localhost:tmp$ clang++ --pedantic a.c++
    main.c++:4:8: warning: zero size arrays are an extension [-pedantic]
    int z[0];
    ^
    1 warning generated.
    </quote>


    And here's what g++ says about your code:

    <quote>
    rui@localhost:tmp$ g++ -pedantic a.c++
    main.c++:4:9: warning: ISO C++ forbids zero-size array ‘z’ [-pedantic]
    </quote>


    Rui Maciel

    --
  • Rui Maciel at Jan 9, 2013 at 12:36 pm

    On 01/09/2013 11:30 AM, chris dollin wrote:
    On 9 January 2013 11:12, Rui Maciel wrote:
    Some programming languages (C, C++, Python, etc...) are defined based on the
    "object" concept, which essentially refers to a region of memory storage.
    That's one way of looking at it. Another way is to say that
    an object is something that can respond to messages -- it
    /might/ have an associated region of storage, or it might not.
    Right. Fair enough.

    The "region of memory" is a very C[++] view.
    Risking going off on a tangent, this interpretation isn't really limited
    to C[++]. For example, Ada95 defines an object of a type as "run-time
    entity that contains (has) a value of the type", and I might be mistaken
    here (someone please correct me if I'm wrong) but it appears it also
    requires that they are created at run-time, can be initialized, and are
    associated with addressable memory.

    But this isn't really important, or relevant, for this discussion.
    What's important is to get a better understanding of how Go works.

    Yet, Go supports zero-size variables[1],
    Regions can be empty ...
    But doesn't a memory address implies access to a unit of information?
    After all, between address (X) and (X+1), n bits can be addressed.

    and in the language's specs the
    word "object" only appears in a reference to "higher-dimensional
    objects"[2].

    Considering this, does Go have objects?
    Suppose I said "yes". What would the consequences be?

    Suppose I said "no". What would the consequences be?
    Both have the same consequence: a better understanding of the language,
    provided that the answer is correct, of course.

    So, does anyone know which one is it?


    Rui Maciel

    --
  • Chris dollin at Jan 9, 2013 at 1:09 pm

    On 9 January 2013 12:30, Rui Maciel wrote:

    But doesn't a memory address implies access to a unit
    of information?
    The address is insufficient. You also need to know how big
    the thing "at" that address is. The same address might be
    referring to a byte or an int or a struct-with-loadsa-fields.
    (Or, on some earlier machines, just a couple of bits ...)
    After all, between address (X) and (X+1), n bits can be
    addressed.
    For some value of n ... yes, but the question is, how many
    bits are you asking for?
    and in the language's specs the
    word "object" only appears in a reference to "higher-dimensional
    objects"[2].

    Considering this, does Go have objects?
    Suppose I said "yes". What would the consequences be?

    Suppose I said "no". What would the consequences be?
    Both have the same consequence: a better understanding of the language,
    provided that the answer is correct, of course.

    So, does anyone know which one is it?
    The answer depends on which definition of "object" you
    want to adopt. Go doesn't provide one, so you (or whoever
    is asking the question) must do so.

    I think an appropriate response -- it might not be an answer --
    to the question "does Go have objects?" is "why are you asking?".
    Usually the question isn't about Go but about how to relate
    Go to some other language the asker is familiar with, and that
    question, being more specific, can have a more specific answer.

    I like the answer "no" because it doesn't mislead people into
    expecting some specific behaviour-like-some-other-language,
    and there also, I think, likely to then ask "but how do you do X
    then?" at which point there's something specific to discuss,
    see above.

    Chris

    --
    Chris "allusive" Dollin

    --
  • Rui Maciel at Jan 9, 2013 at 8:49 pm

    On 01/09/2013 01:08 PM, chris dollin wrote:
    On 9 January 2013 12:30, Rui Maciel wrote:

    But doesn't a memory address implies access to a unit
    of information?
    The address is insufficient. You also need to know how big
    the thing "at" that address is. The same address might be
    referring to a byte or an int or a struct-with-loadsa-fields.
    (Or, on some earlier machines, just a couple of bits ...)
    After all, between address (X) and (X+1), n bits can be
    addressed.
    For some value of n ... yes, but the question is, how many
    bits are you asking for?
    That's true, and no one is disputing that. My point was that there is a
    minimum amount of memory which is referenced through an address alone,
    even when a length isn't specified.

    So, does anyone know which one is it?
    The answer depends on which definition of "object" you
    want to adopt. Go doesn't provide one, so you (or whoever
    is asking the question) must do so.

    I think an appropriate response -- it might not be an answer --
    to the question "does Go have objects?" is "why are you asking?".
    Usually the question isn't about Go but about how to relate
    Go to some other language the asker is familiar with, and that
    question, being more specific, can have a more specific answer.
    That's precisely why I started this thread.

    I like the answer "no" because it doesn't mislead people into
    expecting some specific behaviour-like-some-other-language,
    and there also, I think, likely to then ask "but how do you do X
    then?" at which point there's something specific to discuss,
    see above.
    That sounds reasonable. Go's support for zero-size variables pretty
    much excludes any definition of object which is based on some memory
    being used to store some data. Yet, if some other definition of object
    was (or, better yet, is) adopted for Go then the answer might be a "yes,
    but..." followed by a series of caveats.

    Either way, it would be nice to know what these caveats are, to better
    conceptualize what really happens when some magic Go statement is
    executed.


    Rui Maciel

    --
  • Aram Hăvărneanu at Jan 9, 2013 at 8:54 pm

    Go's support for zero-size variables pretty much
    excludes any definition of object which is based on some memory being used
    to store some data.
    It must also exclude C++ then, as shown in my previous post in this thread.

    --
    Aram Hăvărneanu

    --
  • Rui Maciel at Jan 10, 2013 at 3:29 am

    On 01/09/2013 08:54 PM, Aram Hăvărneanu wrote:
    It must also exclude C++ then, as shown in my previous post in this thread.
    Read my reply to your code. In short, you posted broken code.


    Rui Maciel

    --
  • Minux at Jan 9, 2013 at 8:59 pm

    On Thu, Jan 10, 2013 at 4:49 AM, Rui Maciel wrote:

    That sounds reasonable. Go's support for zero-size variables pretty much
    excludes any definition of object which is based on some memory being used
    to store some data. Yet, if some other definition of object was (or,
    better yet, is) adopted for Go then the answer might be a "yes, but..."
    followed by a series of caveats.
    As Go spec doesn't use object to define other things (only a single
    occurrence of the word "object"
    in the whole spec tip.golang.org/ref/spec),
    we can define object to be a Go variable. I'm sure this definition isn't
    what you'd have expected, but
    i think it's this simple.
    Either way, it would be nice to know what these caveats are, to better
    conceptualize what really happens when some magic Go statement is executed.
    If you want to know this, you'd better ask about it directly.

    --
  • Itmitica at Jan 9, 2013 at 9:01 pm
    Multiple pointers, having a common target, even though they constitute
    memory to store about themselves, they don't really store some data, since
    they point to the same base value.

    And this also doesn't constitute an exceptional paradox that needs to be
    treated with "yes, but...". The same way the Go's support for zero-size
    variables doesn't.

    --
  • Itmitica at Jan 9, 2013 at 9:14 pm
    Another question is: a generalization of the zero size variables case
    (common memory address for a common profile) can be expected within the
    language?

    --
  • Nate Finch at Jan 9, 2013 at 9:22 pm
    Here's the answer: No, Go doesn't have objects, simply because the word
    object is not defined in the Go lexicon.

    Now, is there something you'd like to accomplish with Go that you think
    you'd need something called an Object? Maybe we can help figure out how to
    do that.
    On Wednesday, January 9, 2013 3:49:45 PM UTC-5, Rui Maciel wrote:


    Either way, it would be nice to know what these caveats are, to better
    conceptualize what really happens when some magic Go statement is
    executed.


    Rui Maciel
    --
  • Nigel Tao at Jan 10, 2013 at 12:21 am

    On Thu, Jan 10, 2013 at 7:49 AM, Rui Maciel wrote:
    On 01/09/2013 01:08 PM, chris dollin wrote:
    On 9 January 2013 12:30, Rui Maciel wrote:
    After all, between address (X) and (X+1), n bits can be
    addressed.
    For some value of n ... yes, but the question is, how many
    bits are you asking for?
    That's true, and no one is disputing that. My point was that there is a
    minimum amount of memory which is referenced through an address alone, even
    when a length isn't specified.
    Perhaps a different way to look at it is that a pointer p is just a
    base. The relevant memory is the interval [p, p+s), where s is the
    size of the pointee type. For example, if p is a *[3]uint8 then the
    relevant memory is [p, p+3). The interval is what matters, but we can
    refer to that interval in Go just by its base p because the s is
    implicit in the type of the pointer.

    Note that the upper bound is exclusive. The interval [p, p+0) is a
    perfectly valid concept; it is an empty interval.

    As an analogy:
    b := make([]byte, 8)
    will allocate 8 bytes. b is represented by a pointer, length and
    capacity (http://research.swtch.com/godata). Doing
    c := b[8:]
    is valid Go, and c's pointer is b's pointer + 8, even though c's
    pointer can not be safely dereferenced. It's OK, though, because
    len(c) == 0 and cap(c) == 0, so c refers to an empty interval of
    memory.

    --
  • Bryanturley at Jan 9, 2013 at 4:32 pm

    On Wednesday, January 9, 2013 5:12:25 AM UTC-6, Rui Maciel wrote:
    Some programming languages (C, C++, Python, etc...) are defined based on
    the "object" concept, which essentially refers to a region of memory
    storage.
    C was object based? If you start from what the cpu can actually do and go
    up then object's are only an illusion.
    No matter what language you are writing in you are giving instructions to a
    cpu, might as well think like one.

    --
  • Phil Whelan at Jan 9, 2013 at 4:39 pm
    Any roadmap for when Go++ will be released? (I jest)
    On Wed, Jan 9, 2013 at 8:26 AM, bryanturley wrote:


    On Wednesday, January 9, 2013 5:12:25 AM UTC-6, Rui Maciel wrote:

    Some programming languages (C, C++, Python, etc...) are defined based on
    the "object" concept, which essentially refers to a region of memory
    storage.
    C was object based? If you start from what the cpu can actually do and go
    up then object's are only an illusion.
    No matter what language you are writing in you are giving instructions to
    a cpu, might as well think like one.

    --



    --
    Thanks,
    Phil Whelan

    CEO and Founder
    FluidFeatures.com

    Cell : +1 (778) 233-4935
    Web : http://www.fluidfeatures.com
    Twitter : http://www.twitter.com/philwhln
    LinkedIn : http://ca.linkedin.com/in/philwhln
    Blog : http://www.bigfastblog.com

    --
  • Steve wang at Jan 9, 2013 at 5:03 pm
    Go++ is meaningless becuase ++ is a statement rather than an expression.
    On Thursday, January 10, 2013 12:39:15 AM UTC+8, Phil Whelan wrote:

    Any roadmap for when Go++ will be released? (I jest)

    On Wed, Jan 9, 2013 at 8:26 AM, bryanturley <bryan...@gmail.com<javascript:>
    wrote:
    On Wednesday, January 9, 2013 5:12:25 AM UTC-6, Rui Maciel wrote:

    Some programming languages (C, C++, Python, etc...) are defined based on
    the "object" concept, which essentially refers to a region of memory
    storage.
    C was object based? If you start from what the cpu can actually do and
    go up then object's are only an illusion.
    No matter what language you are writing in you are giving instructions to
    a cpu, might as well think like one.

    --



    --
    Thanks,
    Phil Whelan

    CEO and Founder
    FluidFeatures.com

    Cell : +1 (778) 233-4935
    Web : http://www.fluidfeatures.com
    Twitter : http://www.twitter.com/philwhln
    LinkedIn : http://ca.linkedin.com/in/philwhln
    Blog : http://www.bigfastblog.com
    --
  • Guelfey at Jan 9, 2013 at 11:21 pm

    On Wednesday, January 9, 2013 5:55:23 PM UTC+1, steve wang wrote:

    Go++ is meaningless becuase ++ is a statement rather than an expression.
    [...]

    Just by the way, if you argue this way, you can also say that C++ isn't
    better than C because it is evaluated before the increment.

    --
  • Steve wang at Jan 10, 2013 at 1:15 am

    On Thursday, January 10, 2013 4:46:05 AM UTC+8, gue...@gmail.com wrote:
    On Wednesday, January 9, 2013 5:55:23 PM UTC+1, steve wang wrote:

    Go++ is meaningless becuase ++ is a statement rather than an expression.
    [...]

    Just by the way, if you argue this way, you can also say that C++ isn't
    better than C because it is evaluated before the increment.
    Actually, C++ means that you get nothing more than C.
    Just a joke.

    --
  • Rui Maciel at Jan 10, 2013 at 3:34 am

    On 01/09/2013 04:26 PM, bryanturley wrote:
    C was object based?
    Yes, according to C's definition of an object, but I suspect you
    associate objects with the object-oriented programming paradigm. They
    aren't exactly the same thing.

    Nevertheless, just for fun, here's a link to a book on object-oriented
    programming with ANSI-C. That's right, C.

    http://www.cs.rit.edu/~ats/books/ooc.pdf


    Rui Maciel

    --
  • Bryanturley at Jan 11, 2013 at 6:24 pm

    On Wednesday, January 9, 2013 9:34:13 PM UTC-6, Rui Maciel wrote:
    On 01/09/2013 04:26 PM, bryanturley wrote:
    C was object based?
    Yes, according to C's definition of an object, but I suspect you
    associate objects with the object-oriented programming paradigm. They
    aren't exactly the same thing.

    Nevertheless, just for fun, here's a link to a book on object-oriented
    programming with ANSI-C. That's right, C.
    Heh yeah I wrote a lot of code with glib/gtk in c as well as other similar
    libraries.
    I don't know any c coders that talk about native c objects though.
    They almost always mean a pointer to a struct or union.

    --
  • Itmitica at Jan 9, 2013 at 7:54 pm
    See this thread for a partial insight given by a magazine special on Go:

    https://groups.google.com/forum/#!topic/golang-nuts/2vq8LnKEJWs

    --

Related Discussions

People

Translate

site design / logo © 2021 Grokbase