About AXAnnouncements (was: some Announcements related questions)

2009/11/1 Lukas Renggli <[hidden email]>:
>> But if it so stripped to bare-bones, then where the benefits to use
>> exactly Announcements?
>
> I would rather like to hear what this "more wide functionality" is all about?
>

i don't know. I just not buying 'use this' because its good. I need to
know why its so good :)
As far as i can see, it is as good as any other observer pattern implementation.
But alone, this pattern is nothing, so we should analyze, how well it
fits for use in different scenarios.
And so, what if such implementation doesn't play well with all
scenarios, would you still insist
to use Announcements instead of making own, given that cost of
implementation is quite small (10 or even less methods)?

> So far you only argued that big is better. I don't buy that.
>
In contrary. An annoucements implies to use separate (sub)classes for
different event kinds.
While i can simply use field in the event to identify its kind.
Lets say you having 50 event kinds. So what is bigger - single class + 1 field,
or 50 classes? Or we not counting classes as a code?

So, as you can see, announcements, in some cases could lead to
'bigger' code bloat.
And i would like to know, why it is still good to use them, despite
the costs of such potential bloat.
yes, good software is one where nothing left to remove, instead
nothing left to add.




--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/1 Igor Stasenko <[hidden email]>:
Just a bit more arguing. :)
Suppose i bought the idea, and created a 50 subclasses. They form some
kind of tree (such as AbstractEvent subclasses).

So far so good. But now i want some of those event kinds to be logged,
while some of them are not.
What annoucements framework could propose for this scenario?
Okay, i can create a new announcement subclass:

Announcement subclass: #LoggedAnnouncement
...

so then any , who would like to subcscibe to logged announcement could
simply do something like:

annoucer on: LoggedAnnouncement do: [:ann | Transcript show: ann message ].

But how i suppose to wire it up with the tree above?
Obviously i can't. Because if i make all of the tree to be a subclass
of LoggedAnnouncement, then all of them
will be logged, while i want only some of them.



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Obviously i can't. Because if i make all of the tree to be a subclass
> of LoggedAnnouncement, then all of them
> will be logged, while i want only some of them.

You are missing the point of announcements: they are not supposed to
do anything, they are only supposed to notify interested parties about
something. It is the sole responsibility of the interested party to
register for announcements. If somebody is interested logging some
announcement, then this interested party should declare that wish. The
announcement itself shouldn't care.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Indeed, the main and only goal of Announcement is to provide an object-
oriented (Exception-like) way to handle notifications.

I have used the Announcements implementation of Lukas on several  
occasions and I did not feel the need for anything else.

You indeed should subclass Announcement for any specific announcement,  
but that is not a drawback, it is a nice feature. If you want to have  
an announcement that you want to identify by a special single field,  
you are free to implement that in one announcement class on top.

Cheers,
Doru


On 1 Nov 2009, at 17:08, Lukas Renggli wrote:

--
www.tudorgirba.com

"Some battles are better lost than fought."




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/1 Lukas Renggli <[hidden email]>: Hmm.. i don't think that i'm missing the point.

Where in this code:

annoucer on: LoggedAnnouncement do: [:ann | Transcript show: ann message ].

you see that i'm putting a responsibility for handling the
announcement on announcement,
instead of subscriber?
Subscriber provides a block, and given that LoggedAnnouncement
implements #message , it simply using it.
But subscriber is free to do anything he likes to in the handler
block, so again, i don't see where i putting any responsibility
on announcement instead of subscriber.

Oh, wait.. you mean that if i want, say 35 out of 50 announcement
kinds to be logged, then
i need to do something like:

logblock := [:announcement | ... ].
announcer on: AnnouncementKind1 do: logblock.
announcer on: AnnouncementKind2 do: logblock.
....
announcer on: AnnouncementKind35 do: logblock.

?
Do you agree that this is far from being short and elegant? Moreover
it imposes dependency from various kinds of events, instead of just
one (LoggedAnnouncement),
and, if i going to change them somehow, i would need to revisit this
code again.. and again.

I used this case to illustrate, that single inheritance , which used
in Annoucements framework not always sufficient.

In this case, it would need to overrride

Announcement class>>handles: anAnnouncementClass
        ^ anAnnouncementClass isKindOf: self

in LoggedAnnouncement , to something like:

LoggedAnnouncement class>>handles: anAnnouncementClass
        ^ anAnnouncementClass isLoggedAnnouncement

and provide a default #isLoggedAnnouncement implementation in
Announcement class.
as well as in any my own classes,  override it to answer true.

So, to implement this scenario i need substantional efforts to be
taken. And already will need to extend Announcement class.



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/1 Tudor Girba <[hidden email]>:
Thanks Doru. Indeed, its a feature, but not a rule which everyone should follow.
In other thread, I had proposed to use field to identify an event type
instead of class, and someone said
that i'm doing it wrong.
While i thinking that the way how the framework identifies events
kinds (by default) not always best one, and as i illustrated its not
good for everything.




--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

    announcer
        on: AnnouncementKind1 , AnnouncementKind2 , ... AnnouncementKind35
        do: logblock

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

you see you find a use of Set :)

Stef

On Nov 1, 2009, at 6:17 PM, Lukas Renggli wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/1 Lukas Renggli <[hidden email]>: good catch.
Still dependency on 35 classes .. while my intent is to subscribe to
all announcements which can be logged.
If i load new package, it could provide more announcements which can be logged.
But i will not be able to see them if i'm going to enumerate them in
such way :(



> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/1 Stéphane Ducasse <[hidden email]>:
> you see you find a use of Set :)
>

IMO, this is a find where you should not use Set :)




--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

At Sun, 1 Nov 2009 19:35:57 +0200,
Igor Stasenko wrote:
  If "can be logged" means to have #canBeLogged method that returns
true, you could also say (given that you provide a default
implementation of #canBeLogged at a/the root):

logblock := [:announcement | announcement canBeLogged ifTrue: [... ]].
announcer on: Announcement do: logblock.

Loading a package with new subclasses of Announcement is not a
problem.  And, a recipient ignoring an announcement that it doesn't
handle is somewhat common, when I used my own implementation for my
projects.

  If you implement an observer pattern to accommodate the new package
loading requirement, what would be the strategy to implement it?

-- Yoshiki

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/1 Yoshiki Ohshima <[hidden email]>: i dont want to nitpick , but since you subscribing to the Announcement class,
this means that you need to put an extension method #canBeLogged into it.

And we started this discussion from question: is Announcements
framework is generic enough
and won't require more coding. But extending it is already means 'more
code'  in base.

> Loading a package with new subclasses of Announcement is not a
> problem.  And, a recipient ignoring an announcement that it doesn't
> handle is somewhat common, when I used my own implementation for my
> projects.
>
>  If you implement an observer pattern to accommodate the new package
> loading requirement, what would be the strategy to implement it?
>
Not necessarily a new package. The problem is, that i don't want to
modify multiple places in system if i reconsider whether something can
be logged or not, as well as i want to be sure that my code will
handle all and any potential changes in future without the need of any
modifications in my code.

I think that this part of discussion can be closed.

Another question , which Stephane noted already, is the overhead of
broadcasting.

In Announcer>>announce:
it iterating over all subscriptions to determine which one may want to
receive an announcement or not.

        subscriptions keysAndValuesDo: [ :class :actions |
                (class handles: announcement)
                        ifTrue: [ actions valueWithArguments: (Array with: announcement) ] ].

but if we can't avoid iteration, then why ASKING but not TELLING to handle it:

        subscriptions do: [ :subscriber | subscriber handle: announcement ].

(subscriptions collection can be just a Set in this case)
and then , a particular subscriber could decide whether he interested
in given announcement or not,
based on own criteria (such as #canBeLogged etc).

And surely, we can provide a subscriber class, which can use the same
logic, to determine if it interested in particular announcement, based
on announcement class.
This could make the whole thing more flexible.

> -- Yoshiki
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Another question , which Stephane noted already, is the overhead of
> broadcasting.

First of all, announcements are magnitudes faster than the ancient
change-update and trigger frameworks.

The problem of broadcasting does not apply to announcements, because
the observer only registers and receives events he is interested in.

Please read the blog posts of Vassily.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Yes after writing that I thought that it was already based on on:send:
so you only broadcast to the person that register.

>> Another question , which Stephane noted already, is the overhead of
>> broadcasting.
>
> First of all, announcements are magnitudes faster than the ancient
> change-update and trigger frameworks.

In VW I would have problem to see why this was that slow especially  
since
they clean the update:/changed: to have exactly on:send:....

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/1 Lukas Renggli <[hidden email]>:
>> Another question , which Stephane noted already, is the overhead of
>> broadcasting.
>
> First of all, announcements are magnitudes faster than the ancient
> change-update and trigger frameworks.
>

i having zero interest in ancient stuff. This topic is about announcements.

> The problem of broadcasting does not apply to announcements, because
> the observer only registers and receives events he is interested in.
>
nope. this problem applies to announcements as well. As soon as you
having multiple subscribers
listening for same event, sending this event to all of them is called
broadcasting.
Please tell me if this definition is wrong.

But in addition, announcer also iterates even over those subscribers
who would never want to receive some announcements.
I thought that Stephane talking about this overhead, not about some
dusty, ancient code which i never seen.

> Please read the blog posts of Vassily.
>

Thanks, i'm already read his blog.



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/1 Igor Stasenko <[hidden email]>:
Igor, even if you open a shiny new Pharo image, I'm afraid you'll have
to contemplate plenty of ancient code.
Note sure the most ancient the most dusty though ;).

FIY, st80 MVC was broadcasting to 99% of ignorers with a long chain of
this kind:
self changed: aSymbol SENT FROM THE MODEL
-> self changed:with:
--> self changed:with:from:
---> update:with:from: BROADCAST IN EACH dependents (each subview was
potentially)
--> update:with:
-> update:

I hope we don't replicate this scheme, I had understood Announcements
did not thanks to explicit subscription.
Anyway, a bit of archeology is always helpfull when cleaning Smalltalk...

Nicolas

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Sun, Nov 01, 2009 at 10:07:59PM +0100, Lukas Renggli wrote:
> > Another question , which Stephane noted already, is the overhead of
> > broadcasting.
>
> First of all, announcements are magnitudes faster than the ancient
> change-update and trigger frameworks.

Is this true? I would expect announcements to be magnitudes faster than
the trigger framework, and similar in performance to change-update.

Dave


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/2 Nicolas Cellier <[hidden email]>: Oh yeah, i seen that code, and Dependents class var in Object class,
which is a dictionary of dictionaries...
This model, as well as morphic extensions, takes roots from Self's
morphic, where you can easily extend
any object state by adding new slots to it. In smalltalk we don't have
dynamic named slots, and thus we
having such ugly crutches :)

> I hope we don't replicate this scheme, I had understood Announcements
> did not thanks to explicit subscription.
> Anyway, a bit of archeology is always helpfull when cleaning Smalltalk...
>

It is strange, i have a feeling that people think i am being
short-sighted or don't understand things,
while i'm trying to show the potentional bottlenecks of Announcements
framework itself...

> Nicolas
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

At Sun, 1 Nov 2009 20:22:48 +0200,
Igor Stasenko wrote:
  Well, I said "if".  And if you really don't want to have an
extension method in the base, you can say something like:

  (announcement instVarNames includes: 'canBeLogged') ifTrue: [...]

or any other ways that don't require an extension method in the core.
The point was that you don't have to have all 35 classes listed upfront.
 
  Ok... But announcement or not, you need a way to tell a notification
"can be logged".

  But the client side code will be more messy.  An object will have
only one implementation of #handle:, and whenever you want to add a
new thing to be handled by the object, it ends up with adding a new if
clauses inside it.

  (Something more flexible and loose-coupling than Announcement would
be really good, I agree.)

-- Yoshiki

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/2 Yoshiki Ohshima <[hidden email]>: yes.
Sure thing.

the #handle: is an entry point, where subscriber could decide what to
do with announcement.
And of course, you can introduce messy testing code if you need. But
its up to you, not up to Announcement framework.
See the difference?
My point is, that #isKindOf: test is not always single one or best
one, which can be used to
test the relevance of announcement to subscriber.

We having a Traits, right?
Now imagine that i could control, whether announcement can be logged or not,
by simply using or not using a trait in my announcement subclasses.
It can be even a trait with no methods, but i can use this information
to check if given announcement is relevant
to my subscriber.
And as result: zero new methods, no extensions to core and very
convenient way to promote announcement to be a logged one.
Just one requirement: give me a way to define own means to check the
relevance to subscriber :)



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project