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
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
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
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.