- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Recommendation for password encryption?

by Henrik Johansen

On Jul 15, 2013, at 10:42 , Mariano Martinez Peck wrote: > Ahh another question, sorry. With this cipher a "salt" would make almost no sense since I already need a key? > or it make sense to put a "salt" together with the string to ecnrypt? > > Thanks No. Salts (and one-way hashed passwords) only make sense when you're the one authenticating login credentials, not when you're the one tasked with providing said credentials. There is *no* good way of securely "remembering" passwords for a client, other than (as Norbert said) restricting access to the place the password is stored using permissions. As such, you could just as well store the password in-image, and keep it in a restricted location/run as separate user with access to that location. Keeping a blowfish key in a separate file, used to decrypt some in-image value to get the actual password, only buys you safety against 1. Someone gaining access to the image, but not the file 2. Reading cleartext passwords from the process memory directly. For 1), it should be obvious that it is mostly a moot point, if you place the image in a similarly restricted location anyways. For 2), I *think*, no modern OS lets you read another users process' memory (on purpose *) unless they have root access/logged in as same user, in which case, well, you're already screwed. Sure, there might be exploitable bugs that lets an attacker read memory of other processes, but such usually have a high fix-priority. It also means, in order to never end up keeping the plaintext password in memory for prolonged durations (and vulnerable to being read), you have to re-read the file every time you provide the password, so the image must be run as a user with access to the files location anyways. A usable alternative exists if you already use client-side credentials for your app, provided manually when a user signs in. Then, in addition to salt + hashed password value for your users, you can store the db-passwords encrypted with a symmetric cipher (like blowfish) using the users password as key. At login time, after authenticating, you then also decrypt the db-passwords, and keep them available while the application runs. This of course, is still vulnerable to potential memory dumps, but you never store the passwords in an easily reversible form if an attacker ever gains access to the files. If introduced to an existing application , it also means you'd have to keep the db-passwords around in plantext for awhile, to create encrypted values for users on first login (if non-existing), after that passwords should already be available in memory for calculation of new encrypted values when changing passwords/ adding new users. (due to those being allowed to do so, being logged in already) If it's a non-deployed app, the encrypted value for some super-user can be calculated before deployment, and the data required to decrypt the db-passwords never kept on disk in production. Cheers, Henry

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Igor Stasenko

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. > Florin > > > > On 7/22/2013 7:40 AM, Tudor Girba 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, the only real difference being the > case of the Announcer (and even there, the difference is more philosophical > in nature). > > Would it be Ok to call it a day and move on? :) > > 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" > > -- Best regards, Igor Stasenko.

July 22, 2013

Re: [Pharo-dev] opal bug with the old debugger

by Andrei Vasile Chis

Done. https://pharo.fogbugz.com/default.asp?11210 On Sat, Jul 20, 2013 at 11:09 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jul 19, 2013, at 5:10 PM, Andrei Vasile Chis < > chisvasileandrei(a)gmail.com> wrote: > > Just noticed that the second bug also appears in the new debugger. > To reproduce execute (with either debugger) while debugging add a message > send > to a method that does not exist, step into that message send and then > choose to create > the method. After you created you'll get: UndefinedObject(Object)>> > doesNotUnderstand: #debugHighlightRange > > Can you add a bug tracker entry? > > Marcus > >

July 22, 2013

Re: [Pharo-dev] [update 3.0] #30290

by Goubier Thierry

I've started a backport to 2.0 for this one: https://pharo.fogbugz.com/f/cases/11209/backport-2-0-Add-RPackageSet-cache It makes loading significantly faster. Thierry Le 22/07/2013 13:55, Tudor Girba a Ã©crit : > Wow! > > Doru > > > On Mon, Jul 22, 2013 at 12:53 PM, Martin Dias <tinchodias(a)gmail.com > <mailto:tinchodias@gmail.com>> wrote: > > Note this change improved a lot the loading time of Monticello > packages in general. > > The bench showed 3x speed-up loading Pier3 (from more than 10 minutes > to less than 4 minutes!) > > Thanks Esteban! > > MartÃn > > > On Mon, Jul 22, 2013 at 9:42 AM, Marcus Denker > <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > 30290 > > ----- > > > > 10393 Add RPackageSet cache > > https://pharo.fogbugz.com/f/cases/10393 > > > > > > Diff information: > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-Core-MarcusDenker.24… > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-MarcusDenker.839.d… > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Metacello-Platform.pharo20-Ma… > > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Florin Mateoc

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. Florin On 7/22/2013 7:40 AM, Tudor Girba 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, > the only real difference being the case of the Announcer (and even there, the difference is more philosophical in nature). > > Would it be Ok to call it a day and move on? :) > > Cheers, > Doru > > > > > On Mon, Jul 22, 2013 at 1:05 PM, Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: > > On 21 July 2013 20:21, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > 2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@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 <http://www.tudorgirba.com> > > "Every thing has its own flow"

July 22, 2013

[update 3.0] #30291

by Marcus Denker

30291 ----- 4533 UIThemeWatery and UIThemeWatery2 should be merged... https://pharo.fogbugz.com/f/cases/4533 11207 clean up some dead code in FileContentsBrowser https://pharo.fogbugz.com/f/cases/11207 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1189.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke…

July 22, 2013

Re: [Pharo-dev] [update 3.0] #30290

by Tudor Girba

Wow! Doru On Mon, Jul 22, 2013 at 12:53 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Note this change improved a lot the loading time of Monticello > packages in general. > > The bench showed 3x speed-up loading Pier3 (from more than 10 minutes > to less than 4 minutes!) > > Thanks Esteban! > > MartÃn > > > On Mon, Jul 22, 2013 at 9:42 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > 30290 > > ----- > > > > 10393 Add RPackageSet cache > > https://pharo.fogbugz.com/f/cases/10393 > > > > > > Diff information: > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-Core-MarcusDenker.24… > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-MarcusDenker.839.d… > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Metacello-Platform.pharo20-Ma… > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

July 22, 2013

Re: [Pharo-dev] [NB]: Review & fixes & ideas

by Henrik Johansen

On Jul 13, 2013, at 7:23 , Igor Stasenko wrote: > On 13 July 2013 14:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> what are the pros and cons? >> > pros - you can pass is as parameter everywhere it expects a pointer > cons - it will slow down all calls with pointer type because of extra check, > even if you don't using it (and in most cases you don't) > > i think best way is to introduce it as option. I think there's an -optNoChecks or something already? IMHO, it's would be nice to basically treat them as asserts; leave them on by default, then have a system-wide switch in case you want to disable them for production and gain some performance at the risk of crashes rather than failures in case of running into untested incorrect usage. (Optionally with an added -optForceChecks in case you write code that depends on an error being thrown for incorrectly passed typesâ¦ though that shouldn't really happen) Cheers, Henry PS: Sadly, summer in Norway has seen the best weather in ages :D

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Tudor Girba

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, the only real difference being the case of the Announcer (and even there, the difference is more philosophical in nature). Would it be Ok to call it a day and move on? :) 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 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.

July 22, 2013