Kamil wrote about his impressions and posed some questions.
Here are remarks to some of his questions:

>>For example, Object understands so many methods that I doubt it still 
>>stands for basic building stone.

I agree that the Object protocol became huge over time. Methods like
#beep are not really necessary, but they are convenient.

>>Should every object understand how to 'inspect itself'?

Yes, I think it should. Inspection is a general concept and it
is very helpful during debugging.

>>In network environment, what is the sense for 'myString' inspect
>>on some silent server? 

For some classes it may be necessary to redefine #inspect and
that is waht you should do when you feel that the general inspection
is inappropriate. By the way: Currently, we have seven implementors
of inspect. You find them when you select the inspect method
of Object and select the menue option "implementors of...".
It is instructive to analyse these seven definitions.

>>Also, what is "indexable receiver" mentioned in Object>>at: message?

This is protocol for variable subclasses only. (Examples of variable
subclasses are Array and String)  #at:  (and  #at:put:)  will
raise an error for ordinary classes
Example:   Color red at: 1
raises the error  "COlors are not indexable"
Variable subclasses are not often used. Look at Array for an
example or try to define univariate polynomials.

Of course it is strange that Object has these messages that can
be sent to variable subclasses only, but the advantages is, that
every ordinary class can be the superclass of a variable class.
Had we defined a hierarchy like

 Object
   FixedSizeObject
     <classes like Color, Boolean, View>
   VariableSizeObject
     <classes like Array, String, Float>

we would have a very strict distinction between 
fixed size objects and variable size objects. We would then
have to split the Collection hierarchy into two herarchies.

>>Or - LargeNegativeInteger is subclass of  LargePositiveInteger - 
well......

Well, here the classes have the responsibility to represent the sign.
This is an implementation trick. (By the way: IBM Smalltalk uses a
class LargeInteger to represent both positive and negative large
integers)

>>Or - message Date>>printOn:format: - was that school assignment?

Date formats are a point of endless conflicts. For my needs,
'Jun 6, 2002' is sufficient, but a lot of persons are quite
ideological about the date format.  Date>>printOn:format:
is an attempt to be helpful. You will find other such attempts
elsewhere in the image.

>>I like the syntax for passing arguments to message but then to have 
>>message like #perform:with:with:with:?

The perform is needed to send a message whose name is not
written down in the text of your method, but kept in a variable.

This is a key element in callback mechanisms that are used
in most windowing systems.

You have for example

  setNameOfCallback: aSymbol
    name := aSymbol

and than, in an other method:

  cooperatingPartner perform: name
       with: arg1
       with: arg2

This works when  the symbol is a selector than can be
used with two elements, like  #acceptText:controller:
 
The use of  variables to keep the method name and the
identity of a cooperating object gives the
flexibility to configure an instance to the specific needs of that
partner. (This statement can be reworded into pattern
terminology, but I think that is not really necessary.)

>>Would it be possible to extend language so it could be 
>>written as something like #perform:*with:?

I failed to fully understand this question.

>>Maybe I am expecting something else from "the thing" that
>is purposed as a toy for education. Maybe I'm balancing
>>between chaos and order. Maybe I just don't get the 
>>rhythm in this music :)

Really difficult to say. I am a bit surprised to see Squeak
called a toy for education but I also strongly feel that at
this very moment I am not in a position to convince you
that Squeak is much more. Finally, Squeak can be used
as a toy for education, so you are not completely wrong.

All my interesting porjects are still unfinished, so I have
nothing that I could give you. This may change in a few
years, but for now I have nothing. (Until tomorrow, I will
prepare the polynomials for you)

Greetings

Boris Gärtner

msg  systems ag
Fraunhoferstraße 9
85737 Ismaning

Tel.: (+89) 96 101 546
mailto: Boris_Gaertner at msg.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20020605/de16cd08/attachment.htm