March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] about code formatting in pharo

by Schwab,Wilhelm K

A conditional +1; can I simply edit and save code without "benefit" of a formatter? That could probably be via an installable "formatter" that does _nothing_ to my code. Given that option, I'm all in favor of what makes others happy. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Thursday, March 04, 2010 2:49 PM To: Pharo Development Subject: Re: [Pharo-project] about code formatting in pharo +1 On Mar 4, 2010, at 19:10 , Dale Henrichs wrote: > It is obvious that a consensus will not be reached on the "one and only true format." > > If my browser displays code formatted the way I want to see it and the difference tools are format neutral (i.e., the source and target code is formatted using the same rules) there is no need to agree on a standard style. For all intents and purposes each developer's favored format _is the standard_. > > We only need to agree to disagree and then figure out how to make it possible to customize the formatter and resolve any other technical details (performance and others) that are deemed important. These are technical problems with technical solutions. > > Dale > ----- "Chris Muller" <asqueaker(a)gmail.com> wrote: > > | > Another visual problem with "[" and "]" is that they are but one > | > character, and if you place them together with something else, > | > like "[self", they lose their visual identity (btw, we read words > | > in > | chunks > | > not by characters) and get harder to spot. It's true that some > | > fonts and extra coloring could solve this problem, but whitespace > | > is > | always > | > the best and least invasive design weapon. > | > | Tudor, for what its worth, the white-space surrounding the blocks is > | not really at issue or discussion here. It's about formatting > | blocked code into rectangular shapes. > | > | In fact, I agree with you about your point about the whitespace. > | IOW, I prefer: > | > | someVar = someValue > | ifTrue: [ self doOneThing ] > | ifFalse: > | [ self > | doOtherThing ; > | doYetAnotherThing. > | anotherObject doSomething ] > | > | Not: > | > | someVar = someValue > | ifTrue: [self doOneThing] > | ifFalse: > | [self > | doOtherThing ; > | doYetAnotherThing. > | anotherObject doSomething] > | > | Perhaps if you looked at a longer method example, with nested > | blocks, you might be able to "see", visually, the blocks more obviously. > | Perhaps not, I don't know. > | > | Regards, > | Chris > | > | > The lines are clearly belonging together, [ is clearly observed > | > and clicking anywhere on the first line after [ will select the > | > whole > | block. > | > > | > Yet another thing it solves is the consistency between block and > | > method. They both define behavior, and thus it would be great if > | they > | > would be treated similarly. This is better seen in the context of > | > a block with parameter: > | > > | > aCollection do: [ :each | > | > self something. > | > self somethingElse. ] > | > > | > Just like a method has the top line with the signature and the > | > parameters, a block should be the same. In this case, each is a > | > parameter and it is clearly distinct from everything else. When > | there > | > is no parameter, this is information made very clear, too (because > | of > | > the absence of anything following [ ). > | > > | > > | > An argument against this convention was that it looks like C and > | that > | > blocks are not dumb {. While I understand the built-in adversity, > | > we are talking about a visual notation that makes sense for > | > Smalltalk > | and > | > not one that make it different from everything else around us. > | > > | > Another option would be to have: > | > boolean ifTrue: > | > [ self clearCaches. > | > self current soleInstance yada yada blah blah > | > self recomputeAngle ] > | > > | > with everything inside the block being aligned. However, this has > | the > | > problem of wasting space. One space can also be used, but only > | > when the font is monospaced, so it would not work in general. > | Furthermore, > | > it would be inconsistent or even more space wasting when it comes > | > to blocks with parameters. > | > > | > Cheers, > | > Doru > | > > | > > | > On 4 Mar 2010, at 03:38, Chris Muller wrote: > | > > | >>>> ifTrue: [ > | >>>> line1 yo. > | >>>> line2 eh ] > | >>> > | >>> Horrible, horrible, horrible ;) Poor block. The block is an > | >>> object... > | >> > | >> Exactly what I was thinking; and how some of the new editor > | features > | >> since 3.9, that seem to reify "statements". For example, > | >> clicking inside parens or square-brackets selects that > | >> statement(s). I also really enjoyed the ability to "surround", > | >> thereby creating > | additional > | >> statement-levels. > | >> > | >> The whole interaction becomes much more liked working with tiled > | code > | >> rather than a text-editor. > | >> > | >>> I think the conclusion has to be (and I can confirm that the > | >>> VisualWorks team was equally divided) that no one formatting > | >>> regime will make every one happy and that all regimes will make > | >>> a substantial minority unhappy. So perhaps we should step up to > | >>> having code formatted automatically according to tailorable > | >>> preferences. > | >> > | >> > | >> > | >>> My only concern is comment formatting but the way to deal with > | that > | >>> is to > | >>> use automatic formatting and deal with comment problems as they > | >>> arise. I always used to be concerned about e.g. comments > | >>> spanning multiple lines. > | >>> But without day to day exposure I don't think one can know how > | >>> much of an issue it is. > | >> > | >> As someone who's logged 5-digits of hours in Squeak these last > | >> few years, I think the best thing is to just not. Let 'em wrap! > | >> Use shout to turn them light gray, so they don't really intrude > | >> on the code, but are there if you want focus on the extra prose. > | >> > | >> Unfortunately, the real problem with comments within BlockNodes > | >> is > | how > | >> they duplicate themselves within the parse-tree.. ouch! I hope > | that > | >> is what you and Nicolas were talking about or that you'll have a > | fix > | >> for that.. > | >> > | >>> One upside will be less effort reformatting when indent levels > | >>> change. Have you noticed that Smalltalk tends to be more > | >>> difficult to reformat than C syntax languages, I guess because > | >>> of keywords? Not having to > | worry > | >>> about > | >>> this could be great. > | >> > | >> Very cool, I hope there'll be enough additional consensus to > | >> adopt these Beckian formats for Squeaks pretty-print refinement. > | >> > | >>> Of course, what format gets written to a source file could still > | be > | >>> a source > | >>> of conflict ;) We may all want our syntax to be the format of > | >>> record :) > | >> > | >> Absolutely. To not, would be the machine dictating to the user. > | >> Invoking automatic formatting is always the users choice. > | >> browseWithPrettyPrint allows readers to have it formatted > | dynamically > | >> if they wish.. > | >> > | >> Cheers.. > | >> > | >>> P.S. and don't get me started on the trailing period (putrid > | >>> excressence), or the space between ^ and the return expression > | >>> (vomitous mass). > | >> > | >> _______________________________________________ > | >> Pharo-project mailing list > | >> Pharo-project(a)lists.gforge.inria.fr > | >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-proje > | >> ct > | > > | > -- > | > www.tudorgirba.com > | > > | > "Live like you mean it." > | > > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > Pharo-project(a)lists.gforge.inria.fr > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-projec > | > t > | > > | > | _______________________________________________ > | 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

March 4, 2010

Re: [Pharo-project] [Moose-dev] Re: Fwd: Re: ConfigurationOfMetacello and OB

by Lukas Renggli

> Yes, an OBPlatform for each major version... Well, the problem is that ... OBPlatform OBMorphicPlatform OBShoutPlatform That doesn't really work without an explosion of classes and I don't feel like changing all that :-( Lukas > > > Dale > -- Lukas Renggli http://www.lukas-renggli.ch

March 4, 2010

Re: [Pharo-project] About danny help :)

by StÃ©phane Ducasse

On Mar 4, 2010, at 8:48 PM, Danny Chan wrote: >> >>> I am not sure what you mean by modular. It has a Metacello configuration. >> >> my point is if you imagine that we want a small system with good packages >> where do we put the helpSystem. > Hm, still not 100% sure what you mean. If you're asking how we can have > documentation usable with HelpSystem without having to actually load > HelpSystem, then see below. I was thinking aloud. I was thinking we can load HelpSystem and use it but since we want to have core we should get it in Pharo but still make sure that everything in Core is adapted to give info to Pharo. >>> A nice idea on squeak-dev was to add support for a simple structured >>> markup language like Markdown in class comments. We could use this to >>> write "big- picture" documentation directly in a class comment. I think >>> this would complement the method comments quite nicely. >> >> Do you have an example? >> > > In a package you put in the most important class a comment that looks somehow > like this: > > <classcomment> > Here comes the comment for the class > </classcomment> Why XML? > <packagecomment> > This is the documentation for MyPackage. > > # Introduction > A bit of introduction. > # Another chapter > More text. > ## Structure > You can have sub levels > > where do you define <packagecomment> > And this would create a documentation tree like this (text after the colon is > displayed in the content window): > > - MyPackage: This is the documentation for MyPackage. > - Introduction: A bit of introduction > - Another chapter: More text > - Structure: You can have sub levels > - API documentation > - Class1 documentation > - Instance Methods > - Class Methods > - Class1 documentation > - Instance Methods > - Class Methods > ... > > Now you have all the documentation for a package in the comments, but you can > view it in a nicely structured way. > > Does this make sense? Yes In addition I would like to have a tag for promoting test to be list in the help. <documentation> Would be nice. Stef > > Danny > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 4, 2010

Re: [Pharo-project] [Moose-dev] Re: ConfigurationOfMetacello and OB

by StÃ©phane Ducasse

On Mar 4, 2010, at 8:27 PM, Lukas Renggli wrote: > Also why are Apparently looking at http://code.google.com/p/pharo/issues/detail?id=2015 > > - Utilities changeStamp Author>>changeStamp > - Utilities timeStampForMethod: StringHolder>>timeStamp ??? http://code.google.com/p/pharo/issues/detail?id=2110 > - SystemNavigation allMethodsNoDoitsSelect: > > gone and what is their replacement? > > All in all I noticed a huge performance boost. So this is really cool :-) I'm dead/exhausted going bed now.....pfff cloud of smoke stef disappear from office pffff reappear in bed....

March 4, 2010

Re: [Pharo-project] [Moose-dev] Fwd: Re: ConfigurationOfMetacello and OB

by StÃ©phane Ducasse

> > There is a large number of deprecated code that OB is calling. What am > I supposed to do so that OB continues to work in Pharo 1.0 and 1.1? > Can I expect that people have the deprecated warnings disabled? > > - How are menus registered? TheWorldMenu does not exist any longer. alain will reply have a look at the <worldmenu> pragma menuCommandOn: aBuilder <worldMenu> (aBuilder group: #SystemChanges) parent: #CodeRecoveringTools; with: [ (aBuilder item: #'Change Sorter') action:[self new morphicWindow openInWorld]; icon: self taskbarIcon. (aBuilder item: #'Recover lost changes...') action: [ChangeList browseRecentLog]] We should start writing a doc. > - What is the replacement for #intialExtent? defining it in the model ? Stef > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

March 4, 2010

Re: [Pharo-project] about code formatting in pharo

by Adrian Lienhard

+1 On Mar 4, 2010, at 19:10 , Dale Henrichs wrote: > It is obvious that a consensus will not be reached on the "one and only true format." > > If my browser displays code formatted the way I want to see it and the difference tools are format neutral (i.e., the source and target code is formatted using the same rules) there is no need to agree on a standard style. For all intents and purposes each developer's favored format _is the standard_. > > We only need to agree to disagree and then figure out how to make it possible to customize the formatter and resolve any other technical details (performance and others) that are deemed important. These are technical problems with technical solutions. > > Dale > ----- "Chris Muller" <asqueaker(a)gmail.com> wrote: > > | > Another visual problem with "[" and "]" is that they are but one > | > character, and if you place them together with something else, like > | > "[self", they lose their visual identity (btw, we read words in > | chunks > | > not by characters) and get harder to spot. It's true that some fonts > | > and extra coloring could solve this problem, but whitespace is > | always > | > the best and least invasive design weapon. > | > | Tudor, for what its worth, the white-space surrounding the blocks is > | not really at issue or discussion here. It's about formatting blocked > | code into rectangular shapes. > | > | In fact, I agree with you about your point about the whitespace. IOW, > | I prefer: > | > | someVar = someValue > | ifTrue: [ self doOneThing ] > | ifFalse: > | [ self > | doOtherThing ; > | doYetAnotherThing. > | anotherObject doSomething ] > | > | Not: > | > | someVar = someValue > | ifTrue: [self doOneThing] > | ifFalse: > | [self > | doOtherThing ; > | doYetAnotherThing. > | anotherObject doSomething] > | > | Perhaps if you looked at a longer method example, with nested blocks, > | you might be able to "see", visually, the blocks more obviously. > | Perhaps not, I don't know. > | > | Regards, > | Chris > | > | > The lines are clearly belonging together, [ is clearly observed and > | > clicking anywhere on the first line after [ will select the whole > | block. > | > > | > Yet another thing it solves is the consistency between block and > | > method. They both define behavior, and thus it would be great if > | they > | > would be treated similarly. This is better seen in the context of a > | > block with parameter: > | > > | > aCollection do: [ :each | > | > self something. > | > self somethingElse. ] > | > > | > Just like a method has the top line with the signature and the > | > parameters, a block should be the same. In this case, each is a > | > parameter and it is clearly distinct from everything else. When > | there > | > is no parameter, this is information made very clear, too (because > | of > | > the absence of anything following [ ). > | > > | > > | > An argument against this convention was that it looks like C and > | that > | > blocks are not dumb {. While I understand the built-in adversity, we > | > are talking about a visual notation that makes sense for Smalltalk > | and > | > not one that make it different from everything else around us. > | > > | > Another option would be to have: > | > boolean ifTrue: > | > [ self clearCaches. > | > self current soleInstance yada yada blah blah > | > self recomputeAngle ] > | > > | > with everything inside the block being aligned. However, this has > | the > | > problem of wasting space. One space can also be used, but only when > | > the font is monospaced, so it would not work in general. > | Furthermore, > | > it would be inconsistent or even more space wasting when it comes to > | > blocks with parameters. > | > > | > Cheers, > | > Doru > | > > | > > | > On 4 Mar 2010, at 03:38, Chris Muller wrote: > | > > | >>>> ifTrue: [ > | >>>> line1 yo. > | >>>> line2 eh ] > | >>> > | >>> Horrible, horrible, horrible ;) Poor block. The block is an > | >>> object... > | >> > | >> Exactly what I was thinking; and how some of the new editor > | features > | >> since 3.9, that seem to reify "statements". For example, clicking > | >> inside parens or square-brackets selects that statement(s). I also > | >> really enjoyed the ability to "surround", thereby creating > | additional > | >> statement-levels. > | >> > | >> The whole interaction becomes much more liked working with tiled > | code > | >> rather than a text-editor. > | >> > | >>> I think the conclusion has to be (and I can confirm that the > | >>> VisualWorks > | >>> team was equally divided) that no one formatting regime will make > | >>> every one > | >>> happy and that all regimes will make a substantial minority > | >>> unhappy. So > | >>> perhaps we should step up to having code formatted automatically > | >>> according > | >>> to tailorable preferences. > | >> > | >> > | >> > | >>> My only concern is comment formatting but the way to deal with > | that > | >>> is to > | >>> use automatic formatting and deal with comment problems as they > | >>> arise. I > | >>> always used to be concerned about e.g. comments spanning multiple > | >>> lines. > | >>> But without day to day exposure I don't think one can know how > | >>> much of an > | >>> issue it is. > | >> > | >> As someone who's logged 5-digits of hours in Squeak these last few > | >> years, I think the best thing is to just not. Let 'em wrap! Use > | >> shout to turn them light gray, so they don't really intrude on the > | >> code, but are there if you want focus on the extra prose. > | >> > | >> Unfortunately, the real problem with comments within BlockNodes is > | how > | >> they duplicate themselves within the parse-tree.. ouch! I hope > | that > | >> is what you and Nicolas were talking about or that you'll have a > | fix > | >> for that.. > | >> > | >>> One upside will be less effort reformatting when indent levels > | >>> change. Have > | >>> you noticed that Smalltalk tends to be more difficult to reformat > | >>> than C > | >>> syntax languages, I guess because of keywords? Not having to > | worry > | >>> about > | >>> this could be great. > | >> > | >> Very cool, I hope there'll be enough additional consensus to adopt > | >> these Beckian formats for Squeaks pretty-print refinement. > | >> > | >>> Of course, what format gets written to a source file could still > | be > | >>> a source > | >>> of conflict ;) We may all want our syntax to be the format of > | >>> record :) > | >> > | >> Absolutely. To not, would be the machine dictating to the user. > | >> Invoking automatic formatting is always the users choice. > | >> browseWithPrettyPrint allows readers to have it formatted > | dynamically > | >> if they wish.. > | >> > | >> Cheers.. > | >> > | >>> P.S. and don't get me started on the trailing period (putrid > | >>> excressence), > | >>> or the space between ^ and the return expression (vomitous mass). > | >> > | >> _______________________________________________ > | >> Pharo-project mailing list > | >> Pharo-project(a)lists.gforge.inria.fr > | >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | > > | > -- > | > www.tudorgirba.com > | > > | > "Live like you mean it." > | > > | > > | > _______________________________________________ > | > 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

March 4, 2010

Re: [Pharo-project] About danny help :)

by Danny Chan

> > > I am not sure what you mean by modular. It has a Metacello configuration. > > my point is if you imagine that we want a small system with good packages > where do we put the helpSystem. Hm, still not 100% sure what you mean. If you're asking how we can have documentation usable with HelpSystem without having to actually load HelpSystem, then see below. > > > A nice idea on squeak-dev was to add support for a simple structured > > markup language like Markdown in class comments. We could use this to > > write "big- picture" documentation directly in a class comment. I think > > this would complement the method comments quite nicely. > > Do you have an example? > In a package you put in the most important class a comment that looks somehow like this: <classcomment> Here comes the comment for the class </classcomment> <packagecomment> This is the documentation for MyPackage. # Introduction A bit of introduction. # Another chapter More text. ## Structure You can have sub levels And this would create a documentation tree like this (text after the colon is displayed in the content window): - MyPackage: This is the documentation for MyPackage. - Introduction: A bit of introduction - Another chapter: More text - Structure: You can have sub levels - API documentation - Class1 documentation - Instance Methods - Class Methods - Class1 documentation - Instance Methods - Class Methods ... Now you have all the documentation for a package in the comments, but you can view it in a nicely structured way. Does this make sense? Danny

March 4, 2010

Re: [Pharo-project] [Moose-dev] Re: ConfigurationOfMetacello and OB

by StÃ©phane Ducasse

> Also why are > > - Utilities changeStamp > - Utilities timeStampForMethod: we forgot to deprecate them.... shame on us. Probably in Date > - SystemNavigation allMethodsNoDoitsSelect: > > gone and what is their replacement? > > All in all I noticed a huge performance boost. So this is really cool :-) > > Lukas > > On 4 March 2010 20:21, Lukas Renggli <renggli(a)gmail.com> wrote: >> Sorry, forgot to add the Pharo list ... >> >> ---------- Forwarded message ---------- >> From: Lukas Renggli <renggli(a)gmail.com> >> Date: 4 March 2010 20:13 >> Subject: Re: [Moose-dev] Re: ConfigurationOfMetacello and OB >> To: Related to the development of Moose and other related tools >> <moose-dev(a)iam.unibe.ch> >> >> >> I am looking into this. I reply to the Pharo list, I think the Moose >> list is the wrong one. >> >> The refactoring engine seems to work well. All tests pass. >> >> OmniBrowser is more difficult. There are 7 tests failing, and there >> are 8 errors. >> >> There is a large number of deprecated code that OB is calling. What am >> I supposed to do so that OB continues to work in Pharo 1.0 and 1.1? >> Can I expect that people have the deprecated warnings disabled? >> >> - How are menus registered? TheWorldMenu does not exist any longer. >> >> - What is the replacement for #intialExtent? >> >> Cheers, >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> > > > > -- > 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

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by Adrian Lienhard

Hi Jorge, Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! Cheers, Adrian On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: > Hi Adrian, > > Yep, I have the same problem as you. My idea was to make it work as > before without completely changing it. Basically because I did not > have the test support to validate my changes. > Anyhow, what I propose is to write a bunch of tests for every case > that we know and then if new cases show up add them to the test suite. > And then play with the code. > > I will work on that today, is that ok? > > For the explanation of what is going on is that now node can be an > instance variable node, then the behavior that was there was not > appropriate in the sense that instance variable nodes do not > understand #scope. > However, why this validation "(node isTemp or: [requestor > interactive])" was there in the first place is not that clear to me, > but it's been there since 1999. > > I'll try to build the tests and come up with a better solution. > > Cheers, > > Jorge > > On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> Jorge, >> >> I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? >> >> This is the code: >> >> "When non-interactive raise the error only if its a duplicate" >> (node isTemp or: [requestor interactive]) >> ifTrue:[ ((node isTemp) and: [node scope <= 0] ) >> ifFalse: [^self notify:'Name is already defined' ]] >> >> Cheers, >> Adrian >> >> On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: >> >>> 11243 >>> ----- >>> >>> - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed >>> Problem fixed: >>> We cannot have twice the same block arg in a method >>> >>> [:each | each ...] >>> [:each | each ...] >>> >>> THANKS jorge :) >>> Do you like good bio beer? >>> >>> Stef >>> >>> >>> _______________________________________________ >>> 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

March 4, 2010

Re: [Pharo-project] [1.1] Object>>initialExtent

by StÃ©phane Ducasse

The user interface or the model should define the initialExtent I do not understand why 1 initialExtent makes sense. We have to define initialExtent to some model. Stef > I ran into this as well. I tried to avoid triggering the deprecation, > to see if the model understood initialExtent before sending it and > guarding for nil models and things like that. otherwise just > dispatching to the default extent, however this is difficult because > all objects understand initialExtent! i needed a method > respondsToButNotInObject:... at that point I got distracted. it is > ugly to do this deep respondsTo: check so I was not sure what the > correct way of approaching this deprecation was. I assumed someone had > a nice solution when they deprecated it? > > Mike > > On Thu, Mar 4, 2010 at 5:49 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> Hi! >> >> I do not have a solution, but Object>>initialExtent was recently >> deprecated and this causes great usability problem. This deprecation >> is very valuable for a clean UI separation. However, I have a warning >> deprecation each time a window is open. The reason stems from the >> method: >> >> SystemWindow>>initialExtent >> ^ model initialExtent >> >> For now, in my image, I suppressed this deprecation. >> Again, I do not have a clean solution. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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

March 4, 2010