April 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] About Traits

by Stephan Eggermont

On 22-04-16 17:04, Hilaire wrote: > Hi Julien, > > > Le 22/04/2016 16:45, Julien Delplanque a Ã©crit : >> Hello, >> >> I have a question about Trait. >> >> Is it ok, in the design point of view, to use them to force an object to >> implement an interface? > Why not using a parent abstract class for that, with required method > answering #subclassResponsability? > > Then from your tests in subclasses, you check > > self shouldnt: [instance toto] raise: SubclassResponsabilty > That limits one to one interface. Why not use a test testTheConformingImplementation self assert: ((AConformingImplementation selectors) asOrderedCollection addAll: (AnInterfaceClass selectors)) asSet = (AConformingImplementation selectors) asSet

April 22, 2016

Re: [Pharo-users] About Traits

by Julien Delplanque

On 22/04/16 17:04, Hilaire wrote: > Hi Julien, > > > Le 22/04/2016 16:45, Julien Delplanque a Ã©crit : >> Hello, >> >> I have a question about Trait. >> >> Is it ok, in the design point of view, to use them to force an object to >> implement an interface? > Why not using a parent abstract class for that, with required method > answering #subclassResponsability? Yes this is what I do for now. But what if I do not want to force the use of inheritance? > > Then from your tests in subclasses, you check > > self shouldnt: [instance toto] raise: SubclassResponsabilty > This wont work if the object does not implement #toto at all. >> Like that it would be possible to check (via an #assert: for example) if >> a class provides the interface required. >> >> I read some things I found on the net about Traits and already used >> TComparable but I never created one myself and I am not sure to >> understand this concept entirely. > > With Trait you add behavior to a class. TComparable adds behavior to > your class, your instance are then comparable. Is it a problem? Isn't it similar to Java's interface? I see traits as a mix between Java's abstract classes and Java's interface since you can define methods and let some of them abstract but you can not define instance variables. But maybe I am wrong, that is why I ask :)... Julien

April 22, 2016

Re: [Pharo-users] About Traits

by Hilaire

Hi Julien, Le 22/04/2016 16:45, Julien Delplanque a Ã©crit : > Hello, > > I have a question about Trait. > > Is it ok, in the design point of view, to use them to force an object to > implement an interface? Why not using a parent abstract class for that, with required method answering #subclassResponsability? Then from your tests in subclasses, you check self shouldnt: [instance toto] raise: SubclassResponsabilty > Like that it would be possible to check (via an #assert: for example) if > a class provides the interface required. > > I read some things I found on the net about Traits and already used > TComparable but I never created one myself and I am not sure to > understand this concept entirely. With Trait you add behavior to a class. TComparable adds behavior to your class, your instance are then comparable. > > > Thanks in advance! > > Julien > -- Dr. Geo http://drgeo.eu

April 22, 2016

About Traits

by Julien Delplanque

Hello, I have a question about Trait. Is it ok, in the design point of view, to use them to force an object to implement an interface? Like that it would be possible to check (via an #assert: for example) if a class provides the interface required. I read some things I found on the net about Traits and already used TComparable but I never created one myself and I am not sure to understand this concept entirely. Thanks in advance! Julien

April 22, 2016

Re: [Pharo-users] ensureCreateFile

by Valentin Ryckewaert

For me ensureCreateFolder is made to be sure the folder is created, if you make '/home/a/b/c/d' with a b c d not existing it will create all of them. ensureCreateFile should do the same thing no ? 2016-04-21 13:19 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > because it's like this > > ensureCreateFolder : create the folder structure if necessary > ensureCreateFile : create the file if necessary > > I really don't see any gain from changing existing behavior and > introducing potential problems. > If I ask for file to be created, I don't expect that the system will > suddenly start creating folders, that's a unintentional side effect. > If you need it for your convenience, then it's dead-easy to implement > without breaking existing stuff. > > > On Thu, Apr 21, 2016 at 10:35 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2016-04-21 9:55 GMT+02:00 Valentin Ryckewaert < >> valentin.ryckewaert(a)gmail.com>: >> >>> Yes but why ensureCreateFile then ? >>> Why don't we juste create a message createFile as there is createFolder ? >>> createFolder : create the folder >>> createFile : create the file >>> >>> ensureCreateFolder : create the folder and its parents if necessary >>> ensureCreateFile : create the file and its parents if necessary >>> >> >> +1 >> > >

April 22, 2016

Re: [Pharo-users] Trapping the Pharo window close event

by Dimitris Chloupis

sorry meant to say Pharo is not lazy coder friendly by nature. On Fri, Apr 22, 2016 at 10:03 AM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Just for the record I am in agreement as I think most of us are about > this. > > But.... > > I think as a community must make one thing clear > > Pharo is environment meant to be hacked. Its not always to do so but > similarly to Squeak, the goal here is to give developers and environment > that they can design and modify themselves with ease. At least a lot more > than other languages and this is where Pharo really excels. > > In the end Pharo does not tries to be the most popular thing out there, it > tries to fill a gap that others dont or cant. Sure we want to make Pharo > popular but making something that is a ready made solution is not our top > priority. Making something modifiable and direct so much more. > > I think its our responsibility to make this clear to newcomers. > > Or else people will wonder, why not use python, ruby or whatelse which > comes with sophisticated IDEs far more lazy friendly than Pharo. > > Pharo is definetly , by nature, lazy coder friendly. Its for coders that > like to design their own workflow. > > On Sat, Apr 16, 2016 at 1:51 PM kmo <voxkmp(a)gmail.com> wrote: > >> Well, my reply was rather tongue-in-cheek. I was mocking my own laziness >> and >> the laziness of developers like me. But really I have no problem in doing >> these things for myself. And I hope that soon I will be in a position to >> contribute to pharo myself. >> >> But overriding the close event is something any application developer is >> going to want to do. And every time you make a developer work harder than >> necessary to implement a basic feature you make the pharo platform less >> attractive. If you want more developers to use pharo you have to make >> basic >> things like this easy to do and easy to find out how to do. >> >> I do think that deployment of applications gets very little attention in >> pharo - yet it's a major issue of you want to make pharo a widely-used >> application platform. >> >> I'm not the only lazy developer, you know . >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p48902… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >>

April 22, 2016

Re: [Pharo-users] Trapping the Pharo window close event

by Dimitris Chloupis

Just for the record I am in agreement as I think most of us are about this. But.... I think as a community must make one thing clear Pharo is environment meant to be hacked. Its not always to do so but similarly to Squeak, the goal here is to give developers and environment that they can design and modify themselves with ease. At least a lot more than other languages and this is where Pharo really excels. In the end Pharo does not tries to be the most popular thing out there, it tries to fill a gap that others dont or cant. Sure we want to make Pharo popular but making something that is a ready made solution is not our top priority. Making something modifiable and direct so much more. I think its our responsibility to make this clear to newcomers. Or else people will wonder, why not use python, ruby or whatelse which comes with sophisticated IDEs far more lazy friendly than Pharo. Pharo is definetly , by nature, lazy coder friendly. Its for coders that like to design their own workflow. On Sat, Apr 16, 2016 at 1:51 PM kmo <voxkmp(a)gmail.com> wrote: > Well, my reply was rather tongue-in-cheek. I was mocking my own laziness > and > the laziness of developers like me. But really I have no problem in doing > these things for myself. And I hope that soon I will be in a position to > contribute to pharo myself. > > But overriding the close event is something any application developer is > going to want to do. And every time you make a developer work harder than > necessary to implement a basic feature you make the pharo platform less > attractive. If you want more developers to use pharo you have to make basic > things like this easy to do and easy to find out how to do. > > I do think that deployment of applications gets very little attention in > pharo - yet it's a major issue of you want to make pharo a widely-used > application platform. > > I'm not the only lazy developer, you know . > > > > -- > View this message in context: > http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p48902… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 22, 2016

Re: [Pharo-users] Trapping the Pharo window close event

by stepharo

Le 16/4/16 12:18, kmo a Ã©crit : > Well, my reply was rather tongue-in-cheek. I was mocking my own laziness and > the laziness of developers like me. But really I have no problem in doing > these things for myself. And I hope that soon I will be in a position to > contribute to pharo myself. But you are :) 30 min a week is enough :) > > But overriding the close event is something any application developer is > going to want to do. And every time you make a developer work harder than > necessary to implement a basic feature you make the pharo platform less > attractive. If you want more developers to use pharo you have to make basic > things like this easy to do and easy to find out how to do. We know that. Now I will not give the HUGE list of the things we are working on and that default developers are in need: - good file library - good list widget - FFI - decent texteditor - a compiler :) - ... > > I do think that deployment of applications gets very little attention in > pharo - yet it's a major issue of you want to make pharo a widely-used > application platform. Indeed. We started to push that when damien worked on the launcher and we should continue. > > I'm not the only lazy developer, you know . > > > > -- > View this message in context: http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p48902… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 22, 2016

Re: [Pharo-users] Trapping the Pharo window close event

by stepharo

Le 16/4/16 11:33, kmo a Ã©crit : > /Pharo is yours, so you can add it. :)/ > > Yes, but I don't want to add it. I expect it to be there out of the box. So you believe either is modern slavery or magic auto generation :D Seriously if you that need it are not ready to invest 30 min why me that does not need it should do it? Do you know what is free open-source software? > I think it's quite enough work for me to add my own code on window close. I > don't want to have to write the framework for doing it as well. > > > > -- > View this message in context: http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p48902… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 22, 2016

Re: [Pharo-users] Trapping the Pharo window close event

by stepharo

My point is that it is a proof that a library is not good when it forces users to redefined core code. Stef Le 15/4/16 23:06, Peter UhnÃ¡k a Ã©crit : > > I did not really get it. Now I have the impression that changing > the method definition shows that Pharo does not > offer the correct possibility. > Am I correct? > > > I disagree. Closing the window should not decide on it's own whether > the session should be saved. Asking the user is the right thing. > > The ideal thing would be to not ask if nothing has happened... but > that's impossible, this is a live system, not a text editor. > > Peter

April 22, 2016