July 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Monticello deleting all code

by Norbert Hartl

Opps, sorry, I was too shocked to give proper information The image is a #20599. And I was using the latest pharo vm. Norbert Am 22.07.2013 um 17:46 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > that sounds evil... > which pharo version? > > On 2013-07-22, at 17:44, Norbert Hartl <norbert(a)hartl.name> wrote: >> I've discovered a strange effect. I don't know why it happened but I want to save a modified package to a repository but looking at the "changed" in monticello it showed every class and method has been deleted. That is not true because the code is still there. Saving the package indeed removed everything for the monticello package. So my image was fine but loading the new package again removed all the code. >> >> Any ideas what might have gone wrong here? Or any ideas for a recheck of changes? >> >> Norbert > >

July 22, 2013

Re: [Pharo-dev] Monticello deleting all code

by Camillo Bruni

that sounds evil... which pharo version? On 2013-07-22, at 17:44, Norbert Hartl <norbert(a)hartl.name> wrote: > I've discovered a strange effect. I don't know why it happened but I want to save a modified package to a repository but looking at the "changed" in monticello it showed every class and method has been deleted. That is not true because the code is still there. Saving the package indeed removed everything for the monticello package. So my image was fine but loading the new package again removed all the code. > > Any ideas what might have gone wrong here? Or any ideas for a recheck of changes? > > Norbert

July 22, 2013

Monticello deleting all code

by Norbert Hartl

I've discovered a strange effect. I don't know why it happened but I want to save a modified package to a repository but looking at the "changed" in monticello it showed every class and method has been deleted. That is not true because the code is still there. Saving the package indeed removed everything for the monticello package. So my image was fine but loading the new package again removed all the code. Any ideas what might have gone wrong here? Or any ideas for a recheck of changes? Norbert

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Paul Davidowitz

Stephane Ducasse had responded: > What is all api of Announcer? Announcer allSelectors But I would surely hope that private methods would be excluded from the API. Or being that privacy is (unfortunately) not enforced by the system, there is no such practical notion? - Paul

July 22, 2013

[update 3.0] #30293

by Marcus Denker

30293 ----- 11215 EyeInspector>>selectedElement fails when selectedIndex=0 and the list is empty https://pharo.fogbugz.com/f/cases/11215 11199 CodeCritics browser cannot be opened any more. https://pharo.fogbugz.com/f/cases/11199 11214 Fix for Theme Watery https://pharo.fogbugz.com/f/cases/11214 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.216… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.4… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-CriticBrowser-Marcus…

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by H. Hirzel

On 7/22/13, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I love this debate, but given the energy it attracted, I now apologize to > have fueled it. > > By reading the thread, I believe that everyone involved in the discussion > is on the same page on 99.9% of the cases, +1 the only real difference being > the case of the Announcer (and even there, the difference is more > philosophical in nature). +1 > > Would it be Ok to call it a day and move on? :) +1 > > Cheers, > Doru > > > > > On Mon, Jul 22, 2013 at 1:05 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 21 July 2013 20:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> > 2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> >> >> Interesting how many people in this list think that "Announcer >> >> subclass: >> >> #TxEditor" provides special implementation of announcer named >> >> TxEditor? >> >> >> >> >> >> Many >> >> this is composition using inheritance and inheritance should not be >> >> used >> >> like that. >> >> >> >> Announcer subclass: #GreedyAnnouncer >> >> >> >> Announcer subclass: #RemoteAnnouncer >> > >> > >> > And if we prefer composition we should not implement such kind of >> hierarchy. >> > We should implement GreadySubscriptionsRegistry, >> RemoteSubscriptionsRegistry >> > or AsynchSubscriptionsRegistry and reuse existed Announcer. All >> subscribing >> > and delivering logic implemented by subscription registry. Announcer is >> just >> > simple delegator with convenient api to create Subscription instances: >> > >> > Announcer>>subscribe: anAnnouncementClass do: aValuable >> > "Declare that when anAnnouncementClass is raised, aValuable is >> > executed." >> > ^ registry add: ( >> > AnnouncementSubscription new >> > announcer: self; >> > announcementClass: anAnnouncementClass; >> > valuable: aValuable) >> > >> > >> > Announcer>>announce: anAnnouncement >> > >> > | announcement | >> > announcement := anAnnouncement asAnnouncement. >> > registry ifNotNil: [ >> > registry deliver: announcement >> > ]. >> > ^ announcement >> > >> > All magic happens inside #add: and #deliver: methods of >> > SubscriptionsRegistry. >> > >> > Also announcements framework provides very nice feature: you can have >> > announcer as last argument of event handler selector (that's why >> > AnnouncementSubscription contains reference to announcer instance): >> > >> > announcer on: MyEvent send: #handleAnnouncement:raisedBy: to: >> > aSubscriber >> > >> > Without subclassing YourEventsSource from Announcer you will not have >> such >> > feature. Or you will need implement complex subscription method inside >> > YourEventSource which will delegates special event handler to its >> announcer >> > >> >> 1. you don't need separate class to represent event source. >> it can be any object which does: >> >> announcer announce: Foo. >> >> in any place.. >> I do not see any practical gains from forming a separate class for this >> role. >> It is barely formalizeable because the way how users creating and >> triggering events is arbitrary. >> >> 2. SubscriptionRegistry is an implementation detail. It is private. It >> is a way how Announcer >> doing things inside. It should be no concern of anything outside to >> consider what it does. >> You won't find this class in VisualWorks implementation, for instance. >> >> 3. again, event source - is any object which says 'announcer announce: >> ...' >> It is NOT announcer, because announcer is an event dispatcher. >> dispatcher ~= source >> Is it so hard to see a difference? >> >> When you subclass from Announcer, is that you want to say: >> >> 'self announce:' , so the very same object acts both as event source >> and event dispatcher. >> >> But then , as Stef said, by subclassing you inheriting API. >> So, what prevents me from writing following code, in my own class, >> which uses your domain object >> in a following way: >> >> coolDomainObject := YourDomainObjectWhichInheritsFromAnnouncer new. >> >> coolDomainObject on: Foo do: #bar. >> coolDomainObject announce: Foo. >> >> That i guess is not something you expected, huh? But why not? >> As long as your object understand this protocol, and as long as you >> don't overriding original behavior of Announcer, >> i can abuse your object in a way you did not expected. >> And this is a consequence of violating principle of least authority. >> >> Because once you declare that we're free to use subclassing for any >> purpose, >> then, i can declare: i am free to use any subclass of Announcer as >> announcer for myself. >> >> Lets write random code, do not follow any rules and everyone will be >> happy. >> >> --- >> Best regards, >> Igor Stasenko. >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Igor Stasenko

On 22 July 2013 16:52, Florin Mateoc <fmateoc(a)gmail.com> wrote: > Forget about quaternions! Are you really saying: specialization good, > generalization bad?!!! Well, at least in this case, your generalization is > indeed a bad one :) > > Generalization and specialization are duals of each other. We can do stupid > specializations just as easily as we can do stupid generalizations. Let's > take you example. Postman subclass: > PostmanWhoAlsoDeliversPizzasAndFliesToTheMoon is a specialization, not a > generalization. How is it any better? > > uh? Generalization is good. but you don't achieving it by subclassing. And that's exactly what i was pointing out: subclassing is intended for specialization, but not for generalization. And when you subclass for generalization you doing exactly what i am against. > > > On Mon, Jul 22, 2013 at 10:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 22 July 2013 16:23, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > Because the quaternion (ar + ai * i + 0 * j + 0 * k) will behave exactly >> > like a complex (ar + ai * i) with respect to arithmetic (+ - * /) and >> > elementary functions (exp sin cos etc...). >> > >> all i know is that >> >> i*i = -1 >> >> that's what makes complex numbers quite different from other >> n-dimensional vector(s). >> and i never seen that you can mix complex algebra and linear algebra.. >> hence, i can imagine that you can subclass both from some abstract >> NDimensionalVector >> but not subclass one from another, because it makes no sense. >> >> >> > >> > 2013/7/22 Igor Stasenko <siguctua(a)gmail.com> >> >> >> >> On 22 July 2013 15:13, Florin Mateoc <fmateoc(a)gmail.com> wrote: >> >> > On 7/22/2013 8:44 AM, Igor Stasenko wrote: >> >> >> On 22 July 2013 14:13, Florin Mateoc <fmateoc(a)gmail.com> wrote: >> >> >>> I also liked the debate, so before it closes I want to throw my 2 >> >> >>> cents in: >> >> >>> >> >> >>> I don't think this is an issue about inheritance (vs composition), >> >> >>> it >> >> >>> is one >> >> >>> about multiple inheritance or lack thereof. You may want your >> >> >>> object >> >> >>> to be >> >> >>> an announcer of events, but almost always you will also want it to >> >> >>> be >> >> >>> something else as well. To me this suggests that Announcer should >> >> >>> be a >> >> >>> trait, not a class, so in a sense, indeed, you would "compose" your >> >> >>> classes >> >> >>> using it, but you would use trait composition instead of class >> >> >>> composition. >> >> >>> In VisualAge there is a huge hierarchy underneath >> >> >>> AbtObservableObject. >> >> >>> Sure, >> >> >>> there are many classes that want to participate in an observable >> >> >>> pattern, >> >> >>> but you should not be forced to inherit from a particular class in >> >> >>> order to >> >> >>> do that, so that is just another related example that would have >> >> >>> benefited >> >> >>> from traits. >> >> >>> >> >> >> Again, announcer of events means event source role. >> >> >> It is distinct from 'delivery service' role. >> >> >> >> >> >> When you write mail, you just drop it into mailbox, and then mr. >> >> >> Postman delivers it to receiver, >> >> >> but not directly yourself. >> >> >> That's what you get from specialization. >> >> >> But if you wanna play as mr. Postman, and also will deliver pizzas, >> >> >> and fly to the moon, >> >> >> this is called generalization, and straightly opposite to >> >> >> specialization. >> >> >> >> >> >> >> >> > >> >> > So what? The thing is, you want to do both. We think in both >> >> > directions. >> >> > Sometimes we generalize from the existing >> >> > knowledge, sometimes we specialize from the abstract. >> >> >> >> I say you what. If you go to extreme, then your object can do >> >> everything.. and so you end up with code like this everywhere: >> >> >> >> self foo: self bar with: self zork. >> >> >> >> Because your object knows everything, can do everything and don't >> >> needs anything. >> >> The only question which remains is why you using object-oriented >> >> language >> >> then? >> >> Why using classes, caring about inheritance, polymorphism , message >> >> passing etc, because >> >> if single object does all you need, you don't need all of above. >> >> >> >> My point is that if you don't need such concepts, just don't use >> >> them.. but if you using them, >> >> then please follow the rules. >> >> >> >> Same goes to Announcer. It defines the certain way how it should be >> >> used. And how its not. >> >> >> >> > A quaternion is a generalization in 4 dimensions, we did not get >> >> > complex >> >> > numbers by specializing from quaternions, it >> >> > was the other way around. >> >> > >> >> >> >> hmm? how that? i first time hear that they are related. >> >> Can you provide a real example where you can mix both of them >> >> interchangeably? >> >> Besides the fact that they both are partial case of n-dimentional >> >> vectors, they not sharing too much, >> >> because of different math and different uses. >> >> >> >> But anyways.. it seems like Announcement(s) model, to my thinking >> >> don't really fits well with >> >> observer pattern. >> >> Because in observer pattern you need only 2 roles: observer(s) and >> >> subject. >> >> You don't have nor need a mediator or 'event dispatcher', which >> >> represented by announcer. >> >> >> >> Implementing an observer pattern using Announcer is an overkill, to my >> >> thinking. >> >> Reflecting by your example, is like using quaternions where complex >> >> numbers is sufficient. >> >> >> >> I think more and more, in this regard, that Announcements is not a >> >> silver bullet and it has own limits >> >> and intended ways to use. >> >> For that matter, i think we should have more simple and elegant >> >> solution. >> >> Because subclassing from Announcer is not a solution. >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Florin Mateoc

Forget about quaternions! Are you really saying: specialization good, generalization bad?!!! Well, at least in this case, your generalization is indeed a bad one :) Generalization and specialization are duals of each other. We can do stupid specializations just as easily as we can do stupid generalizations. Let's take you example. Postman subclass: PostmanWhoAlsoDeliversPizzasAndFliesToTheMoon is a specialization, not a generalization. How is it any better? On Mon, Jul 22, 2013 at 10:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 22 July 2013 16:23, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Because the quaternion (ar + ai * i + 0 * j + 0 * k) will behave exactly > > like a complex (ar + ai * i) with respect to arithmetic (+ - * /) and > > elementary functions (exp sin cos etc...). > > > all i know is that > > i*i = -1 > > that's what makes complex numbers quite different from other > n-dimensional vector(s). > and i never seen that you can mix complex algebra and linear algebra.. > hence, i can imagine that you can subclass both from some abstract > NDimensionalVector > but not subclass one from another, because it makes no sense. > > > > > > 2013/7/22 Igor Stasenko <siguctua(a)gmail.com> > >> > >> On 22 July 2013 15:13, Florin Mateoc <fmateoc(a)gmail.com> wrote: > >> > On 7/22/2013 8:44 AM, Igor Stasenko wrote: > >> >> On 22 July 2013 14:13, Florin Mateoc <fmateoc(a)gmail.com> wrote: > >> >>> I also liked the debate, so before it closes I want to throw my 2 > >> >>> cents in: > >> >>> > >> >>> I don't think this is an issue about inheritance (vs composition), > it > >> >>> is one > >> >>> about multiple inheritance or lack thereof. You may want your object > >> >>> to be > >> >>> an announcer of events, but almost always you will also want it to > be > >> >>> something else as well. To me this suggests that Announcer should > be a > >> >>> trait, not a class, so in a sense, indeed, you would "compose" your > >> >>> classes > >> >>> using it, but you would use trait composition instead of class > >> >>> composition. > >> >>> In VisualAge there is a huge hierarchy underneath > AbtObservableObject. > >> >>> Sure, > >> >>> there are many classes that want to participate in an observable > >> >>> pattern, > >> >>> but you should not be forced to inherit from a particular class in > >> >>> order to > >> >>> do that, so that is just another related example that would have > >> >>> benefited > >> >>> from traits. > >> >>> > >> >> Again, announcer of events means event source role. > >> >> It is distinct from 'delivery service' role. > >> >> > >> >> When you write mail, you just drop it into mailbox, and then mr. > >> >> Postman delivers it to receiver, > >> >> but not directly yourself. > >> >> That's what you get from specialization. > >> >> But if you wanna play as mr. Postman, and also will deliver pizzas, > >> >> and fly to the moon, > >> >> this is called generalization, and straightly opposite to > >> >> specialization. > >> >> > >> >> > >> > > >> > So what? The thing is, you want to do both. We think in both > directions. > >> > Sometimes we generalize from the existing > >> > knowledge, sometimes we specialize from the abstract. > >> > >> I say you what. If you go to extreme, then your object can do > >> everything.. and so you end up with code like this everywhere: > >> > >> self foo: self bar with: self zork. > >> > >> Because your object knows everything, can do everything and don't > >> needs anything. > >> The only question which remains is why you using object-oriented > language > >> then? > >> Why using classes, caring about inheritance, polymorphism , message > >> passing etc, because > >> if single object does all you need, you don't need all of above. > >> > >> My point is that if you don't need such concepts, just don't use > >> them.. but if you using them, > >> then please follow the rules. > >> > >> Same goes to Announcer. It defines the certain way how it should be > >> used. And how its not. > >> > >> > A quaternion is a generalization in 4 dimensions, we did not get > complex > >> > numbers by specializing from quaternions, it > >> > was the other way around. > >> > > >> > >> hmm? how that? i first time hear that they are related. > >> Can you provide a real example where you can mix both of them > >> interchangeably? > >> Besides the fact that they both are partial case of n-dimentional > >> vectors, they not sharing too much, > >> because of different math and different uses. > >> > >> But anyways.. it seems like Announcement(s) model, to my thinking > >> don't really fits well with > >> observer pattern. > >> Because in observer pattern you need only 2 roles: observer(s) and > >> subject. > >> You don't have nor need a mediator or 'event dispatcher', which > >> represented by announcer. > >> > >> Implementing an observer pattern using Announcer is an overkill, to my > >> thinking. > >> Reflecting by your example, is like using quaternions where complex > >> numbers is sufficient. > >> > >> I think more and more, in this regard, that Announcements is not a > >> silver bullet and it has own limits > >> and intended ways to use. > >> For that matter, i think we should have more simple and elegant > solution. > >> Because subclassing from Announcer is not a solution. > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Igor Stasenko

On 22 July 2013 16:23, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Because the quaternion (ar + ai * i + 0 * j + 0 * k) will behave exactly > like a complex (ar + ai * i) with respect to arithmetic (+ - * /) and > elementary functions (exp sin cos etc...). > all i know is that i*i = -1 that's what makes complex numbers quite different from other n-dimensional vector(s). and i never seen that you can mix complex algebra and linear algebra.. hence, i can imagine that you can subclass both from some abstract NDimensionalVector but not subclass one from another, because it makes no sense. > > 2013/7/22 Igor Stasenko <siguctua(a)gmail.com> >> >> On 22 July 2013 15:13, Florin Mateoc <fmateoc(a)gmail.com> wrote: >> > On 7/22/2013 8:44 AM, Igor Stasenko wrote: >> >> On 22 July 2013 14:13, Florin Mateoc <fmateoc(a)gmail.com> wrote: >> >>> I also liked the debate, so before it closes I want to throw my 2 >> >>> cents in: >> >>> >> >>> I don't think this is an issue about inheritance (vs composition), it >> >>> is one >> >>> about multiple inheritance or lack thereof. You may want your object >> >>> to be >> >>> an announcer of events, but almost always you will also want it to be >> >>> something else as well. To me this suggests that Announcer should be a >> >>> trait, not a class, so in a sense, indeed, you would "compose" your >> >>> classes >> >>> using it, but you would use trait composition instead of class >> >>> composition. >> >>> In VisualAge there is a huge hierarchy underneath AbtObservableObject. >> >>> Sure, >> >>> there are many classes that want to participate in an observable >> >>> pattern, >> >>> but you should not be forced to inherit from a particular class in >> >>> order to >> >>> do that, so that is just another related example that would have >> >>> benefited >> >>> from traits. >> >>> >> >> Again, announcer of events means event source role. >> >> It is distinct from 'delivery service' role. >> >> >> >> When you write mail, you just drop it into mailbox, and then mr. >> >> Postman delivers it to receiver, >> >> but not directly yourself. >> >> That's what you get from specialization. >> >> But if you wanna play as mr. Postman, and also will deliver pizzas, >> >> and fly to the moon, >> >> this is called generalization, and straightly opposite to >> >> specialization. >> >> >> >> >> > >> > So what? The thing is, you want to do both. We think in both directions. >> > Sometimes we generalize from the existing >> > knowledge, sometimes we specialize from the abstract. >> >> I say you what. If you go to extreme, then your object can do >> everything.. and so you end up with code like this everywhere: >> >> self foo: self bar with: self zork. >> >> Because your object knows everything, can do everything and don't >> needs anything. >> The only question which remains is why you using object-oriented language >> then? >> Why using classes, caring about inheritance, polymorphism , message >> passing etc, because >> if single object does all you need, you don't need all of above. >> >> My point is that if you don't need such concepts, just don't use >> them.. but if you using them, >> then please follow the rules. >> >> Same goes to Announcer. It defines the certain way how it should be >> used. And how its not. >> >> > A quaternion is a generalization in 4 dimensions, we did not get complex >> > numbers by specializing from quaternions, it >> > was the other way around. >> > >> >> hmm? how that? i first time hear that they are related. >> Can you provide a real example where you can mix both of them >> interchangeably? >> Besides the fact that they both are partial case of n-dimentional >> vectors, they not sharing too much, >> because of different math and different uses. >> >> But anyways.. it seems like Announcement(s) model, to my thinking >> don't really fits well with >> observer pattern. >> Because in observer pattern you need only 2 roles: observer(s) and >> subject. >> You don't have nor need a mediator or 'event dispatcher', which >> represented by announcer. >> >> Implementing an observer pattern using Announcer is an overkill, to my >> thinking. >> Reflecting by your example, is like using quaternions where complex >> numbers is sufficient. >> >> I think more and more, in this regard, that Announcements is not a >> silver bullet and it has own limits >> and intended ways to use. >> For that matter, i think we should have more simple and elegant solution. >> Because subclassing from Announcer is not a solution. >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Nicolas Cellier

Because the quaternion (ar + ai * i + 0 * j + 0 * k) will behave exactly like a complex (ar + ai * i) with respect to arithmetic (+ - * /) and elementary functions (exp sin cos etc...). 2013/7/22 Igor Stasenko <siguctua(a)gmail.com> > On 22 July 2013 15:13, Florin Mateoc <fmateoc(a)gmail.com> wrote: > > On 7/22/2013 8:44 AM, Igor Stasenko wrote: > >> On 22 July 2013 14:13, Florin Mateoc <fmateoc(a)gmail.com> wrote: > >>> I also liked the debate, so before it closes I want to throw my 2 > cents in: > >>> > >>> I don't think this is an issue about inheritance (vs composition), it > is one > >>> about multiple inheritance or lack thereof. You may want your object > to be > >>> an announcer of events, but almost always you will also want it to be > >>> something else as well. To me this suggests that Announcer should be a > >>> trait, not a class, so in a sense, indeed, you would "compose" your > classes > >>> using it, but you would use trait composition instead of class > composition. > >>> In VisualAge there is a huge hierarchy underneath AbtObservableObject. > Sure, > >>> there are many classes that want to participate in an observable > pattern, > >>> but you should not be forced to inherit from a particular class in > order to > >>> do that, so that is just another related example that would have > benefited > >>> from traits. > >>> > >> Again, announcer of events means event source role. > >> It is distinct from 'delivery service' role. > >> > >> When you write mail, you just drop it into mailbox, and then mr. > >> Postman delivers it to receiver, > >> but not directly yourself. > >> That's what you get from specialization. > >> But if you wanna play as mr. Postman, and also will deliver pizzas, > >> and fly to the moon, > >> this is called generalization, and straightly opposite to > specialization. > >> > >> > > > > So what? The thing is, you want to do both. We think in both directions. > Sometimes we generalize from the existing > > knowledge, sometimes we specialize from the abstract. > > I say you what. If you go to extreme, then your object can do > everything.. and so you end up with code like this everywhere: > > self foo: self bar with: self zork. > > Because your object knows everything, can do everything and don't > needs anything. > The only question which remains is why you using object-oriented language > then? > Why using classes, caring about inheritance, polymorphism , message > passing etc, because > if single object does all you need, you don't need all of above. > > My point is that if you don't need such concepts, just don't use > them.. but if you using them, > then please follow the rules. > > Same goes to Announcer. It defines the certain way how it should be > used. And how its not. > > > A quaternion is a generalization in 4 dimensions, we did not get complex > numbers by specializing from quaternions, it > > was the other way around. > > > > hmm? how that? i first time hear that they are related. > Can you provide a real example where you can mix both of them > interchangeably? > Besides the fact that they both are partial case of n-dimentional > vectors, they not sharing too much, > because of different math and different uses. > > But anyways.. it seems like Announcement(s) model, to my thinking > don't really fits well with > observer pattern. > Because in observer pattern you need only 2 roles: observer(s) and subject. > You don't have nor need a mediator or 'event dispatcher', which > represented by announcer. > > Implementing an observer pattern using Announcer is an overkill, to my > thinking. > Reflecting by your example, is like using quaternions where complex > numbers is sufficient. > > I think more and more, in this regard, that Announcements is not a > silver bullet and it has own limits > and intended ways to use. > For that matter, i think we should have more simple and elegant solution. > Because subclassing from Announcer is not a solution. > > > -- > Best regards, > Igor Stasenko. > >

July 22, 2013