June 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] MVC removing step2: your point of view

by Alain Plantec

Hi all, I'm cleaning some methods which contain 'AsMorph'. for example, Browser>>openAsMorphMessageEditing: is send only in Browser>>openMessageEditString: which only returns openAsMorphMessageEditing: result. so, I copy code from Browser>>openAsMorphMessageEditing: to Browser>>openMessageEditString: and remove Browser>>openAsMorphMessageEditing:. I guess this is ok. But now I'm continuing by chasing all methods with 'InMorphic' in their name. As an example, there is Morph>>embeddedInMorphicWindowLabeled:. the question is, do I make the asumption that morphic is the only way or the default (then Morph>>embeddedInMorphicWindowLabeled: can be renamed as Morph>>embeddedInWindowLabeled:) or do I let it as is ? the same would be applied to openInMorphic (->open), inspectModelInMorphic (->inspectModel), inspectInMorphic: (->inspect:), inspectInMorphic (->removed because no sender), thanks alain

June 5, 2008

Re: [Pharo-project] About on:

by Damien Cassou

On Thu, Jun 5, 2008 at 1:06 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Yes, but it is not consistent, and they are apparently not happy with it. Object Arts' solution is consistent both with itself and with yoga of structured exception handling. However, at this point, it appears that you do not want to make the change, so I will stop pressing. I personally would like to see this change in Pharo. However, there is no consensus and it might affect a lot of external code that the refactoring can't change. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

June 5, 2008

Re: [Pharo-project] About on:

by StÃ©phane Ducasse

no this is the point. We are learning. I propose to harvest the on: change and have a pln for end of stream behavior stef On Jun 5, 2008, at 1:06 PM, Bill Schwab wrote: > Damien, Lukas, Stef, > > Yes, but it is not consistent, and they are apparently not happy > with it. Object Arts' solution is consistent both with itself and > with yoga of structured exception handling. However, at this point, > it appears that you do not want to make the change, so I will stop > pressing. > > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > >>>> damien.cassou(a)gmail.com 06/05/08 6:27 AM >>> > On Thu, Jun 5, 2008 at 12:01 PM, Lukas Renggli <renggli(a)gmail.com> > wrote: >>>> No surprise, I would argue that we proceed, and would also >>>> include a >>> rename of #next to #nextOrNil and #next: to #nextAvailable:. All >>> code in >>> the image at the time should work as before. >>> >>> What would be the impact on code that is not in the image? Would all >>> external packages need to be adapted as well or would the current >>> semantics >>> be preserved? >> >> I suggest to implement #next so that it throws an EndOfStream >> notification. The default action would return nil, so no existing >> code >> needs to be changed. People that want to use exceptions capture the >> notification. > > That's what is in VW apparently. > > > > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 5, 2008

Re: [Pharo-project] About readStream on: vs readStream

by StÃ©phane Ducasse

ok i like this summary stef On Jun 5, 2008, at 11:37 AM, Damien Cassou wrote: > On Wed, Jun 4, 2008 at 8:36 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I was wondering why you think that ReadStream on: anObject is worse >> than >> anObject readStream? >> Because you do not hardcode ReadStream? > > I already gave my opinion that at least 3 times :-). Here is it again: > > - no more direct reference on ReadStream where it is not necessary > - allows different implementation of #readStream depending on the > receiver class (different collection classes can use specific streams > as it is the case in Nile. In GnuSmalltalk, WriteStream>>readStream > answers a ReadStream without needing copy the collection) > - clarify the code: I noticed the code becomes much more readable > - use a method that has been there for ages > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 5, 2008

Re: [Pharo-project] HowToContribute wiki page rewrite

by Serge Stinckwich

ok thank you. 2008/6/5 Damien Cassou <damien.cassou(a)gmail.com>: > On Thu, Jun 5, 2008 at 11:31 AM, Serge Stinckwich > <serge.stinckwich(a)doesnotunderstand.org> wrote: >> I guess i'm not an administrator ;-) > > Fixed. > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/

June 5, 2008

Re: [Pharo-project] About on:

by Bill Schwab

Damien, Lukas, Stef, Yes, but it is not consistent, and they are apparently not happy with it. Object Arts' solution is consistent both with itself and with yoga of structured exception handling. However, at this point, it appears that you do not want to make the change, so I will stop pressing. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> damien.cassou(a)gmail.com 06/05/08 6:27 AM >>> On Thu, Jun 5, 2008 at 12:01 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> > No surprise, I would argue that we proceed, and would also include a >> rename of #next to #nextOrNil and #next: to #nextAvailable:. All code in >> the image at the time should work as before. >> >> What would be the impact on code that is not in the image? Would all >> external packages need to be adapted as well or would the current semantics >> be preserved? > > I suggest to implement #next so that it throws an EndOfStream > notification. The default action would return nil, so no existing code > needs to be changed. People that want to use exceptions capture the > notification. That's what is in VW apparently. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 5, 2008

Re: [Pharo-project] About on:

by Bill Schwab

Adrian, All external code would need to be adapted. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> adi(a)netstyle.ch 06/05/08 2:52 AM >>> On Jun 5, 2008, at 00:27 , Bill Schwab wrote: > Stef, Damien, > > No surprise, I would argue that we proceed, and would also include a > rename of #next to #nextOrNil and #next: to #nextAvailable:. All > code in the image at the time should work as before. What would be the impact on code that is not in the image? Would all external packages need to be adapted as well or would the current semantics be preserved? Adrian > The next step (part B) would be to add exception-aware #next and > #next:. > > Damien and I could cook it up, try it, and then return with an "all > clear." > > Bill > > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > > >>>> stephane.ducasse(a)inria.fr 6/4/2008 10:36 AM >>> > > On Jun 4, 2008, at 5:20 PM, Damien Cassou wrote: > >> On Wed, Jun 4, 2008 at 1:45 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> here is what I propose for on: >>> I will move your package out of the inbox so that the discussion >>> can go on >>> and >>> I try to integrate all the other changes. >>> Then with bill and others you propose how to proceed. >>> Is it ok ? >> >> What do you mean by 'I will move your package out of the inbox'? Do >> you mean you simply delete the packages or you moved them to Pharo? > > I mean move them to the treatedBox without putting in the image > >> Replacing 'ReadStream on: smth' by 'smth readStream' is not >> mandatory. >> However, it makes the code simpler to read, avoids a direct class >> reference and allows different implementation of #readStream >> depending >> on the kind of collection it is sent to. I do not think anyone is >> against that as soon as I apply the automatic refactoring >> carefully. I >> did that and didn't see any place where the RB did a bad job. It even >> detected that SequenceableCollection>>readStream should not be >> changed >> to avoid infinite recursion. >> >> Do you think there is a problem that I might take care of? > > Now as a group how do we want to handle this case? > We give a try and trust damien? > > Stef > > >> >> >> >> -- >> Damien Cassou >> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 5, 2008

Re: [Pharo-project] About on:

by Damien Cassou

On Thu, Jun 5, 2008 at 12:01 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> > No surprise, I would argue that we proceed, and would also include a >> rename of #next to #nextOrNil and #next: to #nextAvailable:. All code in >> the image at the time should work as before. >> >> What would be the impact on code that is not in the image? Would all >> external packages need to be adapted as well or would the current semantics >> be preserved? > > I suggest to implement #next so that it throws an EndOfStream > notification. The default action would return nil, so no existing code > needs to be changed. People that want to use exceptions capture the > notification. That's what is in VW apparently. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

June 5, 2008

Re: [Pharo-project] HowToContribute wiki page rewrite

by Damien Cassou

On Wed, Jun 4, 2008 at 7:39 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks so may be we should move the wiki contents to this one > but more importantly the tasks. I've setup the issue tracking system and I've started by adding 3 short-term issues. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

June 5, 2008

Re: [Pharo-project] About on:

by Lukas Renggli

> > No surprise, I would argue that we proceed, and would also include a > rename of #next to #nextOrNil and #next: to #nextAvailable:. All code in > the image at the time should work as before. > > What would be the impact on code that is not in the image? Would all > external packages need to be adapted as well or would the current semantics > be preserved? I suggest to implement #next so that it throws an EndOfStream notification. The default action would return nil, so no existing code needs to be changed. People that want to use exceptions capture the notification. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

June 5, 2008