Re: Just let me know if I lose my time and yours

Hi Stef.

I think so far KCP has given us changes that are definitely for the
better. Where I thought that some changes are wrong, I said it (things
that should be class extensions, but implemented on Kernel classes). 
Andreas' warning to find good concepts for classes before moving them
sounds like a good idea to me. I think there are a lot of places we
could take ideas from (other big projects have preferences/utilities
too, or maybe deal with some of the same functionalities). Where you are
not sure you have a clear concept, it might be better to delay working
on it until later.

But so far, so good. I think people do understand the importance of what
you're doing, and that's why you're getting comments and suggestions. 

Daniel

Stephane Ducasse <[email protected]> wrote:
> I do it because I feel 
> it important.
> Now if you think that I'm over cleaning, over refactoring, if you think 
> that I'm
> creating too much classes and that Squeak should stay the way it is, 

> Stef
From [email protected] Thu Jun 12 08:47:38 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 22922 invoked from network); 12 Jun 2003 08:47:38 -0000
Received: from ns.bluefish.se (HELO leia.bluefish.se) (213.212.22.234)
  by mail.theinternetone.net with SMTP; 12 Jun 2003 08:47:38 -0000
Received: from [213.80.63.110] (helo=aSqueakSystem)
	by leia.bluefish.se with smtp (Exim 3.12 #1 (Debian))
	id 19QNk8-0001pV-01
	for <[email protected]>;
	Thu, 12 Jun 2003 10:47:36 +0200
X-Mailer: Celeste 2.0.4917
Date: Thu, 12 Jun 2003 10:47:29 +0100 
In-reply-to: <[email protected]>
Subject: Re: [Squeakfoundation]Just let me know if I lose my time and yours
To: Discussing the Squeak Foundation
	<[email protected]>
References: <[email protected]>
From: [email protected]
Message-Id: <[email protected]>
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.squeakfoundation.org/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Thu, 12 Jun 2003 08:47:38 -0000

Hi Stephane, Andreas and all!

Instead of quoting a lot of text etc I try to keep it to the point:

- Keep on cleaning Stephane! Sure, sometimes people will disagree with
selected proposed actions - but we are *all* grateful for the work being
done, including Andreas I am sure. So please, don't be discouraged. The
progress so far is great.
- Regarding these "hard to place methods", placing #abandonSources in
Image does sound perfectly reasonable to me... And I would also expect
to find the #snapshot:andQuit: family of methods there (even though I
don't really like the names of those...).
- Regarding the rest of these methods, there may be methods that really
are hard to place - and in that case I agree that a Utilities class can
be good to have, BUT:
	- Placing them all in one class may need the use of class extensions so
that it doesn't "hurt" the partitioning of the image. If we put a
utility method for Morphic and a utility method for files in the same
class called Utilities then we will create problems for minimal images
without Morpic - unless we use class extensions.
	- Having utility methods in class SystemDictionary seems utterly wrong
to me. Just listen to the name - SystemDictionary. What on earth tells
the novice that this is a place for Utility methods? Nothing IMHO. It is
also confusing for the novice that the methods are in "SystemDictionary"
but you run them by sending messages to "Smalltalk"... But the class
name Utilities or even UtilityMethods with the methods on the class side
is much better I think. If we indeed are talking about functions then I
think it is appropriate for them to be on the class side.

Just my 2... öre. (at least until we join the EMU)

regards, Göran
From [email protected] Thu Jun 12 09:28:44 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 12864 invoked from network); 12 Jun 2003 09:28:43 -0000
Received: from mailhub01.unibe.ch (130.92.9.52)
  by mail.theinternetone.net with SMTP; 12 Jun 2003 09:28:43 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailhub01.unibe.ch (Postfix) with ESMTP id AE8BF25BBB6
	for <[email protected]>;
	Thu, 12 Jun 2003 11:28:42 +0200 (MEST)
Received: from mailhub01.unibe.ch ([127.0.0.1])
 by localhost (mailhub01 [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 01289-01-35 for <[email protected]>;
 Thu, 12 Jun 2003 11:28:40 +0200 (MEST)
Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4])
	by mailhub01.unibe.ch (Postfix) with ESMTP id 3EAA725BB33
	for <[email protected]>;
	Thu, 12 Jun 2003 11:23:27 +0200 (MEST)
Received: from iam.unibe.ch (asterix [130.92.64.4])
	by asterix.unibe.ch (8.11.6+Sun/8.11.6) with ESMTP id h5C9NQK17630
	for <[email protected]>;
	Thu, 12 Jun 2003 11:23:26 +0200 (MET DST)
Date: Thu, 12 Jun 2003 11:23:26 +0200
Subject: Re: [Squeakfoundation]Just let me know if I lose my time and yours
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Stephane Ducasse <[email protected]>
To: Discussing the Squeak Foundation
	<[email protected]>
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
X-Mailer: Apple Mail (2.552)
X-Virus-checked: by University of Berne
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.squeakfoundation.org/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Thu, 12 Jun 2003 09:28:44 -0000


On Thursday, June 12, 2003, at 11:47 AM, [email protected] wrote:

> Hi Stephane, Andreas and all!
>
> Instead of quoting a lot of text etc I try to keep it to the point:
>
> - Keep on cleaning Stephane! Sure, sometimes people will disagree with
> selected proposed actions - but we are *all* grateful for the work=20
> being
> done, including Andreas I am sure. So please, don't be discouraged. =
The
> progress so far is great.
> - Regarding these "hard to place methods", placing #abandonSources in
> Image does sound perfectly reasonable to me... And I would also expect
> to find the #snapshot:andQuit: family of methods there (even though I
> don't really like the names of those...).

this is there (in the next KCP I will try to produce).

> - Regarding the rest of these methods, there may be methods that =
really
> are hard to place - and in that case I agree that a Utilities class =
can
> be good to have, BUT:
> 	- Placing them all in one class may need the use of class =
extensions=20
> so
> that it doesn't "hurt" the partitioning of the image. If we put a
> utility method for Morphic and a utility method for files in the same
> class called Utilities then we will create problems for minimal images
> without Morpic - unless we use class extensions.
> 	- Having utility methods in class SystemDictionary seems utterly =
wrong
> to me. Just listen to the name - SystemDictionary. What on earth tells
> the novice that this is a place for Utility methods? Nothing IMHO. It=20=

> is
> also confusing for the novice that the methods are in=20
> "SystemDictionary"
> but you run them by sending messages to "Smalltalk"... But the class
> name Utilities or even UtilityMethods with the methods on the class=20
> side
> is much better I think. If we indeed are talking about functions then =
I
> think it is appropriate for them to be on the class side.

Ok thanks for the feedback I was tired and pissed of yesterday (really).

Stef

>
> Just my 2... =F6re. (at least until we join the EMU)
>
> regards, G=F6ran
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
>