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

Re: [Pharo-dev] About abuse of inheritance

by Igor Stasenko

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

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 1 regressions found. KernelTests.Classes.ClassHierarchyTest.testSubclasses

July 22, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 1 regressions found. KernelTests.Classes.ClassHierarchyTest.testSubclasses

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Florin Mateoc

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. A quaternion is a generalization in 4 dimensions, we did not get complex numbers by specializing from quaternions, it was the other way around. Florin

July 22, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linu… 1 regressions found. KernelTests.Classes.ClassHierarchyTest.testSubclasses

July 22, 2013

[update 3.0] #30292

by Marcus Denker

30292 ----- 11211 clean up Watery2 theme https://pharo.fogbugz.com/f/cases/11211 11206 clean up externalInterrupt in old Debugger https://pharo.fogbugz.com/f/cases/11206 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1190.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke…

July 22, 2013

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