[KCP] SystemChangeNotifications: Current state and some code

Roel Wuyts wuyts at iam.unibe.ch
Fri Jul 25 21:10:14 UTC 2003


I'll put it on Squeakmap somewhere this week.
Before inclusion it needs to capture some more system changes (I am 
extending the set).

In the meantime I made it safer for updating clients: events are sent 
synchronously, but every event handler execution is wrapped in 
exception handling code. When an exception occurs, it is remembered and 
the other events are handled. After all the events are handled, the 
exceptions that occurred are thrown again. It is fun writing unit tests 
for this :-)

On Monday, Jul 21, 2003, at 15:42 Europe/Zurich, Daniel Vainsencher 
wrote:

> I'm sure it will be clearer once implmementation is complete.
>
> Please release it on SM - it deserves to be more visible as it is.
>
> What're the next steps for this code? what do you think should happen
> before it is considered for inclusion in 3.7a?
>
> Daniel
>
> Roel Wuyts <wuyts at iam.unibe.ch> wrote:
>> The current implementation is a bit boring, yes :-) The idea is that
>> you can ask each event for 'useful' information, and calculate it in a
>> lazy way so that clients have t worry less. For example, if you get an
>> 'added' event for a method, you can ask this event (through this
>> uniform interface) for its 'itemMethod' (returning you the method that
>> has been added), its 'itemProtocol' (the protocol for the method), its
>> 'itemClass' (the class of the method), etc. For some of these items, I
>> do not have this information readily at hand (it might not be in the
>> environment) but I can calculate it from information that I know 
>> about.
>> But these pieces of code are not there yet, so that is why they look
>> uniform. For example, I will add some code in 'itemClass' that
>> calculates the class from the method, if the method is known but the
>> class is not. I hope this makes it a bit more clear :-) It will be
>> easier to follow once implemented :-) :-)
>>
>>
>>
>> On Tuesday, Jul 15, 2003, at 11:51 Europe/Zurich, Daniel Vainsencher
>> wrote:
>>
>>> [class names]
>>> I proposed "Code" instead of "System" as being much specific and
>>> intention revealing, though "code" isn't a very precise term in
>>> Smalltalk.
>>>
>>> <nit pick>BTW, can you explain the rationale for the methods in
>>> SystemChangeNotifier>item kinds? it seems very repetitive and a bit
>>> cumbersome. </nit pick>
>>>
>>> Daniel
>>>
>>> Roel Wuyts <wuyts at iam.unibe.ch> wrote:
>>>> Oops, I forgot to add this point on my to-do list. It is one of the
>>>> reasons that I did not write too much documentation yet (because
>>>> otherwise I have to keep it up-to-date whenever I refactor some name
>>>> :-(  ). The current names 'grew' while developing but are not really
>>>> good.
>>>>
>>>> Note that the names you propose will not really do though (since for
>>>> example, the current  SystemAddedEvent can be used with classes,
>>>> methods, instance variables, etc.). That is why I took this name:-)
>>>> But
>>>> since I know I am not very good at names any input on this front is
>>>> welcome :-)
>>>>
>>>> PS: Thanks for pointing out that it is one of the Squeak traditions 
>>>> to
>>>> not use prefixes for class names. This used to be the convention in
>>>> Smalltalk (at least in VisualWorks), to make it clear which code
>>>> belonged together when not seeing it in categories, and for avoiding
>>>> name clashes. I was not aware that this was changed in the meantime 
>>>> in
>>>> Squeak, even in the absence of namespaces.
>>>>
>>>> PS2: [fun] you have to agree that SystemEvent is already a much 
>>>> better
>>>> name than ExtensionalClassification :-) :-) Maybe I'll learn it in 
>>>> the
>>>> end :-) :-)
>>>>
>>>> On Tuesday, Jul 15, 2003, at 10:25 Europe/Zurich, Brent Pinkney 
>>>> wrote:
>>>>
>>>>> Roel,
>>>>>
>>>>> I have not had the time to install and test your code.
>>>>>
>>>>> I do think however that we must be very careful when naming new
>>>>> classes, especially of this significance.
>>>>>
>>>>>>> (4) SystemEvent: root class of the events that implement most of
>>>>>>> the
>>>>>>> functionality
>>>>>>>  ...snip...
>>>>>>> so you find classes SystemAddedEvent, SystemRenamedEvent, ...
>>>>>
>>>>> One of the traditions of Smalltalk and Squeak in particular is that
>>>>> class names do not describe their implementation or namespace.
>>>>>
>>>>> This exact issue has come up recently on the list with the
>>>>> introduction of the Deprecation exception. That class was 
>>>>> originally
>>>>> called DeprecatedException. This, I hope you agree, does not match
>>>>> the
>>>>> feel established by the ANSI exceptions: DivideByZero and
>>>>> MessageNotUnderstood, Halt.
>>>>>
>>>>> The mailing list seemed to agree and the class was renemed to
>>>>> Deprecation.
>>>>>
>>>>> Similarly I would strongly urge you to concider a similar naming
>>>>> convention\hierarchy for the events...
>>>>>
>>>>> e.g. (of the top of my head)
>>>>>
>>>>> Event
>>>>>    CodeModified
>>>>>       ClassChanged
>>>>>       ClassRenamed
>>>>>       ClassAdded
>>>>>       ClassRemoved
>>>>>       MethodAdded
>>>>>       MethodRemoved
>>>>>
>>>>> PS. For this same reason, objects like SMObject and MagmaCollection
>>>>> make me unhappy, despite their excellent functionality.
>>>>>
>>>>> There is something very homely and intimate in the Smalltalk
>>>>> convention which prevents is feeling like _code_. It is about as 
>>>>> far
>>>>> away from Hungarian notation as you can get - Squeak has ubiqitious
>>>>> reflection to assist the developer.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> Brent
>>>>>
>>>>>
>>>> Roel Wuyts                                                   
>>>> Software
>>>> Composition Group
>>>> roel.wuyts at iam.unibe.ch                       University of Bern,
>>>> Switzerland
>>>> http://www.iam.unibe.ch/~wuyts/
>>>> Board Member of the European Smalltalk User Group: www.esug.org
>>>
>>>
>> Roel Wuyts                                                   Software
>> Composition Group
>> roel.wuyts at iam.unibe.ch                       University of Bern,
>> Switzerland
>> http://www.iam.unibe.ch/~wuyts/
>> Board Member of the European Smalltalk User Group: www.esug.org
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org



More information about the Squeak-dev mailing list