- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Don't want to see a particular notification

by Damien Cassou

On Sun, Jul 21, 2013 at 10:18 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > SmalltalkImage checkChangesFileAvailability: false. Thank you Norbert, but this method does not exist -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by Denis Kudriashov

2013/7/21 Igor Stasenko <siguctua(a)gmail.com> > Yes, but where are the guarantees that you don't? > Just think from outsider's point of view: when he sees > > Announcer subclass: #Foo > > what he will think first: > - aha, this guy implements own kind of announcer > or > - aha this guy reusing announcer > or > - aha, this guy doing both things at the same time (a worst possible > alternative) > > and how many abuses like that, he should see before making a logical > conclusion: > - aha.. this is the way how i should do as well. > Interesting how many people in this list think that "Announcer subclass: #TxEditor" provides special implementation of announcer named TxEditor? Because to me it is not practical design issues when we talk about subclassing Announcer.

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by Denis Kudriashov

Hi Igor. 2013/7/21 Igor Stasenko <siguctua(a)gmail.com> > There are 3 kinds of roles in context: > > - subscriber: an object who subscribing for events to receive them later > - an event source (the object which announces the event) > - an announcer, an object which provides subscription service and > through which you can announce events, acting as mediator between 2 > parties above > > > the rest, like registry, Announcement (as class) and subscriptions is > implementation detail. > The main reason for using Announcements model is to have decoupling > between event source (the place/object , which producing events) and > its handlers. And announcer provides such decoupling. > I understand your position. But I think it is too little and simple place to introduce another object. And original paper about Announcements framework (maybe from Vasiliy Bykov) not described such distinction between event source and announcer as subscription service. Too me subscription service is exactly SubscriptionsRegistry. Interesting how Announcer used in VisualWorks system. Any way if we agree with your proposals we should add EventsSource class (choose better name) to Announcements package. And we should describe it in announcements chapter in pharo book. Because now there are no documentation where your distinction are explained and that's why now natural way to make event source classes is subclassing Announcer. Best regards, Denis

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by StÃ©phane Ducasse

On Jul 21, 2013, at 2:38 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Yes, but where are the guarantees that you don't? > Just think from outsider's point of view: when he sees > > Announcer subclass: #Foo > > what he will think first: > - aha, this guy implements own kind of announcer > or > - aha this guy reusing announcer + 1 Stef

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by Igor Stasenko

On 20 July 2013 21:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > Thanks for taking the time to write such a long answer. > > I think you misunderstood my point :). I simply said that the two examples > are not the same (and I can add now that "Butter subclass: #Fridge" is as > bad as "Shampoo subclass: #Shower", but they are both different from > "Announcer subclass: #MyDomainConcept"). > It is only in your mind. If someone else will look at your code, he won't make any difference (and you can tell me why ;). And that is what matters. You know, i can also (ab)use things in my code and make very strange things, which can be understood only by me.. depending on intent, like having highly optimized code or as a way to code less (making many subclasses can be tiresome sometimes ;) But if there's any chance that anyone else will use this code or will need to change/understand/improve it, i would not do that. Because when i do, i putting them into misery. > As I understand, you conceded the point that inheriting from Object has > reuse reasons, but that it is so because Object provides generic mechanisms > that everyone wants. I can imagine scenarios where I want a different > reflection support. All of a sudden the generic mechanism is not so generic > anymore, and you get in the same situation as the one of wanting a different > Announcer kind. Does it mean that inheriting from Object is a bad thing? No. > It is a great good enough compromise for 99.9% of the cases. > > Then you say that Announcer is not in the Object protocol as if this would > be necessarily a good thing. I can argue that every Object should have > announcer capabilities just like it has exception handling capabilities, but > then we would go even further away from the main point :). > Not at all, i also think that having a generic way for any object to act as event source is quite valuable. That's why, there is already existing protocols for that (see events-blah categories). And dependents mechanism. And that's why we want to eventually unify them.. because there's too many. > Inheritance as reuse is definitely to be avoided, and indeed the principle > of Least Authority (or more known as Principle of Least Privilege) is a > relevant point (I concede that :)). However, I guess you agree that having > #class defined in Object is not a horrible (it can be better, but it is not > horrible) thing even if most objects do not need this information. > > Another principle that might be more useful when thinking about inheritance > is the Liskov Substitution Principle. From this point of view, as long as > MyDomainConcept does not redefine the meaning of Announcer, it is not > unreasonable to have it inherit from Announcer. > Yes, but where are the guarantees that you don't? Just think from outsider's point of view: when he sees Announcer subclass: #Foo what he will think first: - aha, this guy implements own kind of announcer or - aha this guy reusing announcer or - aha, this guy doing both things at the same time (a worst possible alternative) and how many abuses like that, he should see before making a logical conclusion: - aha.. this is the way how i should do as well. > I stop now. You can continue to shoot :). > -- Best regards, Igor Stasenko.

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by Igor Stasenko

On 20 July 2013 12:48, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi > > 2013/7/19 Igor Stasenko <siguctua(a)gmail.com> >> >> So, on your place, if you really need a lot of classes with announcer >> capabilities, you can do it like that: >> >> Object subclass: #ObjectWithAnnouncer >> instvars: 'announcer' >> > > ObjectWithAnnouncer is exactly what I think about Announcer. I just need > class which makes my objects events sources. And I'm wondering why Announcer > is bad for this? > Just look at Announcer definition: > > Object subclass: #Announcer > > instanceVariableNames: 'registry' > > classVariableNames: '' > > poolDictionaries: '' > > category: 'Announcements-Core' > > > "registry" variable is instance of SubscriptionsRegistry which actually > implements all announcements logic. Announcer just adds convenient public > api to events subscriptions and delivering. No complex logic. No actual > knowledge about how announcements work. > And your argument "why you subclass from Announcer" looks to me like why you > subclass from SubscriptionsRegistry. But I'm not. Nobody doing it. > So i'm not understand why you want another wrapper around Announcer. > > (To me "subscriptions" is better name then "registry". And I prefer > composition than inheritance too). > There are 3 kinds of roles in context: - subscriber: an object who subscribing for events to receive them later - an event source (the object which announces the event) - an announcer, an object which provides subscription service and through which you can announce events, acting as mediator between 2 parties above the rest, like registry, Announcement (as class) and subscriptions is implementation detail. The main reason for using Announcements model is to have decoupling between event source (the place/object , which producing events) and its handlers. And announcer provides such decoupling. That means, both subscribers and event source(s) don't need to have direct knowledge about each other, all they need is to use same announcer to establish communication channel. Then, subscribers don't really care who triggered an event and why/where while event source don't really cares who will handle the event(s), in what order or how many of them there. Now, what happens when you mixing roles and treating announcer as an event source? (and by subclassing from Announcer you doing that). When you merge event source and announcer, then your subscribers are forced to have direct access to event source, and that means you actually not using/need decoupling at all. In this regard, my question: why then you using Announcements model at all? Because it is there, or because there should be only one? I don't think that either of these reasons are valid. When you don't need decoupling , i do not see much value in using Announcements. I would implement/use something else then. -- Best regards, Igor Stasenko.

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by Igor Stasenko

On 19 July 2013 19:14, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: > Igor - could you please explain 'the principle of least authority'? Here the wiki link: http://en.wikipedia.org/wiki/Principle_of_least_privilege > Thanks, > - Paul > -- Best regards, Igor Stasenko.

July 21, 2013

Re: [Pharo-dev] Don't want to see a particular notification

by StÃ©phane Ducasse

Hi pharoers I think that doing is more difficult than evolving :) So before this scenario happens, I want to have a new changes management system that is orthogonal to the source management. Right now these two concepts are mixed together. Martin in the context of his PhD is working on a nice replacement to changeset and also he is building a nice representation of a change (in the spirit of deltaStream) with changes representation and not just method, class, package. The project is called Epicea. We want to support for example: - I perform a list of changes - I tagged them with comments like refactored this method into these two - publish the code - and Alain can review my code at the level of the semantic change by looking and commenting on changes using the tags. I hope to get a nice demo for ESUG :) Stef >>>> >>>>> Hi, >>>>> >>>>> in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code >>>>> that looks like this: >>>>> >>>>> [...] >>>>> changes isReadOnly >>>>> ifTrue: [ self inform: 'Pharo cannot write to the >>>>> changes file ...' ]. >>>>> [...] >>>>> >>>>> This code raises a warning if the changes file can't be written to. In >>>>> the PharoLauncher case, the image and changes file won't be writable >>>>> and it is ok (they will be in a place like /usr/lib). I certainly >>>>> don't want my users to see this warning. >>>>> >>>>> What can I do please? >>>>> >>>> >>>> We need to get rid of .changes and .sourcesâ¦ it will solve all kinds of problems. >>>> >>> What will be the replacement? >>> >> >> -> transaction log attached to he end of the running image file >> > Ok, sounds reasonable on the one hand (getting rid of an additional file) and dangerous on the other hand (on image write the transaction log needs to be read/written/moved making it possible to loose image and transaction log. Think about a "disk full" scenario). How is this covered? > >> -> accepted methods kept in image history until next commit to the source repo >> > Great. Everyone can have a ImmediateCommitStrategy so no reason to complain, right? > >> -> sources in image. First compresses text with a shared compression dictionary, >> later a high-level representation of code that superseded the AST, text and bytecode. >> > That is really cool. There is no reason to have sources separate until you treat it like text you basicall don't care about. I'm curious with what you'll come up with regarding the thing that supersedes ast, text and bytecode. And especially if the visual syntax can still be the same as it is now. As you know I would be a fan of something that would keep the smalltalk syntax (meaning visual characters) the same but adds visual things (colors, icons, type setting) to indicate the presence of meta data. Underneath there be something that can transport the code with an extended source format to another image. Cool times are these. > >> Yes, and I know that everyone things that this is wrong. And I don't care :-) >> > Come on. Things aren't that bad. Just imagine that all of the people that aren't complaining do agree or don't care about. And that's a way bigger number. I personally like those steps even if it means we are loosing a lot of tools and frameworks out there (And there aren't that many) > > Norbert

July 21, 2013

Re: [Pharo-dev] Don't want to see a particular notification

by StÃ©phane Ducasse

May be we should refactor the code so that we can specify if the warning should be raised or not. > Hi, > > in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code > that looks like this: > > [â¦] > changes isReadOnly > ifTrue: [ self inform: 'Pharo cannot write to the > changes file ...' ]. > [...] > > This code raises a warning if the changes file can't be written to. In > the PharoLauncher case, the image and changes file won't be writable > and it is ok (they will be in a place like /usr/lib). I certainly > don't want my users to see this warning. > > What can I do please? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

July 21, 2013

Re: [Pharo-dev] Don't want to see a particular notification

by Marcus Denker

>> >> -> transaction log attached to he end of the running image file >> > Ok, sounds reasonable on the one hand (getting rid of an additional file) and dangerous on the other hand (on image write the transaction log needs to be read/written/moved making it possible to loose image and transaction log. Think about a "disk full" scenario). How is this covered? > For the change log: it will stop recording (like now when there is no space for .changes appending) Image save: right now you override the existing file, this means that if you don't have enough space for you (likely) larger image, it will fail and override the old image. New: it will fail, but while writing the *new* file. So you at least keep your old. In both cases you can't write a new image file, but right now you loose your old one, too. So it's better. >> -> accepted methods kept in image history until next commit to the source repo >> > Great. Everyone can have a ImmediateCommitStrategy so no reason to complain, right? > Yes, it is the same as now: you loose the "method save" commits as only what is in Monticello is saved for real. >> -> sources in image. First compresses text with a shared compression dictionary, >> later a high-level representation of code that superseded the AST, text and bytecode. >> > That is really cool. There is no reason to have sources separate until you treat it like text you basicall don't care about. I'm curious with what you'll come up with regarding the thing that supersedes ast, text and bytecode. And especially if the visual syntax can still be the same as it is now. As you know I would be a fan of something that would keep the smalltalk syntax (meaning visual characters) the same but adds visual things (colors, icons, type setting) to indicate the presence of meta data. Underneath there be something that can transport the code with an extended source format to another image. Cool times are these. The idea would be to keep it at the beginning just the same: instead of a stream of characters, the data structure would be different, but would be just s string form what it shows. (this means no changes to MC, Git, or even file out). Purely internal. > >> Yes, and I know that everyone things that this is wrong. And I don't care :-) >> > Come on. Things aren't that bad. :-) > Just imagine that all of the people that aren't complaining do agree or don't care about. And that's a way bigger number. I personally like those steps even if it means we are loosing a lot of tools and frameworks out there (And there aren't that many) I think nothing works directly on the .source and .changes right nowâ¦ so one would loose nothing. (Of course after there are other things thinkableâ¦ but that is for after). Marcus

July 21, 2013