Newsgroups: comp.soft-sys.powerbuilder,comp.object,comp.lang.c++,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!godot.cc.duq.edu!news.duke.edu!news.mathworks.com!uunet!usenet
From: rbrooks@waterw.com (Rik Brooks)
Subject: Re: what is an object?
Message-ID: <D7A26D.LAs@waterw.com>
Sender: usenet@waterw.com (Usenet daemons)
Nntp-Posting-Host: dial2.waterw.com
Organization: Brooks & Young
X-Newsreader: WinVN 0.92.5
References: <3mu025$e5o@tst.hk.super.net>
Date: Wed, 19 Apr 1995 10:23:00 GMT
Lines: 90
Xref: glinda.oz.cs.cmu.edu comp.soft-sys.powerbuilder:13645 comp.object:29738 comp.lang.c++:123805 comp.lang.smalltalk:22869

In article <3mu025$e5o@tst.hk.super.net>, dickensl@hk.super.net (Mr Dickens Leung) says:
>
>Prior to touching PB, I found it quite comfortable with _both_ C++ and
>ST's approaches to OO.  I understand that the approaches are different,
>but I can appreciate (or so I think) the rationale behind them. In come
>PB, specifically the book Using PowerBuilder 4 Special Edition from Que
>Corp, and I become disturbed.  In chapter 5, page 131, this book gives
>out a list of data types available in PB; the list includes this
>fragment:
>
>   Data Type   Comments
>   ----------  -------------------------------------------------------
>   DragObject  Contains the dragged object type. Values include all
>               draggable objects with controls (but no drawing objects).
>
>   Object      Contains the enumerated type of a PowerBuilder object.
>               Values include all windows and controls.
>
>   PowerObject Any PowerBuilder object including structures. Usually
>               used with the OpenWithParm commands.
>
>Now what puzzled me was that after reading these definitions times and
>again I still haven't got a clue about how the objects are different and
>why they are distinguished that way.  Intuitively, I had thought: OK,
>DragObjects are the objects that PB considers as being draggable, but
>what the hell is a PowerObject and how does it relate to an Object?
>
>You see, I like to see exact and accurate wordings in any given
>definition but I'm afraid I've got completely confused by the above.
>
>Also, in other parts of the book, they seem to be distinguishing between
>controls and objects.  On that, I thought: Isn't a control an object? A
>control exhibits quite some behaviour and have a state associated with
>it, so shouldn't it be regarded as an object?  Maybe they regard
>controls as raw material for building objects just as what C++ regards
>of primitive types (integers, floats)?  If they indeed made that choice,
>I think it's a bad tasted one.
>
>Why do I _only_ feel uncomfortable with PB's view?  Well, I found ST's
>regarding every noun as an object consistent and pure. I do find things
>such as "a > b and: [ b > c ]", "i to: j" and True & False being
>subclasses of the Boolean class a bit odd but given the goal of being
>pure I probably would have designed it that same way.
>
>As for C++, I found its middle-of-the-road approach reasonable because I
>think primitive types are being handled efficiently as is and there's no
>compelling reason to enforce an all-object view. I mean, if you treat an
>integer as a class, it will either be too uninteresting (with the most
>obvious methods - the basic arithmetic operations - implemented) or be
>too bloated (with every conceivable and remotely relevant method
>implemented).
>
>Having said all that, I do realize that:
>
>1) It could be that only "the book" (or particular sections in it) is in
>   error and presented PB incorrectly.
>
>2) My English (or my comprehension ability) is too lousy (low) to
>   understand what is actually being said in the book (or in other
>   books).
>
>In any case, I think there exist different views on what to regard as an
>(non-)object and a discussion on such would be interesting.  Anyone
>then?
>
>

Maybe I can clarify somewhat.  All of the objects mentioned above ARE 
objects.  The object Object is the lowest level.  The others are inherited
from it and thus objects in themselves.  Some of the objects are from
MicroSoft (A window object, for example).

Controls are an inherited kind of object.  They are handled differently
in the passage that you mentioned because they are different.  Let me use
a pretty old reference here.  You can have an object 'Vehicle'.  From that
inherit 'Truck' and 'Car'.  From 'Truck' inherit 'Dump Truck'.  It would
be logical to refer to this as different from a 'Vehicle'... after all,
a vehicle can't dump.

A PowerObject is just one that MicroSoft doesn't know anything about.  It's
mainly used for opening with parameters and closing with return.  Opening
with parm means that PowerSoft puts the parameter that you specify in a
global variable that you can access in the open event.  Closing with return
is the opposite.

If you really want to understand this then the best thing to do is to 
create a few user defined objects for yourself and play with them.  Check
out the Standard Visual types.

Hope this helps
