__storm_remove__ should be called when an object is removed from a store

[Jamu Kakar]

I have a problem that is handled well with reference counting. When
an object is created it increments a reference count and when it's
removed it decrement the reference count. Having __storm_remove__
would be a nice way to deal with the decrement part of this problem.

[Gustavo Niemeyer (niemeyer)]

Hey Jamu!

What are the exact semantics you'd expect for the method?

If the method is called when the object is removed from the Store, I'm
afraid people might use it in place of triggers, which is dangerous
considering that this "trigger" only is called when the object is effectively
in memory (e.g., and not when store.find().remove() is used). If the
method is called when the object is deallocated, then wouldn't __del__
be more appropriate?

[Jamu Kakar (jkakar)]

The example I have is with code that checks an invitation:

class Invitation(object):

    def __init__(self):
        raise_event(InvitiationCreated)

    def accept(self):
        # Perform logic to accept invitation.
        Store.of(self).remove()
        raise_event(InvitiationRemoved)

    def reject(self):
        Store.of(self).remove()
        raise_event(InvitiationRemoved)

I know that Invitation's will only ever be removed from a store by
having their accept or reject method called. The purpose of this
bug is to make this possible:

class Invitation(object):

    def __init__(self):
        raise_event(InvitiationCreated)

    def __storm_remove__(self):
        raise_event(InvitiationRemoved)

    def accept(self):
        # Perform logic to accept invitation.
        Store.of(self).remove()

    def reject(self):
        Store.of(self).remove()

I hadn't thought of the coherency issue you mention, because it isn't
something that would ever happen in the case I have, but I can see that being
a big enough problem to avoid providing the feature.

[Stuart Bishop (stub)]

Seems to be agreement this is not a desirable feature.