Dialog warn: equivalent in squeak

JOEL SHELLMAN joelhelenshellman at comcast.net
Wed May 28 14:58:44 UTC 2003


As I mentioned, if you need the flexibility of a level of indirection, 
put it in. It's the difference between a hard and soft dependency. If 
you have a hard dependency, you will not be able to remove PopUpMenu 
(ie. your app requires that functionality). A soft dependency means you 
require similar functionality but could be swapped out. In that case, 
put in a level of indirection and you're fine. That's just standard 
good practice.

One of the problems with putting it on Object is that if you change it--
you change it for everything. So if you change it for your app, someone 
else's app now behaves differently than it (or the user) expected which 
could cause problems.

-joel

----- Original Message -----
From: Bert Freudenberg <bert at isg.cs.uni-magdeburg.de>
Date: Wednesday, May 28, 2003 7:08 am
Subject: Re: Dialog warn: equivalent in squeak

> 
> Am Mittwoch, 28.05.03 um 15:34 Uhr schrieb Joel Shellman:
> 
> >> Actually, "self inform:" is way better.
> >>
> >> How would creating an explicit dependency to PopUpMenu be 
> better than 
> >> a
> >> generic message send to self? That is as encapsulated as you 
> can get.
> >>
> >> The fact that _currently_, generic methods are implemented as 
> instance>> methods of Object is just a nuisance. The main point is 
> that 
> >> currently,
> >> any object depends on Object anyway, so no artificial 
> dependency is
> >> introduced at all.
> >
> > Not only are you introducing an artificial dependency, but you are
> > introducing a hidden dependency because anyone who uses self 
> inform: 
> > will
> > now be dependent on PopUpMenu and may not even realize it.
> 
> Not so. _My_ code is not dependent on PopUpMenu. Suppose you 
> remove 
> PopUpMenu (which you surely might want to do in a non-GUI 
> environment) 
> - would you rather go and fix a myriad of places explicitely 
> naming 
> PopUpMenu? Or would you rather reimplement Object>>#inform:?
> 
> -- Bert
> 
> 
> 



More information about the Squeak-dev mailing list