In talking with a colleague whose expertise includes heavy
experience with c-LOS (an object-oriented LISP), we discovered that
there was a signficant divergence of our understanding of the term
"message" in OOP.
To him, a "message" is a lexical notation that syntactically
distinquishes a "receiver." Method names can be overloaded.
To me and most other Smalltalk programmers, a "message" is the lexical
invocation of an abstract function such that the actual function is
determined at run time by dynamic dispatch. A method is a function
selected for execution by dynamic dispatch based on 1) a message
selector, and 2) the distinguished argument of the function which
we call the "receiver of the message".
Concrete examples:
Red Blue
Syntax Call mechanics Terminology Terminology
"print(anObject)" static dispatch function call function call
"print(anObject)" dynamic dispatch function call message send
"anObject print" dynamic dispatch message send message send
"anObject.print()" static dispatch message send (overloaded)
function call
This difference in terminology leads to serious misunderstandings.
There is no right and wrong here. But until this inconsistency in
terminology is fixed somehow, confusion and unnecessary arguments
will be common. If you think this topic is only of relevance
for c-LOS, note that the same terminology difference exists between
the Smalltalk and C++ communities (for example).
The obvious thing that can be done about this is to be aware of the
difference in terminology, and be very careful what terms you use
unless you know your audience shares your terminology. What else can
be done, I don't know.
--Alan Lovejoy
P.S. I am aware of virtual functions in C++ (for example). Whether
virtual functions are methods in "Blue Terminology" is an interesting
topic. If you want to discuss it, please start a new thread, and
remove any irrelevant newsgroups from the discussion. I'd suggest
comp.lang.c++ and comp.object as the only clearly relevant groups.
In article <··········@ixnews3.ix.netcom.com>, ········@ix.netcom.com(Alan
Lovejoy ) wrote:
>In talking with a colleague whose expertise includes heavy
>experience with c-LOS (an object-oriented LISP), we discovered that
>there was a signficant divergence of our understanding of the term
>"message" in OOP.
>
>To him, a "message" is a lexical notation that syntactically
>distinquishes a "receiver." Method names can be overloaded.
This doesn't make much sense, for the simple reason that CLOS doesn't have
"message" as a construct. CLOS has methods and generic functions: no
"sending" and no "messages". So wherever your colleague got his peculiar
notions, it wasn't from CLOS.
One of the important Lisp oop precursors to CLOS was Flavors, which in its
original incantation did have messages and explicit message sending (with
the function #'send). Here a message has essentially the same semantics as
in Smalltalk, although the syntax is different.
>To me and most other Smalltalk programmers, a "message" is the lexical
>invocation of an abstract function such that the actual function is
>determined at run time by dynamic dispatch.
Exactly what it is in Flavors. And, since CLOS doesn't have messages,
there's no conflict in either case.
>A method is a function
>selected for execution by dynamic dispatch based on 1) a message
>selector
As in Flavors and CLOS
>and 2) the distinguished argument of the function which
>we call the "receiver of the message".
As in Flavors. CLOS and other languages (eg Dylan) which support the more
general concept of multi-argument dispatch don't designate a specific
"receiver", but the principle is the same; one would say "the specialized
arguments to the generic function" rather than "the receiver of the
message"
>This difference in terminology leads to serious misunderstandings.
You're making a mountain out of the molehill of your friend's personal
misunderstand of "message".
>If you think this topic is only of relevance
>for c-LOS, note that the same terminology difference exists between
>the Smalltalk and C++ communities (for example).
C++ doesn't have messages or message-sending either.
The term "method" can only be used in C++ as a rough analog of what it
means in other languages. In other words. it's better not to use it at
all. There's a reason C++ uses "member function" and "virtual member
function" instead.
In sum, in languages where "message" and "message sending" have meaning,
those meanings are more or less identical to one another. In languages
where "method" has a meaning, those meanings are quite similar to one
another except for the distinction mentioned above (single vs multiple
dispatch). There's really no room for confusion.
--
···········@bbn.com
From: William D. Gooch
Subject: Re: Message sends and function calls--terminology
Date:
Message-ID: <goochb.186.001526D1@rwi.com>
In article <·························@esb.bbn.com> ········@bbn.com (R Shapiro) writes:
>In article <··········@ixnews3.ix.netcom.com>, ········@ix.netcom.com(Alan
>Lovejoy ) wrote:
>>In talking with a colleague whose expertise includes heavy
>>experience with c-LOS (an object-oriented LISP), we discovered that
>>there was a signficant divergence of our understanding of the term
>>"message" in OOP.
>>
>>To him, a "message" is a lexical notation that syntactically
>>distinquishes a "receiver." Method names can be overloaded.
>This doesn't make much sense, for the simple reason that CLOS doesn't have
>"message" as a construct. CLOS has methods and generic functions: no
>"sending" and no "messages". So wherever your colleague got his peculiar
>notions, it wasn't from CLOS....
Did Alan say that I thought CLOS had messages? No, he didn't.
His words above are in any case his own paraphrase of what I
said. The Reader's Digest version, if you will (sorry, Alan). I also
elaborated by email in response to his email of the above, but we
need not go into that here. As far as I'm concerned, one's exact
definition of "message" isn't as important as the knowledge that
the concept isn't unique and isn't an indispensible characteristic
of OO.
>>...This difference in terminology leads to serious misunderstandings.
>You're making a mountain out of the molehill of your friend's personal
>misunderstand of "message".
He may be making something out of something else, but you
are without any doubt making a lot of assumptions here. The
misunderstanding he refers to is not between him and me, but
it *is* rather widespread in the OO community. We got onto
this topic because of posts on another newsgroup reflecting
misconceptions which I would summarize as "messaging is
fundamentally different from function calling, and understanding
the difference is essential to proper use of language X." So far,
I have yet to see anyone *justify* such an assertion.
A related misconception sometimes expressed is that asyn-
chronous messaging, as in actor languages, is fundamentally
different.
>....
>In sum, in languages where "message" and "message sending" have meaning,
>those meanings are more or less identical to one another.
I'm not familiar with many "messaging-based" languages,
but from what I understand those meanings are not always
identical. Actor type languages and perhaps others are
different in significant (if not fundamental) ways.
>In languages
>where "method" has a meaning, those meanings are quite similar to one
>another except for the distinction mentioned above (single vs multiple
>dispatch).
Various kinds of methods (daemons, etc.) and method combination,
dynamic versus static inheritance, privacy constraints, roles, and
other factors contribute to quite a bit of variation here. Differences
may be less significant than similarities, but they are significant.
> There's really no room for confusion.
Seriously? It seems to me that when as many beginners are
entering an evolving domain as are entering OO recently,
there's always "room for confusion." This is especially true
when beliefs of a religious flavor start to creep in, which
seems to happen with annoying regularity (just to avoid any
confusion: that last isn't a message about anything so far on
this thread).
Another way to look at it is that when you stop being
confused, you stop learning.
In article <···················@rwi.com>, ······@rwi.com (William D.
Gooch) wrote:
>Another way to look at it is that when you stop being
>confused, you stop learning.
True enough, but there are so many *new* things to be confused about, I'd
just as soon leave the old, settled things alone.
I'll try to exit gracefully now from this unintended light-flame-war (I
have nothing but respect for Mr Gooch) and go back to waiting for UPS to
deliver my Dylan Technology Release...
--
···········@bbn.com
From: Ell
Subject: Re: Message sends and function calls--terminology
Date:
Message-ID: <4ao1q8$kkt@news4.digex.net>
William D. Gooch (······@rwi.com) wrote:
:...
: Another way to look at it is that when you stop being
: confused, you stop learning.
In a sense. As one learns you are less confused about some things, you
_know_ more. Yet, the new understanding most often raises other points,
which can be confusing. And then one tackles the new points, and the
cycle goes on and on. So yes, one is often constantly confused about
certain points, but the level of knowledge, and confusion generally rises
to a higher level as the cycle "spins".
Elliott
>>> On Tue, 12 Dec 1995 21:08:57, ······@rwi.com (William D. Gooch) said:
goochb> We got onto this topic because of posts on another newsgroup
goochb> reflecting misconceptions which I would summarize as "messaging
goochb> is fundamentally different from function calling, and
goochb> understanding the difference is essential to proper use of
goochb> language X." So far, I have yet to see anyone *justify* such an
goochb> assertion.
goochb> A related misconception sometimes expressed is that asyn-
goochb> chronous messaging, as in actor languages, is fundamentally
goochb> different.
For what reasons is that a misconception?
From: William D. Gooch
Subject: Re: Message sends and function calls--terminology
Date:
Message-ID: <goochb.192.0017209C@rwi.com>
In article <···············@sabi.demon.co.uk> ········@sabi.demon.co.uk (Piercarlo Grandi) writes:
>>>> On Tue, 12 Dec 1995 21:08:57, ······@rwi.com (William D. Gooch) said:
>goochb> A related misconception sometimes expressed is that asyn-
>goochb> chronous messaging, as in actor languages, is fundamentally
>goochb> different.
>For what reasons is that a misconception?
The short answer is: because synchronous messaging plus
threads is equivalent to asynchronous messaging.
From: M. Gallo
Subject: Re: Message sends and function calls--terminology
Date:
Message-ID: <4amb6o$61v@clue.callamer.com>
In article <··········@ixnews3.ix.netcom.com>,
Alan Lovejoy <········@ix.netcom.com> wrote:
>
>In talking with a colleague whose expertise includes heavy
>experience with c-LOS (an object-oriented LISP), we discovered that
>there was a signficant divergence of our understanding of the term
>"message" in OOP.
>
>To him, a "message" is a lexical notation that syntactically
>distinquishes a "receiver." Method names can be overloaded.
>
>To me and most other Smalltalk programmers, a "message" is the lexical
>invocation of an abstract function such that the actual function is
>determined at run time by dynamic dispatch. A method is a function
>selected for execution by dynamic dispatch based on 1) a message
>selector, and 2) the distinguished argument of the function which
>we call the "receiver of the message".
In the Oberon System, a message is still different.
It's taken rather literally and is a data record passed to an
object's message handler. "Method" often refers to the
procedures used to implement a handler.
>The obvious thing that can be done about this is to be aware of the
>difference in terminology, and be very careful what terms you use
>unless you know your audience shares your terminology. What else can
>be done, I don't know.
Personally, I'm not positive that something else needs
to be done. I'm comfortable with leaving the ideas of
objects, messages, etc. to OO *design* and letting the
implementation details of OO *programming* vary between
languages and applications. The important thing would be to
remember that there is a distinction between messaging and the
way you do messaging, for example.
--
Twenty dollars can buy many peanuts! -- Homer Simpson
>>> On Fri, 15 Dec 1995 23:07:29, ······@rwi.com (William D. Gooch) said:
goochb> In article <···············@sabi.demon.co.uk>
goochb> ········@sabi.demon.co.uk (Piercarlo Grandi) writes:
>>>>>> On Tue, 12 Dec 1995 21:08:57, ······@rwi.com (William D. Gooch) said:
goochb> A related misconception sometimes expressed is that asyn-
goochb> chronous messaging, as in actor languages, is fundamentally
goochb> different.
piercarl> For what reasons is that a misconception?
goochb> The short answer is: because synchronous messaging plus
goochb> threads is equivalent to asynchronous messaging.
That's an answer to a different question, one concerning the difference
between asynchronous and synchronous messaging (plus threads), but if I
remember well the context seemed to be about differences between actor
messaging and ``messaging''/function calls. Let's check...
Yeah, looking back at the other paragraph to which I was referring to as
the context of my question:
goochb> We got onto this topic because of posts on another newsgroup
goochb> reflecting misconceptions which I would summarize as
^^^^^^^^^^^^^^
goochb> "messaging is fundamentally different from function calling,
^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
That this is a misconception is agreed, BTW.
goochb> and understanding the difference is essential to proper use of
goochb> language X."
goochb> A related misconception sometimes expressed is that asyn-
^^^^^^^^^^^^^^^^^^^^^^^
goochb> chronous messaging, as in actor languages, is fundamentally
goochb> different.
For what reasons is that a misconception?
it seemed to me that you were criticizing as a misconception the
difference between messaging/calling (as described in the first
paragraph) and actor messaging, not with synchronous messaging (plus
threads), that was not explicitly mentioned.
As to the difference I (erroneously?) thought you were addressing
(``messaging''/calling vs. actor messaging), there are very solid
reasons for which one can argue that actor messaging is fundamentally
different from ``messaging''/procedure calling, whether synchronous or
asynchronous, local or remote (indeed actor computing is often claimed
to involve a different computation model from conventional languages),
like that it involves transfer of data but not transfer of control, and
that the exchange patterns of those data do not need to be nested,
instead of being nested like control transfers in procedure calling
(``messaging'' to some).
From: William D. Gooch
Subject: Re: Message sends and function calls--terminology
Date:
Message-ID: <goochb.201.00126B0A@rwi.com>
In article <···············@sabi.demon.co.uk> ········@sabi.demon.co.uk (Piercarlo Grandi) writes:
>.... one can argue that actor messaging is fundamentally
>different from ``messaging''/procedure calling, whether synchronous or
>asynchronous, local or remote (indeed actor computing is often claimed
>to involve a different computation model from conventional languages),
In the abstract, I suppose it could be viewed as "fundamentally
different," and even "to involve a different computation model."
But in a practical sense, is there anything fundamentally different
about simulating actor behavior on sequential hardware, versus
the sort of language that it might be simulated in? Unless we are
really talking about some non-conventional hardware, in which
case the difference may be something fundamental. If not, is there
something you can point to that one can do in an actor language
that can't be done in a C, C++, Smalltalk or CLOS with threads?
>like that it involves transfer of data but not transfer of control, and
>that the exchange patterns of those data do not need to be nested,
>instead of being nested like control transfers in procedure calling
>(``messaging'' to some).
Asynchronous messaging via conventional messaging with threads
does not involve transfer of control.
Alan Lovejoy (········@ix.netcom.com) wrote:
> In talking with a colleague whose expertise includes heavy
> experience with c-LOS (an object-oriented LISP), we discovered that
> there was a signficant divergence of our understanding of the term
> "message" in OOP.
I have never liked the use of the word "message" to characterise OOP,
partly because it tends to imply OOP is inherently inefficient because of
communication overheads, but also because it does not convey an accurate
impression of the fundamental concepts of OO.
Basically, an object is characterised by a set of externally visible
attributes ("attributes" used in a wider sense than in Eiffel) which can
be accessed/invoked from the environment in which the object exists. In
abstract terms, access/invocation has no messaging connotations but the
effects can (sometimes) be described easily using messaging as an analogy.
In reality, in some systems but by no means all, implementation of
attribute access/invocation may be accomplished by the use of messaging
and indeed, in certain types of system, e.g. distributed systems,
messaging may be necessary. The point I am trying to make is that
messaging is not part of the OO paradigm but in certain situations it may
be a desirable or even essential implementation technique.
> The obvious thing that can be done about this is to be aware of the
> difference in terminology, and be very careful what terms you use
> unless you know your audience shares your terminology. What else can
> be done, I don't know.
It has long been my experience that the lack of a rigorous terminology for
OOP is a great impediment to conducting discussions in depth about various
important aspects.
Cheers....Ron
------------------------------------------------------------------------
Ron Kerr, Computing Service, Newcastle University, NE1 7RU, England.
Tel. +44 191 222 8187 Fax. +44 191 222 8765 (NOTE new area code)
------------------------------------------------------------------------
R. Kerr <······@ncl.ac.uk> writes:
"Basically, an object is characterised by a set of externally visible
attributes... which can be accessed/invoked from the environment in which
the object exists."
I think I disagree. If you ask (in Smalltalk) "Random new next" to obtain
a random integer, are you accessing (or even invoking) an attribute?
I think of "attribute" as "state," and if anything, an object should
protect its state, NOT make it "externally visible." Perhaps we aren't
using the same definition of "attribute?"
Jan
Jan Steinman <··············@acm.org>
Barbara Yates <··················@acm.org>
2002 Parkside Ct., West Linn, OR 97068, USA +1 503 657 7703
In article <··········@newsbf02.news.aol.com>, ··········@aol.com
(Bytesmiths) wrote:
> I think of "attribute" as "state," and if anything, an object should
> protect its state, NOT make it "externally visible." Perhaps we aren't
> using the same definition of "attribute?"
I think that's the key point to this thread: different people use
different terminology and it makes it difficult to talk about OOP concepts
in general. I interpreted the previous use of "attribute" to mean state
and/or "procedures", "functions", "methods", "function members" or any
other executable "attribute" of an object, not just "data".
For example: In the case of some languages, such as Dylan, all the
"slots", or "state" as you put it, are accessed via functions. In fact, in
Dylan slots can be declared "virtual", in which case there is no storage
allocated for them at all and they effectively exist only because there
are functions to access them*.
Therefore, I don't see much difference between protected, internal state
"data" and externally visible ones when the visible "attributes" may be
functions and the internal representation of the state externally
presented by those functions is hidden. (Unfortunately, some languages,
such as C++, require you to distinguish between "data members" and
"function members".)
*If this sounds confusing, imagine an object that represents a rectangle
whose internal representation is a pair of top/left & bottom/right
coordinates. You may wish to present "attributes" of the rectangle such as
top/left & width/height, four corner coordinates, center position & size,
or any other derivative you can imagine. In Dylan, you just allocate
"real" slots for your "real" internal representation and declare "virtual"
slots for the other external representations. You can then feel free to
change the internal representation, while still allowing any of the
several convenient external representations who may or may not be "real"
slots.
--
Chris Page | Internet chain letters, advertisements and SPAMs suck...
Don't Panic! |
····@best.com | Cut it out! :-P
From: Eric W. Nikitin
Subject: Re: Message sends and function calls--terminology
Date:
Message-ID: <4beuvt$fm7@wariat.wariat.org>
Bytesmiths (··········@aol.com) wrote:
: R. Kerr <······@ncl.ac.uk> writes:
: "Basically, an object is characterised by a set of externally visible
: attributes... which can be accessed/invoked from the environment in which
: the object exists."
: I think I disagree. If you ask (in Smalltalk) "Random new next" to obtain
: a random integer, are you accessing (or even invoking) an attribute?
: I think of "attribute" as "state," and if anything, an object should
: protect its state, NOT make it "externally visible." Perhaps we aren't
: using the same definition of "attribute?"
: Jan
I don't think you are using the same definition of attribute. All
instances with the same dynamic type have the same attributes. That
is, a class defines a set of attributes which are common to all
instances of that class. Each instance then has its own state -
i.e. attributes are assigned different values.
In Smalltalk, all data is private and all methods are public (I can't
say I'm an expert in Smalltalk jargon... but I think I'm pretty close :)
This is not how encapsulation is handled in all OO languages. But most,
if not all, agree there should be a public interface and a private
implementation. That is how an object protects its state... by only
permitting access through its interface. Again, it is dependant on the
language as to how this is accomplished.
Eric
From: ········@apci.net
Subject: Re: Message sends and function calls--terminology
Date:
Message-ID: <4behdc$p2h@queeg.apci.net>
In <··········@newsbf02.news.aol.com>, ··········@aol.com (Bytesmiths) writes:
>R. Kerr <······@ncl.ac.uk> writes:
> "Basically, an object is characterised by a set of externally visible
>attributes... which can be accessed/invoked from the environment in which
>the object exists."
>
>I think I disagree. If you ask (in Smalltalk) "Random new next" to obtain
>a random integer, are you accessing (or even invoking) an attribute?
>
>I think of "attribute" as "state," and if anything, an object should
>protect its state, NOT make it "externally visible." Perhaps we aren't
>using the same definition of "attribute?"
>
>Jan
>
>Jan Steinman <··············@acm.org>
>Barbara Yates <··················@acm.org>
>2002 Parkside Ct., West Linn, OR 97068, USA +1 503 657 7703
Not having read the original post....
I don't think Kerr means 'attribute' and 'instance variable' as synomymous. I believe
the poster means as 'something that can be used to characterize or describe
the object' Or 'soemthing which is attributable to the object'. For example,
in an Invoice object, you could consider totalCost to be an 'attribute',
although it is probably not an instance variable. totalCost is probably a method
that iterates over linetems and answers the total cost of all lineItems plus a
certain tax rate. (In Smalltalk lingo...)
totalCost
| total |
total := 0.
self lineItems do: [: item |
total := total + item itemCost
].
^total + TaxPolicy taxForAmount: total
totalCost is a method that performs a calculation, not an instance variable, but
from a client's (any user of Invoice) perspective, it could be considered an
'Attribute' of Invoice objects in that it characterizes or describes them or their
current state.
With such a mentality, I believe, in Random new next, next could be considered
an Attribute of instances of Random, even though it is a method, not an
instance variable.
I suppose this distinction would only apply to methods that treated the receiver
as a subject of the verb rather than the object of the verb. In my mentality,
their are two kinds of methods. Those where the receiver of the message
is the target of the method, and those where the receiver is the performer of the
method....Hmmm that may not sound right. How 'bout
object goDoSomething.
or object tellMeSomething.
window open.
or window width.
I think Kerr meant by Attribute something akin to Responsibilities
(in CRC) regardless of how that respnsibility is implemented (by instance variable
or method). I hope this helps.
James O'Connor
Framework Technolgoies
·······@apci.net
From: Ell
Subject: Re: Message sends and function calls--terminology
Date:
Message-ID: <4bk1gd$13t@news4.digex.net>
········@apci.net wrote:
:...
: I suppose this distinction would only apply to methods that treated the
: receiver as a subject of the verb rather than the object of the verb. In
: my mentality, their are two kinds of methods. Those where the receiver of
: the message is the target of the method, and those where the receiver is
: the performer of the method....Hmmm that may not sound right. How 'bout
:
: object goDoSomething.
: or object tellMeSomething.
:
: window open.
: or window width.
Is this similar to the difference between:
anObject.print
or print(anObject)
Elliott
From: Piercarlo Grandi
Subject: Re: Message sends and function calls--terminology
Date:
Message-ID: <vwjg2ec28h5.fsf@osfb.aber.ac.uk>
>>> On Fri, 22 Dec 1995 03:06:33 -0800, ····@best.com (Chris Page) said:
Chris> In article <··········@newsbf02.news.aol.com>, ··········@aol.com
Chris> (Bytesmiths) wrote:
R.Kerr> Basically, an object is characterised by a set of externally
R.Kerr> visible attributes ("attributes" used in a wider sense than in
R.Kerr> Eiffel) which can be accessed/invoked from the environment in
R.Kerr> which the object exists. In abstract terms, access/invocation
R.Kerr> has no messaging connotations
bytesmiths> I think of "attribute" as "state," and if anything, an
bytesmiths> object should protect its state, NOT make it "externally
bytesmiths> visible." Perhaps we aren't using the same definition of
bytesmiths> "attribute?"
Chris> I think that's the key point to this thread: different people use
Chris> different terminology and it makes it difficult to talk about OOP
Chris> concepts in general.
Indeed, and one should try to get thru the veil of terminology to get at
the underlying concepts, but many people find it difficult, thus
confusions. Also not all terminologies are equal in usefulness...
Chris> I interpreted the previous use of "attribute" to mean state
Chris> and/or "procedures", "functions", "methods", "function members"
Chris> or any other executable "attribute" of an object, not just
Chris> "data".
Yes, but in this case the confusion in terminology (different referents
for "attribute") also implies a difference in concepts. I seem to
understand that according to Jan those "attributes" of an object (class)
that define the state of its instances should not be visible outside it.
Now in some languages like Smalltalk-80 one simply cannot them visible,
in some like C++ one can _optionally_ make them visible, and in some
like Simula 67 (the original version) one could not make them invisible.
By the use of a certain notion of 'attribute' Jan is implying that
encapsulation requires protection of the state "attributes", while Kerr
is just saying that there are attributes that are visible and those that
are not, without constraining protection to be the same as
encapsulation, either way.
In Smalltalk-80 for example all and only the state attributes are
protected, thus encapsulation and protection coincide exactly. In
other languages like C++ encapsulation and protection are not related
in any necessary way, and in others (like some Smalltalk-80 variants,
if I remember well) protection is constrained to be a stricter notion
than encapsulation of state (all state is implicitly protected, and
additionally some other attributes can be protected too explicitly).
Indeed there can be a lot of debate as to whether encapsulation and
protection should coincide. or even whether protection is necessary at
all and as to what forms it should take.
Chris> For example: In the case of some languages, such as Dylan, all
Chris> the "slots", or "state" as you put it, are accessed via
Chris> functions.
This is one way to make sure that protection and encapsulation coincide,
because the encapsulated state is protected by being made visible only
to (and/or thru) functions defined in the same class.
Chris> In fact, in Dylan slots can be declared "virtual", in which case
Chris> there is no storage allocated for them at all and they
Chris> effectively exist only because there are functions to access
Chris> them*.
This is just quibbling with terminology :-).
Chris> Therefore, I don't see much difference between protected,
Chris> internal state "data" and externally visible ones when the
Chris> visible "attributes" may be functions and the internal
Chris> representation of the state externally presented by those
Chris> functions is hidden. (Unfortunately, some languages, such as C++,
Chris> require you to distinguish between "data members" and "function
Chris> members".)
Well, this is not unfortunate, at least not in C++. For two reasons:
1) in C++ access to data members is syntactically different from
access to function members.
2) this distinction is justified by the fact that accessor functions
generated by the compiler for data members have _very_ different
performance properties from those defined by the user, even if the
user may define inlines.
Compare:
class complex
{
private: float _re, _im;
public:
inline float &re() { return &_re; }
inline float &im() { return &_im; }
...
}
which is Smalltalk/Dylan like with
class complex
{
public:
float re,im;
...
}
In C++ compiling the latter is rather different from the former, in that
the compiler has an easier job when it sees 'x.re = 3;' than when it
sees 'x.re() = 3;', because the 're' accessor function has much less
general properties when it is compiler generated than when it is
used defined.
I hope that everybody realizes that 'x._re' is really a shorthand
for '_re(x)'.
It is much harder to compile efficiently accessor functions when they
look like or are really the same as user defined functions. One needs
clever implementation technology; at one extreme BLISS, at the other
Self, have both required fairly sophisticated compiler tricks.
Chris> *If this sounds confusing, imagine an object that represents a
Chris> rectangle whose internal representation is a pair of top/left &
Chris> bottom/right coordinates. You may wish to present "attributes" of
Chris> the rectangle such as top/left & width/height, four corner
Chris> coordinates, center position & size, or any other derivative you
Chris> can imagine. In Dylan, you just allocate "real" slots for your
Chris> "real" internal representation and declare "virtual" slots for
Chris> the other external representations. You can then feel free to
Chris> change the internal representation, while still allowing any of
Chris> the several convenient external representations who may or may
Chris> not be "real" slots.
This is also possible in all those languages (not many) in which
compiler synthetized destructors/accessors can be invoked with the same
syntax as user defined functions, or viceversa (the latter is possible,
in a somewhat limited way, in Eiffel, in which parameterless functions
can be invoked with the same syntax as destructors/accessors).
The ability to have syntactic equivalence in the invocation of various
types of functions is also note necessarily related to the issue as to
whether encapsulation and protection should be twinned, in case anybody
wondered.
From: Piercarlo Grandi
Subject: Re: Message sends and function calls--terminology
Date:
Message-ID: <vwjag4k218h.fsf@osfb.aber.ac.uk>
>>> On 22 Dec 1995 18:55:57 GMT, ········@junior.wariat.org (Eric
>>> W. Nikitin) said:
enikitin> [ ... ] That is, a class defines a set of attributes which are
enikitin> common to all instances of that class. Each instance then has
enikitin> its own state - i.e. attributes are assigned different values.
enikitin> In Smalltalk, all data is private and all methods are public
enikitin> (I can't say I'm an expert in Smalltalk jargon... but I think
enikitin> I'm pretty close :) This is not how encapsulation is handled
enikitin> in all OO languages. But most, if not all, agree there should
enikitin> be a public interface and a private implementation. That is
enikitin> how an object protects its state... by only permitting access
enikitin> through its interface.
I agree with the substance of what you say, but your use of "an object
protects its state" really grates: it really grates. For in most OO
languages, and in particular in Smalltalk-80, it is _classes_ that offer
the ability to protect their _invariants_ via visibility rules, not
_objects_ that protect their _state_ (protecting the state of an object
is not necessarily the same thing as protecting the class invariant).
The two crucial points are: classes and class invariants. Thus things
like design by contract and assertions, as in Eiffel and other
languages.
enikitin> Again, it is dependant on the language as to how this is
enikitin> accomplished.
Yes, but please don't use expressions like "an object protects its
state" that, while being popular, give a very misleading expression as
to what the issues are in almost all of the OO languages around.
News is an informal forum, and the published literature contains similar
phrases, but we could make a start towards more appropriate descriptions
here (let me daydream).
In Article<···············@osfb.aber.ac.uk>, <···@aber.ac.uk> writes:
>
>
> >>> On 22 Dec 1995 18:55:57 GMT, ········@junior.wariat.org (Eric
> >>> W. Nikitin) said:
>
> enikitin> [ ... ] That is, a class defines a set of attributes which are
> enikitin> common to all instances of that class. Each instance then has
> enikitin> its own state - i.e. attributes are assigned different values.
>
> enikitin> In Smalltalk, all data is private and all methods are public
> enikitin> (I can't say I'm an expert in Smalltalk jargon... but I think
> enikitin> I'm pretty close :) This is not how encapsulation is handled
> enikitin> in all OO languages. But most, if not all, agree there should
> enikitin> be a public interface and a private implementation. That is
> enikitin> how an object protects its state... by only permitting access
> enikitin> through its interface.
>
> I agree with the substance of what you say, but your use of "an object
> protects its state" really grates: it really grates. For in most OO
> languages, and in particular in Smalltalk-80, it is _classes_ that offer
> the ability to protect their _invariants_ via visibility rules, not
> _objects_ that protect their _state_ (protecting the state of an object
> is not necessarily the same thing as protecting the class invariant).
>
> The two crucial points are: classes and class invariants. Thus things
> like design by contract and assertions, as in Eiffel and other
> languages.
>
> enikitin> Again, it is dependant on the language as to how this is
> enikitin> accomplished.
>
> Yes, but please don't use expressions like "an object protects its
> state" that, while being popular, give a very misleading expression as
> to what the issues are in almost all of the OO languages around.
>
Two independent issues I would like you to address:
What do you mean by "class invariants"?
What is your objection to "an Object protects its state" and why do you see
it as very misleading?
From: Piercarlo Grandi
Subject: Re: Message sends and function calls--terminology
Date:
Message-ID: <vwjzqccg99b.fsf@osfb.aber.ac.uk>
>>> On Wed, 27 Dec 95 10:31:58 PDT, John Sellers <·······@sellers.com> said:
>>> On 22 Dec 1995 18:55:57 GMT, ········@junior.wariat.org (Eric
>>> W. Nikitin) said:
enikitin> [ ... ] That is, a class defines a set of attributes which are
enikitin> common to all instances of that class. Each instance then has
enikitin> its own state - i.e. attributes are assigned different values.
enikitin> In Smalltalk, all data is private and all methods are public
enikitin> (I can't say I'm an expert in Smalltalk jargon... but I think
enikitin> I'm pretty close :) This is not how encapsulation is handled
enikitin> in all OO languages. But most, if not all, agree there should
enikitin> be a public interface and a private implementation. That is
enikitin> how an object protects its state... by only permitting access
enikitin> through its interface.
piercarl> [ ... ] For in most OO languages, and in particular in
piercarl> Smalltalk-80, it is _classes_ that offer the ability to
piercarl> protect their _invariants_ via visibility rules, not _objects_
piercarl> that protect their _state_ (protecting the state of an object
piercarl> is not necessarily the same thing as protecting the class
piercarl> invariant).
piercarl> The two crucial points are: classes and class invariants. Thus
piercarl> things like design by contract and assertions, as in Eiffel
piercarl> and other languages.
sellers> Two independent issues I would like you to address:
sellers> What do you mean by "class invariants"?
An ancient and admittedly somewhat obscure concept. A nice treatment,
both as to the concept itself, and as to its expression in a particular
language, is given by Meyer in "Object Oriented Software Construction",
pages 123-132 etc. The concept is very similar to that of monitor
invariant by Hoare & C.
Summarizing very brutally, it is a a predicate the expresses some aspects
of the fundamental properties of the type encapsulated in a class. As a
rule such invariant characterizes what are the valid states of the
instances of a class, but not just/only/necessarily.
For example: it is pointless to "protect" those parts of the state
that are not constrained in the class invariant; conversely, those
convenience/internal methods that temporarily violate the class
invariant ought to be "protected". In other words, granting to clients
of a class access to the state does not necessarily result in
violations of the class invariant, and viceversa allowing clients to
access all methods might well result in such violations, unless one
resorts to unnatural code duplication.
Such an invariant exists for all classes, whether or not a particular
language allows one to express it at the linguistic level. Some do
(Eiffel as mentioned has some support for doing so), and I think it is a
good idea, both because of its documentation and checking value, as at
the language level an invariant is expressed a boolean expression that
states a constraint on the class.
enikitin> Again, it is dependant on the language as to how this is
enikitin> accomplished.
piercarl> Yes, but please don't use expressions like "an object protects
piercarl> its state" that, while being popular, give a very misleading
piercarl> expression as to what the issues are in almost all of the OO
piercarl> languages around.
sellers> What is your objection to "an Object protects its state" and
sellers> why do you see it as very misleading?
The main objection is the one already mentioned: that what really
matters is not "protecting" the _object_'s _state_, but the _invariant_
of its _class_ (and I hope the details I have added as to what a class
invariant is, as per your request, illustrate why).
Then that such a phrase expresses somehow the ideas that the object is
active and a subject in the computation. Somebody may well take such
expressions literally. Given that this risk can be avoided by using less
risky phrasing...
Bytesmiths (··········@aol.com) wrote:
> R. Kerr <······@ncl.ac.uk> writes:
> "Basically, an object is characterised by a set of externally visible
> attributes... which can be accessed/invoked from the environment in which
> the object exists."
> I think I disagree. If you ask (in Smalltalk) "Random new next" to obtain
> a random integer, are you accessing (or even invoking) an attribute?
> I think of "attribute" as "state," and if anything, an object should
> protect its state, NOT make it "externally visible." Perhaps we aren't
> using the same definition of "attribute?"
I use the word "attribute" approximately in the sense "an inherent or
characteristic quality" (S.O.E.D) (- and "quality" in the sense "capacity,
ability or skill"). I do not use "attribute" with the connotation of any
specific programming language.
Your comment reinforces the ones already made in the earlier postings:
> The obvious thing that can be done about this is to be aware of the
> difference in terminology, and be very careful what terms you use
> unless you know your audience shares your terminology. What else can
> be done, I don't know.
and
> It has long been my experience that the lack of a rigorous terminology for
> OOP is a great impediment to conducting discussions in depth about various
> important aspects.
Cheers....Ron