Stef,

>I agree with what you are saying but here the point is not the
> change  the implementation of the ClassBuilder but just
> to know if removing Behavior from the classes
> that are dangerous is a problem.

There is no dangerous classes.

To break the system (e.g. changing a class) is one of the
 steps in learning process.
If you remove the step from the road, people think
 he/she has learned to produce a "stable" system.

Removing #Behavior (a name) from the method
 is not a go forward; it is like moving a card from one
 hand to the other but continue playing the same game :-)
 (like while refactoring... really no compromise is taken)

best,
Ale.



----- Original Message ----- 
From: "stéphane ducasse" <ducasse at iam.unibe.ch>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Sunday, October 16, 2005 5:57 PM
Subject: Re: feedback needed on tooDangerousClasses changes


Alejandro

I agree with what you are saying but here the point is not the change
the implementation of the
ClassBuilder but just to know if removing Behavior from the classes
that are dangerous is a problem.
Klaus I tested on the latest 3.9 and I did not get the error you got.
Strange

Stef

On 16 oct. 05, at 12:27, Alejandro F. Reimondo wrote:

> Hi,
>
>
>>      "Return a list of class names which will not be modified in the
>> public interface"
>>
>
> Why return the names and not the classes?
> If there is some "interesting" instances of Behavior, the instances
>  are to be returned and not their names, because names have
>  meaning in a context.
> Working on names also inhibit the use of tools like references.
>
> Please consider the convenience to add methods that has not been
>  used for a long time, or methods that are product of "preventive
>  refactoring".
>
> The comment (the most important part of a message)
>  also refers to a "public interface".
> Is there such a montser in current (or planned) Squeak release?
> If class "Interface" is not present, please evade naming it in
>  comments becasuse it bring confusion about the real
>  convenience of it's existence.
>  (it it really exists please name it if have a role as an
>  argument in the message)
>
> And on implementation...
> Why to put the results in a literal?
> Why not to implement it in a collection? (capable to
>  be modified by tools whitout writing source code)
>
> This kind of messages and implementations present in Squeak (and
>  other Smalltalks) are one of the most inhibitors of advances in
>  Object Technology (in my opinion).
> The use and promotion of Smalltalk as a language and the
>  proliferation of formal models inside an ambience as a result
>  of planning and not as a concecuence/subproduct of evolution
>  inhibit people to get experience in object ambiences (complement
>  formal-ism with non-formal activities).
>
> cheers,
> Ale.
>
>
>
>
>
> ----- Original Message -----
> From: "stéphane ducasse" <ducasse at iam.unibe.ch>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Sunday, October 16, 2005 3:22 PM
> Subject: feedback needed on tooDangerousClasses changes
>
>
>
>> Hi
>>
>> I need feedback on the changes of daniel on tooDangerousClasses in
>> ClassBuilder.
>> To test simply
>> What I did was to add an instance variable to Behavior at the end of
>> the instance variable list and it did not crash
>> just recompiled the complete image.
>>
>>
>> Name: Kernel-dvf.36
>> Author: dvf
>> Time: 27 September 2005, 3:34:50 pm
>> UUID: 6e9f8d6d-873c-4e19-9b63-3096f9d01141
>> Ancestors: Kernel-md.34
>>
>> Behavior actually can be redefined, as long as one doesn't move some
>> of its first instance variables. ProtoObject, OTOH, probably can't
>> be.
>>
>>
>> tooDangerousClasses
>>      "Return a list of class names which will not be modified in the
>> public interface"
>>      ^#(
>>          "Object will break immediately"
>>          ProtoObject Object        "was Object"
>>          "Contexts and their superclasses"
>>          InstructionStream ContextPart BlockContext MethodContext
>>          "Superclasses of basic collections"
>>          Collection SequenceableCollection ArrayedCollection
>>          "Collections known to the VM"
>>          Array Bitmap String Symbol ByteArray CompiledMethod
>> TranslatedMethod
>>          "Basic Numbers"
>>          Magnitude Number SmallInteger Float
>>          "Misc other"
>>          LookupKey Association Link Point Rectangle
>> PositionableStream UndefinedObject
>>          "was LookupKey Association Link Point Rectangle Behavior
>> PositionableStream UndefinedObject"
>>      )
>>
>> I imagine that this is needed for trait refactoring.
>>
>> Stef
>>
>>
>
>
>