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@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
I have just come back from overseas and have been on a plane or in airports for the last 20 hours (and there was a screaming baby on the plane thus no sleep for most of that time, god I hate economy class travel) so if this doesn't make much sense, I apologise :)
I see these discussions as a symptom of a wider ranging problem. IMHO People are blurring the distinction between common code and useability/application code. I have a vision for the KCP end-result of a tiny image containing enough code to start and file-in a change-set from the local disk. So you would need Object, Compiler type classes, some Collections and Magnitudes, some File I/O, Transcript and I am sure some other things I don't know about. Any output would be directed to the Transcript which by default would just write to a file. Everything else would be modules to be loaded. That first file-in could be a script which loads Network support, HTTP support and proceeds to get a huge list of modules from SqueakMap to build you a full Morphic+ image. Or it could just load just enough to get Seaside running. Or just enough to be able to be controlled via the network. Or just enough to read from the serial port for embedded work. Or whatever clever people want to do. That way people can have a raft of small modules to do their useability functions and their code can depend on those being loaded. So Bert and friends can have inform: in Object because that is the way they like to program and any modules they write would have the "BertUsability" module as a dependency. If I want to use their code then I either hack their code or just load that module so their code will work. But if I am writing an application that doesn't need any of their code I don't have to have those methods cluttering up my lovely minimalist image. :) One upside to this is that each module could publish/document the list of "public" functions that they contain. Easy entry points for newbies and also a way to know that your code will work with that module. If you want to go outside the spec then go for it but beware that the internals may change in future versions. As long as the basic methods don't change then you can write a replacement without affecting any code. If your replacement module passes all the Sunit tests for that module then there should be no problems. And of course people can publish a module which has all the basic features plus new ones. Downside is that a lot of code may have to change but in the long run I think we would end up with a cleaner Squeak.
I guess my point is that the Kernel classes should do things in the most basic way with as few "convenience" functions as possible with the option of overloading or dumping methods into Object later. I haven't looked at the ANSI standard but that would seem to me to be the place to start for the basic methods.
Just my 2 cents and with the aussie dollar the way it is, that is not much :)
Russell
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of JOEL SHELLMAN Sent: Thursday, 29 May 2003 12:59 AM To: The general-purpose Squeak developers list Subject: Re: Dialog warn: equivalent in squeak
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@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
"Russell Penney" russell.penney@tincanct.com wrote:
I have a vision for the KCP end-result of a tiny image containing enough code to start and file-in a change-set from the local disk.
This isn't actually the focus of the KCP project but is very much the intent of Craig's Squat and other efforts. Search for references to squat and join in the fun. We need more help.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- So dumb, he faxes face up.
squeak-dev@lists.squeakfoundation.org
-
JOEL SHELLMAN -
Russell Penney -
Tim Rowledge