NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/pascal/8395

Text File | 1993-01-21 | 7.3 KB | 171 lines

Newsgroups: comp.lang.pascal
Path: sparky!uunet!gatech!concert!rock!taco!csemail.cropsci.ncsu.edu!samodena
From: [e-mail] (S. A. Modena)
Subject: Re: TurboVision Question (w/ example)
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Crop Science Dept., NCSU, Raleigh, NC 27695-7620
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 21 Jan 1993 14:13:47 GMT
Lines: 159

In article <[e-mail]> [e-mail] (Patrick POLLET) writes:
>In article <[e-mail]> [e-mail] (S. A. Modena) writes:

>>Concerning this part of what Patrick says:
>
>>>              MyDialog^.SetData(Params);
>>>              Desktop^.ExecView(MyDialog);
>>>              .......
>>>            end
>>>
>>>    CAUTION : Since you are executing the Dialog by ExecView, The
>>>application is "put in the background" until the dialog is closed!
>>>So there is no way for the appliaction to update the content of the
>>>paramtext while the dialog is ON SCREEN ....It could be done by the
>>>dialog itself in its method HandleEvent, provided it "knows" the
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>identifiers of the variables that hold the actual data...
>
>
>>Unfortunately, this is misleadingly incorrect.....Patrick has read
>>the TV book and misinterpretted it.  :^)

I want to re-emphasis my point about how Patrick is looking at TV programming.
Something he says below seems to confirm my contention.

>
>[ Stuff deleted ]
>
>>This is known as "event-driven" programming.  Objects talk to each other!
>
>
>    That's exactly what I said... ( by the Dialog itself in its
>     method handleEvent() !!!!!!

>    In your two examples you had to program response to events in the
>ON SCREEN dialogs for it to react  to focused events:
>     -when you clicks on the button MASTER, of the First Dialog .
>     -when you double click on an item of the overlapping Dialog.
>
>   And also you had to adapt the handleevent() methods in the
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>other dialogs when they received notification that something has changed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>elsewhere.
^^^^^^^^^^
   Yes, that's what I said.....and you sort-of said....

>
>   Whether it is a broadcast or a focused event makes no difference.
>
>   It is the ON SCREEN dialog that detect any modification to some
>   Data and requests all others to update....
>
>   Even if you do it at the application Idle level, you still have to
>   program something like:
>
>      If the NewValue of some data has changed
>           send an updating event to Desktop to forward it
>           Update the New value

Yes, I agree with what you've said up to this point.

>
>      This is not really clean programming since the DATA must be global
               !!! ^^^^^^^^^^^^^^^^^^^^^^^^           ^^^^^^^^^^^^^^^^^^^
>   and in two occurences (one for the Oldvalue and one for the NewValue...)
>   So objects do talk to each others but also uses some global data
>   in common....

It's in the preceeding paragraph that Patrick drives his Simca off the
road and into the ditch.

1) It is simply not true that *global* data need be involve....not at all.
   Strictly private data may be passed around...or an address to private
   data.  In fact, it is possible to program the objects to *first* use
   use broadcast techniques to establish the correct respondant
   relationship.

2) Notice that Pat thinks that event driven programming and objects
talking to each other is not "clean" programming.   This is why I said
that Patrick was terrific at TP syntax, but doesn't understand TV poetry.

Pray tell me: What is the purpose of being allowed to create DESCENDANT
classes and to override VIRTUAL methods?

This is an issue "clean programming?"  You have a perverse notion of
what "dirty" programming is.

>
>  In real OOP languages (Frame languages such as Shirka,KL-1,Yafool..)
      ^^^^^
     Pay attention to that key word: "real"
>objects uses REFLEX-methods  that sense any modification of their
              ^^^^^^^^^^^^^^
>environnement  and reacts WITHOUT the need for the object responsible of
>the modification to  signal in some way that something has happened.
>  But TP is not a real OOP language by b[ut] hybrid language.

A couple of points: I'm programming with TP and TV, so those obscure
academic languages, mentioned above,  have nothing what-so-ever with
the topic under discussion.

Next, may I reiterate, I was taking about EVENT-DRIVEN PROGRAMMING,
and you, it appears, are giving advice from a REFLEX-method prejudice.

Is Turbo Pascal a HYDRID language?  Of course, it is!  That is precisely
*why* I use it.  Of course, the word you are looking for is "mongrel."
TURBO PASCAL is a MONGEL language (or... TP is MONGREL implementation of
ISO PASCAL.)   :^)

I suspect that Patrick is looking at this whole thing through the
eyes of an academician, whereas I am programming a real-world
application for distribution to people who will use it to accomplish
real work.  I use TP and TV because they are a *practical* solution
to the need at hand.....otherwise I won't step down from the purity
of Yafool...  (BTW, you do understand the PUN in the name of that
language?)...

>
>      OOP do give some real powerful tools to programmer, but one
>should keep in mind the BASIC concepts of modular programming:
>    -the minimal amount of global data
>    -the mimimal interdependance of modules (whether objects or simple
>       procedures) to each other.
>    -no object should have a direct reference to another one

Well, there you go, talking about *modular* programming.  OK, look back at
what I was talking about (event-driven programming) and I think you will
see that I obeyed your three dicta of *modular* programming under the
EVENT-DRIVEN case using a OBJECT-ORIENTED implementation.  :^)  BTW, I use
TP and TV because they ease adherence to MODULAR programming, which I
very much favor.  :^)

>
>[e-mail] (Patrick POLLET)
>--------------------------------------------------------

To repeat my cautionary: TV application framework objects are designed
to be modified by the techniques of class derivation and virtual
method override.  In particular, TV is event-driven and you are encouraged
to be event-driven-minded, to be experimental, and to "play" with
the OO and event-driven features as they were intended to be, rather
than attempt uses then in a structured-analysis frame-of-mind.

Ciao,

Steve
---
+------------------------------------------------------------------+
|     In person:  Steve Modena     AB4EL                           |
|     On phone:   [phone]                                   |
|     At e-mail:  [e-mail]                           |
|                 [e-mail]                |
|                 [ either email address is read each day ]        |
|     By snail:   Crop Sci Dept, Box 7620, NCSU, Raleigh, NC 27695 |
+------------------------------------------------------------------+
         Lighten UP!  It's just a computer doing that to you.    (c)
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO