Message sends and function calls--terminology 
Author Message
 Message sends and function calls--terminology


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

Mon, 15 Jun 1998 03:00:00 GMT  
 [ 1 post ] 

 Relevant Pages 

1. Message sends and function calls--terminology

2. Message sends and function calls--terminology

3. Message sends and function calls--terminology

4. Message sends and function calls--terminology

5. Message sends and function calls--terminology

6. Message sends and function calls--te

7. Replace standard MESSAGE function in C4 with own message function

8. VC++ calling fortran function and fortran function calling a c++ function

9. send mail using SMTP Send Message when mail server is unknown

10. How to find out name of calling function from called function

11. Calling functions from functions from functions ...

12. A message send logger in a runtime application...


Powered by phpBB® Forum Software