From: Nilone on
On Mar 9, 5:21 pm, "Daniel T." <danie...(a)earthlink.net> wrote:
> Nilone <rea...(a)gmail.com> wrote:
> > On Mar 9, 3:21 am, "Daniel T." <danie...(a)earthlink.net> wrote:
>
> > > One program is written in an OO style, while another
> > > program (written in the same language and performing the same job,) is
> > > not. (This kind of of stuff is talked about all the time using Java as
> > > an example.) What is the difference between the two programs?
>
> > > It's not an easy question to answer...
>
> > This description is much too vague to comment on.  If you give
> > examples or references, I'll comment on them.
>
> You know what it is when you see it, but you can't tell me what you are
> looking for?

You imagine programs and ill-defined classifications such as a
distinct OO style, and expect me to explain them?

>
> Robert Martin once said that OO means using of jump tables. Do you
> agree, or at least think he was close?

Certainly, jump tables is an important concept and technique in
implementating OO systems.

>
> > Event-driven programming is a well-known architecture with features
> > such as inversion of control (e.g. "In OO you don't tell the object
> > "we are in the state where you will do X," you tell the object "we are
> > in this state"; what the object does with that information is its
> > business.") and unbounded nondeterminism (e.g. "An OO function's only
> > postcondition guarantee is that it will return in a finite amount of
> > time.").
>
> > Object-oriented modeling is a separate concept.
>
> Separate how?

http://www.c2.com/cgi/wiki?DefinitionsForOo

Try the various pages linked from there as well.
From: S Perryman on
johnzabroski(a)gmail.com wrote:

> On Mar 9, 11:56 am, S Perryman <a...(a)a.net> wrote:

SP>Apart from something like meta-typing manipulation, there is no concept
SP>of "DoesNotUnderstand message" in strongly-typed prog langs.

DK>Or to put it slightly different, there is no type errors in strongly typed
DK>languages. So even if DoesNotUnderstand is present, then it does not
DK>indicate a type error. The type is OK, it does have the method Foo. It is
DK>just so that Foo is contracted to propagate DoesNotUnderstand.

>>Exactly.

>>The concept of not understanding what to do when invoked, is completely
>>different to not providing something to invoke in the first place.

>>Nothing more to really say on the topic is there.

> DoesNotUnderstand in Smalltalk does not actually mean "not
> understanding what to do when invoked".

Weakly-typed prog langs use their *runtime dispatch* mechanism as the
means of detecting what in a strongly-typed prog lang is a *type error* .

Smalltalk is a weakly-typed prog lang.


[ snipped the rest as it appears to have no meaning/bearing on strong/
weak typing, or static/dynamic type checking ]


Regards,
Steven Perryman
From: S Perryman on
johnzabroski(a)gmail.com wrote:

> On Mar 8, 5:04 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
> wrote:

SP>Apart from something like meta-typing manipulation, there is no concept
SP>of "DoesNotUnderstand message" in strongly-typed prog langs.

>>Or to put it slightly different, there is no type errors in strongly typed
>>languages. So even if DoesNotUnderstand is present, then it does not
>>indicate a type error. The type is OK, it does have the method Foo. It is
>>just so that Foo is contracted to propagate DoesNotUnderstand.

> Exactly.

> Things considered to be type errors (reduction to the "wrong" type)
> are really just the compiler saying the program shouldn't be compiled,
> because its behavior is undefined at least insofar as the compiler cares.

Wrong.

Type errors merely state that according to the rules of the type system,
a program is valid, or not. If not, the compiler is instructed not to
generate an executable form of the program.

The compiler has *no idea whatsoever* of the *behaviour* of a program,
irrespective of whether the program has type errors or not.

That is the remit of *behavioural logic checking* systems.
Which compilers (in general) are not.

That is why you get defective programs at runtime, even though there
are no type errors in the program.


[ stuff snipped, because it appears to have no bearing / meaning on
type checking of programs ]


Regards,
Steven Perryman
From: Nick Keighley on
On 5 Mar, 19:19, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
wrote:
> On Fri, 05 Mar 2010 18:13:44 +0000, S Perryman wrote:
> > Dmitry A. Kazakov wrote:
>
> >> On Fri, 05 Mar 2010 09:46:25 -0500, Daniel T. wrote:
>
> >>>If you want to visualize how objects in a good OO program work, study
> >>>how ants in a colony work together to get things done. Contrary to
> >>>popular opinion, the Queen does not tell each ant what it should do...
>
> >> It would be a very bad idea to design a program as an ant colony:
>
> >> 1. Ants designed same (worker, fighter, queen), objects are not
> >> 2. They act stochastically, programs are desired to be predictable
> >> 3. They are wasting a huge amount of resources (computational and time)
> >> 4. They communicate in an extremely inefficient, slow and unreliable way
> >> 5. They lack memory and any ability to learn
>
> > Social insect colonies are event-driven.
>
> > There are "broadcast" event channels communicated via pheromones.
> > For example :
>
> > - the signal that a queen exists
> > - the signal that the colony is being attacked
>
> > Social insect colonies are also procedural.
> > Maintenance of the colony structure, tending to the queen etc.
>
> > Both aspects are exhibited in good OO programs.
>
> Broadcasting is asynchronous 1-n messaging. OOPL rather deploy peer-to-peer
> synchronous messaging. The vital advantage of 1-1 synchronous messages
> (calls) are:
>
> 1. you can pass individual parameters. (Ant messages lack parameters
> altogether);
>
> 2. you can have results, this is a key feature that enables programming
> free of side effects;

since objects have state that can be modified doesn't this, by
definition, involve side effects?


> 3. you don't have to worry about race conditions;
>
> 4. objects can be passive, so you can have small things objects, like
> numeric ones, which otherwise could not be objects. (there would be too
> many of them);
>
> 5. you have a uniform structure, where there is no dedicated
> parameter/result, like message receiver, but all parameters and results can
> be considered objects and treated equally;
>
> 6. you can do static analysis and other nice things much easier.

really?


--
Nick Keighley


From: Nick Keighley on
On 7 Mar, 17:15, "Daniel T." <danie...(a)earthlink.net> wrote:
> "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote:
> > On Sun, 07 Mar 2010 10:15:40 -0500, Daniel T. wrote:
> > > "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote:
> > > > On Fri, 05 Mar 2010 09:46:25 -0500, Daniel T. wrote:

> > > > > Here is a simple quote that might help. "In OO programs, objects
> > > > > tend to tell other objects what happened, instead of telling
> > > > > them what to do."
>
> > > > Well, I see no difference if action is a simple function of state.
> > > > To tell the object "do X" is same as to tell it "we are in the
> > > > state, where you will do X."
>
> > > The above misses the point. In OO you don't tell the object "we are
> > > in the state where you will do X," you tell the object "we are in
> > > this state"; what the object does with that information is its
> > > business.
>
> > The point is that if the behavior is a simple function of state, then
> > both views are equivalent. In a well-designed program it is so.
>
> > Moreover, I claim that the programs where there is a substantial
> > difference between them are poorly designed.
>
> > It is no matter if you tell the car to accelerate by pushing the gas
> > pedal, or else it accelerates by itself because the pedal is on the
> > car's floor. You can view it either way. The problem is when you are
> > in a Toyota car, which interprets the pedal position in an unexpected
> > (complex) way. Such cars are called back.
>
> Your still thinking procedurally, not in an OO fashion. Let me go a
> little more low level and technical. Hopefully, I won't loose the OP in
> the process.
>
> A procedural function has a specific postcondition that it must fulfill
> in order to be considered correct, the caller is guaranteed that the
> postcondition will hold true and can operate under that assumption. In a
> very real sense, the caller is using the function to *force* the
> postcondition to become true. The caller is in control in this
> situation. Putting such a function in a class doesn't change this basic
> characteristic (container.insert(x) is not an OO function, but a
> procedural one precisely for this reason.) A vast majority of code in
> any program will consist of such procedures.

even OO programs? This isn't a trick question, I was finding it hard
to express all the functions/methods in my programs in non-imperitive
terms.

Channel::watch()
when_something_happens_on_socket
raw_msg = socket.get_raw_msg ()
msg = make_msg (raw_msg)
message_handler.message_arrived (msg)

so we've told the message_handler there's a message but we havn't told
him (not should we care) what he does with it. The other fucntions in
the above fragment look rather imperitive "get a message!" "parse a
message!"



> An OO function's only postcondition guarantee is that it will return in
> a finite amount of time.
>
> If "car.gasPedalPressed()" were an OO function, then there would be *no*
> guarantee that the car would begin accelerating when the function was
> called.

this is what embedded people call a "bug"
:-)


> If the car started accelerating, it would be because the *car*
> wanted to, not because the caller wanted it to.

which is why Toyota had do all those recalls...

> The ant analogy comes in here. One ant never tells another ant what to
> do, ants tell others what they have been doing, and each ant takes the
> information that comes in and decides what to do based on the
> information.

a couple of pints of boiling water is all the programming I usually
use...
ant_colony.relocate nest!()


--
Nick Keighley