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
|