February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by Tudor Girba

Hi, On Tue, Feb 24, 2015 at 8:57 AM, stepharo <stepharo(a)free.fr> wrote: > Doru and Yuriy > > String is not a good API for reflective operations. This is what you are > doing with asPackage. > When I want to access to a class I do > Class > or Smalltalk globals classNamed: 'Point' > As I said, there is already a String>>asClass. It seems that since it was introduced, people prefer to send Gofer scripts like: #ConfigurationOfXYZ asClass loadDevelopment instead of: (Smalltalk globals classNamed: 'ConfigurationOfXYZ') loadDevelopment a compile method Point>>#x > and not 'Point?x' asCompiledMethod > I think this is not quite the same: one is interpreting a notation and one is looking something up by name. > I would prefer to have Package named: 'jkljk' than the string behavior. > RPackage named: 'XYZ' already exists in the image and is a constructor that returns a new package object without looking it up in the organizer. Perhaps we can add RPackage class>>#@: RPackage @ 'XYZ' Yet, even in that case, working with this would require parentheses: (RPackage @ 'XYZ') linesOfCode I still somehow think that from a reader's point of view, this is more nice: 'XYZ' asPackage linesOfCode and what if I want to reflect on code that is remote? > Package named: 'aaa' would not solve that problem either. Still it would be reasonable solution would be Ok So I maintain that we are polluting String with reflective operations that > it should not have. I see the point, and I would definitely like to have a first class support for important objects like packages. However, I think the problem is not so black and white. I see string extensions like this as a convenience that enables cheap fluent interfaces. For example, PetitParser relies on this pattern quite successfully. I can delete it from the system if it's so decided, but then we should also remove #asClass. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Feb. 24, 2015

Re: [Pharo-dev] Issue 12970 - 16 steps to get through #halt - PROPOSED FIX

by Marcus Denker

> On 24 Feb 2015, at 15:21, Ben Coman <btc(a)openInWorld.com> wrote: > > All, > > Please take a moment to comment on how you like the current behaviour of executing the following snippet then <Step Over> three times to get to the line c := 3. > > a := 1. > self halt. > b := 2. > self halt. > c := 3. I like the new behaviorâ¦ it seems to work fine. The solution is now very special to this caseâ¦ I wonder if it can be differently (but I have no idea of any). So I vote for adding itâ¦ we can always improve later. Marcus

Feb. 24, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by Sean P. DeNigris

stepharo wrote >> I wonder why we do not just late-bind global access. > ...and to me this is better than poor string. Yes!!! This would be really nice. It's one of those gotcha places where the system isn't quite turtles all the way down, like optimized methods that you can't override. It would be great for testing to be able to inject for example a stub class for the real class, but right now that's pretty hard and error prone bc IIRC you have to go down into he literal array of the compiled method. ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-3fabea-40497-tp4806951p48072… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 24, 2015

Re: [Pharo-dev] Issue 12970 - 16 steps to get through #halt - PROPOSED FIX

by Ben Coman

All, Please take a moment to comment on how you like the current behaviour of executing the following snippet then <Step Over> three times to get to the line c := 3. a := 1. self halt. b := 2. self halt. c := 3. cheers -ben

Feb. 24, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by stepharo

> > I wonder why we do not just late-bind global access. They have something in that vein in VW: literal binding or something like that and to me this is better than poor string. Stef

Feb. 24, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by stepharo

> Thatâs close to one of the first thing I tried when I started with Pharo, and I liked it (you didnât back then ;) ). ;) > Packages were globals (so no dashes in their name unfortunately) and answered #import: #import:as: #load #unload #@â¦ > Each package was defining an environment for its classes and this environment had a ThisEnvironment binding pointing to itself. > You could change imports with statements like: > ThisEnvironment import: SomePackage @ #SomeClass as: #LocalName. > > The only difference with what Marcus suggests is that packages didnât have business-level behavior. > If you want that, nested classes sound like a good solution since in that context both packages and classes define behavior and are instanciable. So it worth unifying both concepts. > I tried that also, but first itâs much more difficult to implement cleanly (I remember that I had to rely on many little hacks to make it work) and then it's a huge paradigm shift we canât afford (basically transforming Pharo into Newspeak). > If we were writing a new language I would say yes, go for nested classes, but integrating into them into Pharo, no. > And in the end, not many packages offer a stand-alone service like Compiler does. So instead, having one class in a package that acts as a facade is good enough to me. agreed with you >> I would be curious to see what is happening in the context of Conch (the module system of camille). >> He should present it to us too. > Conch is about local extension methods, not about global variables. > Dealing with globals is much simpler, partly because the problem itself is simpler, partly because the infrastructure is already there: classes answer to #environment and thatâs what is used during compilation instead of 'Smalltalk globals'. > >> But we would need somebody to work on the tools. > Yes, thatâs the difficult part for any language extension. And code migration... > >> Now for me what I would prefer is to have a kernel in which class have a direct pointer to their packages like for their super/subclasses. > Classes already have an #environment and it does the job. > Of course, we could rename it to #package if we all agree that to one package corresponds one environment. > > Camille > >> Stef >> >> >> Le 24/2/15 08:01, Marcus Denker a Ã©crit : >>>> On 24 Feb 2015, at 07:49, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>> >>>> Just my 2 cents: >>>> >>>> I find this really useful and have already implemented this extension in a couple of my packages, as writing: >>>> >>>> RuleChecker check: (RPackageOrganizer default packageNamed: âKernelâ) >>>> >>>> is much worse than: >>>> >>>> RuleChecker check: âKernelâ asPackage >>>> >>>> >>> Sometimes I wonder if Packages should not be part of the Smalltalk globals namespaceâ¦ >>> >>> e.g. packages could have a nice reflective API: >>> >>> MyPackage unload. >>> >>> and even an API for usingâ¦ e.g. a Compiler has a very tiny surface API: >>> >>> OpalCompiler compile: ââ¦.â >>> >>> (but I do not really like nested classes, which is what people will now suggestâ¦) >>> >>> Marcus >>> >> > >

Feb. 24, 2015

Re: [Pharo-dev] MCVersionInfo: 10% of the image

by Marcus Denker

> On 20 Feb 2015, at 18:11, Chris Muller <asqueaker(a)gmail.com> wrote: > >> Chris, didn't you do something about this in Squeak? It would be nice to keep consistent if possible... > > Yes, but no one liked it because it employed the Proxy design-pattern > and requires a become. Perhaps if I'd gotten it perfect the first > time it'd have been better-received. But, I didn't, and the ensuing > backlash wiped out any motivation for me to fix it. > This is always the dangerâ¦ I start to be very careful in this regard: better make (and allow!) mistakes than doing nothing. Because mistakes can be fixed, while a discouraged person will just never do anything. (e.g. leave the project in case of open source). Of course #become: sadly get really slow when the image gets largeâ¦ but this is fixed with Spur, which means it will possible. > Marcus' suggestion is more explicit, and so might be better received > by the community. There's a tradeoff between the two designs: In my > design, you have to make sure you get it right or the image could lock > up. In Marcus' design, you have to sprinkle multiple checks for > #reload in the code and make sure you get it right, or you might end > up saving corrupt MCZ packages (e.g., with #reload as the ancestry). > Yes. I think the only reason I dared to let me think in this direction is that the #ancestors are accessed *only* via the accessorâ¦ but nevertheless: checks need to be added. > Either way, its a wasteful part of the design of MC that should be > addressed. I'm partial to fixing the Proxy solution, but I'd be in > favor of ripping it out and adopting a stable alternative from Pharo > if it becomes available. > We could do it in two steps: adopt the #become: solution when we use spur 100%â¦ I even want to have a default Proxy framework in the system to make these things easier. (something like Ghost). Marcus

Feb. 24, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by Camille

> On 24 Feb 2015, at 13:22, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> >> Yes why not. The question is: late-bind onto whom? >> Since bindings can be changed without recompilation, Iâm not sure that late-bound global have a lot of added value. >> > In the sense that I can write > > MyNonExistingClass new. > > and get a runtime error. Yes true. > > Marcus > >

Feb. 24, 2015

Re: [Pharo-dev] about dark theme

by phil＠highoctane.be

Check the rubric cursor color in the prefs as this may be the reason why. On Tue, Feb 24, 2015 at 1:13 PM, stepharo <stepharo(a)free.fr> wrote: > just some feedback because I was forced to use it because the projector > quality was not great. > and now I cannot use it on my machine :) > the caret is black as well as the window cross and it is really > difficult to see them on my machine. > > Stef >

Feb. 24, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by Marcus Denker

> > > Yes why not. The question is: late-bind onto whom? > Since bindings can be changed without recompilation, Iâm not sure that late-bound global have a lot of added value. > In the sense that I can write MyNonExistingClass new. and get a runtime error. Marcus

Feb. 24, 2015