[squeak-dev] Re: Environment's #classNamed:

Chris Muller asqueaker at gmail.com
Sun Dec 22 20:48:15 UTC 2013


On Sun, Dec 22, 2013 at 1:09 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 22 December 2013 18:16, Chris Muller <asqueaker at gmail.com> wrote:
>> Yes, I had already gone back and read that several days ago when I
>> made the decision to finally get into Environments.  That thread is a
>> gem for getting started understanding Environments.
>>
>> Colin, Environments is exactly how I think the namespace problem
>> should be solved -- I see it as dynamic renames during loading time
>> (vs. a grand global namespace like Java).  Kudos for bringing this to
>> life.
>>
>> What still remains a mystery (for me) is why we need this extra
>> complication -- e.g., why can't I simply _import_ from other
>> Environments.  Instead, I can only import from other Environments what
>> I've declared as their _exports_.
>>
>> This does not seem to be in the spirit of Smalltalk -- having to
>> "declare" the class-API's before I can use them.  I have to keep these
>> two things "in-sync" with each other:  An Environments exports with
>> the other environments imports.
>>
>> It reminds me somewhat of static-typing in that it's simply a "chore"
>> I have to do for the satisfaction of the computer but no real benefit
>> (that I can identify) for the developer...
>
> This is way off topic for the thread. You need to try out Haskell or
> OCaml, because it sounds like you've not used a language with a decent
> static type system. A static type system provides you with axioms,
> letting you prove certain properties of your system. Or: programming
> in the type system is proof writing. Static typing is an
> extraordinarily powerful tool. C++ and Java's type systems are a joke,
> so if that's all you've used, I can understand why you might not see
> much benefit to a static type system.

Indeed, Java is the only statically typed system I've used in at least
a decade.  But the proof-writing property you mentioned about good
static typing systems sounds very interesting and a great benefit.

In the context of the Xtreams paragraph here:

  http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-June/164605.html

================
"An interesting example of this case that I've run across lately is
Xtreams. In the original VW version, there's only one class that's
publicly visible: the Incomplete exception that gets raised when a
stream operation fails. The rest of the public API to the library is
provided as extensions to classes in the base system. There's actually
no need for code that uses Xtreams to refer to any of the stream
classes. That leaves a lot of room for the implementation of Xtreams
to change while keeping the API stable, and I'd like to be able to
take advantage of this design in Squeak. With Environments, that's
possible: we just create an environment to hold the Xtreams classes,
import the base system, compile Xtreams, export Incomplete, and import
Xtreams into our application's environment."
==================

The last sentence enumerates how Xtreams would be made to co-exist
with Squeak, and says its only declared class, Incomplete, should be
exported.  I was just trying to understand whether the export
requirement/capability is actually enabling some use-case that
wouldn't otherwise be enabled.  Obviously, I don't fully grok
Environments yet..


More information about the Squeak-dev mailing list