Lurkers views on KCP (was Dialog warn: equivalent in squeak)

Russell Penney russell.penney at tincanct.com
Wed Jun 4 06:41:49 UTC 2003


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 at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at 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 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