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.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
