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

Re: [Pharo-project] About on:

by Lukas Renggli

> ANSI is a standard and there are cases where it is wrong (commitee decisions > = compromise) I agree, however changing the behavior of #next means that we will not be able to develop Seaside on Pharo. Seaside takes great advantage that Squeak is ANSI compatible. Lukas > > On Jun 5, 2008, at 3:27 PM, Bill Schwab wrote: > > > > Lukas, > > > > I have blind copied someone who can comment, or not at his discretion, > > on Cincom's view on this; he never said he was commenting off the > > record, but I try to err toward assuming that. I got the distinct sense > > that they are contemplating a change of some type and are also > > struggling with backward compatibility. > > > > You are correct about ANSI; I was shocked to see what they did. > > Without reservation, I assert the standard is wrong. Exception handling > > was created to allow the widespread elimination of precisely the > > condition that arises when #next reads off the end of a stream. I can > > always (and probably will if we do not fix this) deprecate #next and > > #next: in my own work, but that still leaves inconsistencies between and > > within dialects. > > > > 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 > > > > > > > > > > > > > > > > > > renggli(a)gmail.com 6/5/2008 7:18 AM >>> > > > > > > > > > Yes, but it is not consistent, and they are apparently not happy > > > > > > > > > with it. > > > > Why? Can you give any pointers? > > > > > > > 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. > > > > As far as I see this is inconsistent with the ANSI standard. > > > > Cheers, > > Lukas > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > 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 > -- Lukas Renggli http://www.lukas-renggli.ch

June 5, 2008

Re: [Pharo-project] Most active

by Serge Stinckwich

2008/6/5 Damien Cassou <damien.cassou(a)gmail.com>: > Pharo is the 4th most active project in gforge and it appears in the > front page. Pharo is also the most active SqueakSource project. This is the INRIA gforge ;-) and the most active project on SqueakSource seems to be broken ... -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/

June 5, 2008

Re: [Pharo-project] Most active

by Alexandre Bergel

This is an excellent news :-) Alexandre On 5 Jun 2008, at 17:06, Damien Cassou wrote: > Pharo is the 4th most active project in gforge and it appears in the > front page. Pharo is also the most active SqueakSource project. > > -- > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 5, 2008

[Pharo-project] Most active

by Damien Cassou

Pharo is the 4th most active project in gforge and it appears in the front page. Pharo is also the most active SqueakSource project. -- 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

ANSI is a standard and there are cases where it is wrong (commitee decisions = compromise) On Jun 5, 2008, at 3:27 PM, Bill Schwab wrote: > Lukas, > > I have blind copied someone who can comment, or not at his discretion, > on Cincom's view on this; he never said he was commenting off the > record, but I try to err toward assuming that. I got the distinct > sense > that they are contemplating a change of some type and are also > struggling with backward compatibility. > > You are correct about ANSI; I was shocked to see what they did. > Without reservation, I assert the standard is wrong. Exception > handling > was created to allow the widespread elimination of precisely the > condition that arises when #next reads off the end of a stream. I can > always (and probably will if we do not fix this) deprecate #next and > #next: in my own work, but that still leaves inconsistencies between > and > within dialects. > > 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 > > >>>> renggli(a)gmail.com 6/5/2008 7:18 AM >>> >>> Yes, but it is not consistent, and they are apparently not happy > with it. > > Why? Can you give any pointers? > >> 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. > > As far as I see this is inconsistent with the ANSI standard. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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] MVC removing step2: your point of view

by StÃ©phane Ducasse

alain you should pay attention that you shoudl deprecate the method. People should be able to load their code in pharo On Jun 5, 2008, at 1:52 PM, Alain Plantec wrote: > 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 for now I'm not sure that I would focus on that. I would clean really the ugly part and etoy. stef > > alain > > _______________________________________________ > 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

Lukas, I have blind copied someone who can comment, or not at his discretion, on Cincom's view on this; he never said he was commenting off the record, but I try to err toward assuming that. I got the distinct sense that they are contemplating a change of some type and are also struggling with backward compatibility. You are correct about ANSI; I was shocked to see what they did. Without reservation, I assert the standard is wrong. Exception handling was created to allow the widespread elimination of precisely the condition that arises when #next reads off the end of a stream. I can always (and probably will if we do not fix this) deprecate #next and #next: in my own work, but that still leaves inconsistencies between and within dialects. 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 >>> renggli(a)gmail.com 6/5/2008 7:18 AM >>> > > Yes, but it is not consistent, and they are apparently not happy with it. Why? Can you give any pointers? > 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. As far as I see this is inconsistent with the ANSI standard. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ 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] MVC removing step2: your point of view

by Noury Bouraqadi

Hi, If we take the separation of concens principle, GUI code should be totally separated from the model one. GUI can have a knowledge of the model, but the model should not care about the view. So, we should have a BrowserModel and a MorphicBrowser. Every new GUI system will require implementing its own view... And views of the same model will all be polymorphic and accept an open message. Now, this separation is not done in the plain Browser. So, the underlying question is that should we maintain this bad design. My position is that more cleanup should be done before introducing a new GUI system. So, I suggest to rename the method "open". Noury On 5 juin 08, at 13:52, Alain Plantec wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

June 5, 2008

Re: [Pharo-project] About on:

by Lukas Renggli

> > Yes, but it is not consistent, and they are apparently not happy with it. Why? Can you give any pointers? > 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. As far as I see this is inconsistent with the ANSI standard. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

June 5, 2008

Re: [Pharo-project] About on:

by Bill Schwab

Damien, It cannot be "fixed" without breaking said external code. However, there is a very clear way for those interested to refactor old code to be consistent. The only alternative is to use selectors such as #nextOne, #nextMany:, etc., to do the jobs that #next and #next: purport to do. I can do that myself; my hope is to fix the real problem, and to gradually bring VW along with us. Perhaps my problem is that I fell into a Smalltalk (Dolphin) that had this right (and grumbled about it, only to later be convinced of its correctness), and now find the analogy to #at: very clear as a result. IMHO, this is a situation where we should lead, but you already knew that. Time for me to start my commute. 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 7:39 AM >>> 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) _______________________________________________ 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