The Trunk: Kernel-mt.1012.mcz

Marcel Taeumel uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-mt.1012.mcz

==================== Summary ====================

Name: Kernel-mt.1012
Author: mt
Time: 5 April 2016, 10:42:29.505517 am
UUID: 83d8a4a7-a80d-1848-90d0-d10abf9728f7
Ancestors: Kernel-ul.1011

Restore clean-up code, which got lost with the introduction of object events long time ago (around Squeak 3.7 or so).

Break dependency to #releaseActionMap implemented in the System package.

=============== Diff against Kernel-ul.1011 ===============

Item was changed:
  ----- Method: Object>>release (in category 'dependents access') -----
  release
  "Remove references to objects that may refer to the receiver. This message
  should be overridden by subclasses with any cycles, in which case the
  subclass should also include the expression super release."
 
+ self breakDependents.
+ (self respondsTo: #releaseActionMap) ifTrue: [self releaseActionMap].!
- self releaseActionMap!

On Tue, 5 Apr 2016, [hidden email] wrote:

Is #respondsTo: necessary? Object seems to implement #releaseActionMap.

Levente

> - self releaseActionMap!
>
>
>

Hi Levente,

#releaseActionMap is part of the System package, not Kernel package, where Object belongs to.

Unless we decide to tightly couple both packages, we either require "self respondsTo:" or an override extension from System to Kernel.

Best,
Marcel

Right. That kinda worth a comment. :)

Levente

On Tue, 5 Apr 2016, marcel.taeumel wrote:

> On 05-04-2016, at 8:23 AM, marcel.taeumel <[hidden email]> wrote:
> #releaseActionMap is part of the System package, not Kernel package, where
> Object belongs to.
>
> Unless we decide to tightly couple both packages, we either require "self
> respondsTo:" or an override extension from System to Kernel.

Or we do a proper job of working out an effective way of doing this. I really hate to see (ab)use of #respondsTo:  like this. Surely it must be slower than simply sending the message - allowing the VM to do its normal fast lookups and caching - and occasionally having to catch a dNU: ?

If that is a practical path, then we need to imagine some simple and comprehensible ways to
a) catch the dNU and do.. whatever
b) discover that the catching is needed, which seems like some sneaky package analysis stuff well suited to a PhD student
c) find a way to use a & b without pissing off the general user/coder

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Rules for Optimization: 1. Don't; 2. (for experts only) Don't Yet

Or move #release to System?

I see no good reason to litter the code with unnecessary checks. It’s ugly, and if we ever untangled Kernel and System then I bet dependents stuff should not end up in Kernel, right?

- Bert -

+1

and then there's overrides...

>
> - Bert -
>
>
>
>

Hi Tim,


Sure.  The main overhead is in allocating the blocks (& hence contexts) for the on:do: handler for the MNU.  But having an empty method on Object in Kernel and overriding it in System would be ideal if Monticello had robust support for overrides.

>
> If that is a practical path, then we need to imagine some simple and comprehensible ways to
> a) catch the dNU and do.. whatever
> b) discover that the catching is needed, which seems like some sneaky package analysis stuff well suited to a PhD student
> c) find a way to use a & b without pissing off the general user/coder

IMO we should do d) a simple override manager scheme ;-)

Hi Marcel,


> On Apr 5, 2016, at 8:23 AM, marcel.taeumel <[hidden email]> wrote:
>
> Hi Levente,
>
> #releaseActionMap is part of the System package, not Kernel package, where
> Object belongs to.
>
> Unless we decide to tightly couple both packages, we either require "self
> respondsTo:" or an override extension from System to Kernel.

Let's do an override extension from System to Kernel.  Bert, does Monticello do the right thing, and publish Kernel with the overridden method and System with the overriding method, or does it all break, eg if someone condenses changes?

Hi all,

On 05.04.2016, at 22:52, Eliot Miranda <[hidden email]> wrote:

Overrides always have a strange taste for me.
I would rather not have overrides in our most basic packages
like Kernel/System; the override mechanism depends on things like package info (maybe even monticello))
which are not this basic, I think.

What about an empty #release in ProtoObject and an extension in System?

Best
        -Tobias

PS: I also thought about an analogy to #future like that:
        self maybe releaseMap.

>> Unless we decide to tightly couple both packages, we either require "self
>> respondsTo:" or an override extension from System to Kernel.
>
> Or we do a proper job of working out an effective way of doing this. I really hate to see (ab)use of #respondsTo:  like this. Surely it must be slower than simply sending the message

Probably not a discernable performance issue for releasing resources.

I do agree that respondsTo: is nothing to be used liberally, but it
does exist, and there are cases where Smalltalk's ability to
"optionally send a message" is a perfectly simple and appropriate
solution.  It creates no mysteries.

>  - allowing the VM to do its normal fast lookups and caching - and occasionally having to catch a dNU: ?
>
> If that is a practical path, then we need to imagine some simple and comprehensible ways to
> a) catch the dNU and do.. whatever
> b) discover that the catching is needed, which seems like some sneaky package analysis stuff well suited to a PhD student
> c) find a way to use a & b without pissing off the general user/coder

IMO, the above and the other "cures" proposed such as introducing a MC
override are much worse than the "illness" -- this single use of
#respondsTo:.

Squeak 5.0 release was delayed for 2 months because of a crazy package
tangle due to an MC override.  Do we _really_ want to cross that line
from having an override-free system to one with overrides because of
one little optional message in the code?

Forgive me:  ;)

   https://en.wikipedia.org/wiki/Cutting_off_the_nose_to_spite_the_face