> On 24 Feb 2015, at 08:18, stepharo <steph...@free.fr> wrote: > > Interesting idea. > We should have a guy trying.
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. > 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.tymc...@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 >> > >
