🚀 go-pugleaf

orpheus@reed.edu (P. Hawthorne) writes:
>It seems un-structured. What would Djikstra say?

I find myself using member() in the TCL for three chief purposes:

1]  ASSERTs.  It's handy to make sure something is what you expect.
2]  In CCollaborators' ProviderChanged() method, testing whether the
provider that changed is of a certain type.  (For non-TCLers,
CCollaborator is a class whose instances can DependUpon() each other;
whenever a CCollaborator calls BroadcastChange(), all itsDependents
get their ProviderChanged() method called.  Very handy, but to design a
flexible system, a CCollaborator has to expect to get lots of unwanted
ProviderChanged() messages.)
3]  In methods that, I suspect, would be called "friend" under C++.
Think C doesn't give you a way to link a bunch of classes together and
say "only these classes are friends of mine, and only my friends can
call the following methods."  (Is that essentially what C++ does?)
So you have to fake it with run-time checking on your own.

>When I use it...I worry that perhaps a seriously
>abstract class variable could formalize whatever notions are at work. Or I
>think that it is a kludge so that I can put off a total overhaul until I
>figure out how to work in the exceptional classes.

If you write, for example,

void CEatingObject::eatObject(CFoodObject *theFoodObj)
{
	if (member(theFoodObj, CBanana)) gobbleBanana();
	else if (member(theFoodObj, CCookie)) munchCookie();
	else if (member(theFoodObj, CSquid)) slurpSquid();
}

...then you're misusing member().  (In this case, the eating method
should go into CFoodObject, not CEatingObject, and should be overridden
by all those subclasses.)

If Think C's lack of multiple inheritence forces you to construct a dual
class hierarchy, I can see having to misuse member(), as a consequence.

But otherwise, unless you're doing something like CEatingObject, I
wouldn't worry about it.
-- 
 Jamie McCarthy      Internet: k044477@kzoo.edu      AppleLink: j.mccarthy
 "Apple developers will still have access to System 7.1 through the
  monthly Developer CD series, but they may use it only for testing
  and development purposes."              - AppleDirect, Nov/Dec 92

In article <1992Dec13.144549.24447@reed.edu> orpheus@reed.edu (P. Hawthorne) writes:
>From: orpheus@reed.edu (P. Hawthorne)
>Subject: The Member Function: Spawn Of Satan?
>Date: 13 Dec 92 14:45:49 GMT
>In Object C and Pascal, the member function reveals whether a given object
>is descended from a given class. I wonder if it is good or bad to use it.
>It seems un-structured. What would Djikstra say?
>
>When I use it, I invariably feel guilty. I worry that perhaps a seriously
>abstract class variable could formalize whatever notions are at work. Or I
>think that it is a kludge so that I can put off a total overhaul until I
>figure out how to work in the exceptional classes. That sort of thing.
>
>So then, am I just an OO-prude?
>
>Dumbfounded,
>Theus (orpheus@reed.edu)


As of today, I#ve found a very nice way to use the member() function. Say, 
we want something to do at the idle time -- update a clock on-screen, do 
some measuring from an external DVM, something the like. It turns out the 
clock never needs to be configured, while the external device needs this 
option (since there is more than one kind of external device You can connect 
to). Of course, the solution is a class

class TIdlingObject{}

which does all the idling behavior, such as scheduling idlers, executing 
them, and the like.

derived from this one are various subclasses -- say, TEditableIdlingObject 
and TFacelessIdlingObject.

The tricky part comes when You want the user to access instances of idling 
objects. You can easily build a list of TIdlingObjects, but the only way to 
exclude the TFacelessIdlingObjects from the list will be to call the member 
function -- which tells You if the object You look at is an 
TEditableIdlingObject.

So, leave the theroy aside and use it -- it's really useful.

-Christoph

P.S: Sorry about all that MacAppish names, but I'm used to...

---------------------------------------------------------------------------
Christoph P. Sold                   CATS Software GmbH
                                    Mussbacher Landstr.2
sold@kit.uni-kl.de                  W-6730 Neustadt (Weinstrasse)
ger.xse0035@applelink.apple.com     Germany

"If an apple is fun, what the heck is an appletree?"

Wouldn't it be better (or purer) to have an instance variable, fVisible say,
and an accessor method, GetVisibility, in the parent class?  (or am I missing
something?)

.../dave   Dave Charlesworth