Re: [Help-smalltalk] lessons from the python environment

[Robert Collins]

On Tue, 2004-09-07 at 17:36 +1000, Bruce Badger wrote:
> Just a couple of questions ...
> 
> On Tue, 2004-09-07 at 14:34, Robert Collins wrote:
> > The nice thing here is that the is an automatic Namespace creation:
> > import foo.bar
> > will look in the search patch for a directory called foo (with a
> > __init__.py file), parse that **into a new namespace 'foo'**, and then
> > if there is no bar symbol in the foo namespace, try to file in
> > foo/bar.py.
> 
> Can name spaces be nested?
> 
> Would "import tom.dick.harry" nest a dick namespace inside of tom and
> then look for a harry.py? 

yes. and harry would be either a package or a module (a heuristic I'm
not suggesting we carry over).
i.e.
first tom is resolved:
tom/__init__.py
then dick
tom/dick/__init__.py
and then if there is no harry symbol in tom.dick, it looks again:
tom/dick/harry/__init__.py OR
tom/dick/harry.py

will match.

> > A default search path might be: the kernel directory, ~/smalltalk-
> > packages, /usr/share/gnu-smalltalk, /usr/share/gnu-smalltalk/site-
> > packages
> 
> This looks rather like a Java class path, i.e. an ordered collection of
> roots.  It that right?

I'm not 100% sure what a classpath's semantics are, but I'd presume -
yes.

> If so, is this list searched in the order shown? 

Yes.

>  Then, is the search
> always from the top of the list, or does searching resume at the root
> within which something was found (or where the last cycle looking for
> something that was not found completed)?

I don't know the python formal semantic on this... but I think its
always from the top. i.e. if you find 'tom' in ~/smalltalk-packages/tom,
then when you look for tom.dick, you start at the smalltalk-packages,
find tom/ as a package, and only look within tom/ for dick. That said,
one of the things I didn't like about smalltalk was the inability to
have tom.dick in my home dir, and tom.harry in the official distro, and
have import just do the right thing. Thats something we might want to do
differently.

> > This is particularly useful as you get third party modules, because they
> > can be trivially dropped on disk, and it all just works. The presence of
> > vm images only slightly reduces the utility: anyone working on a package
> > that needs to run as a script will appreciate this hugely.
> 
> There can be name conflicts here though, right?  So more than one root
> could contain tom.dick - so, how are conflicts handled, or how are they
> prevented?

in python there is only one path to dick. And that is wherever tom is
found, dick must be under that root.

> > editor-bindings:
> > we already have an emacs mode, but AFAIK thats the only editor we have
> > bindings too. Having (for instance) a vim-smalltalk, which can use gnu-
> > smalltalk as a coprocess could allow use to do something similar to what
> > 'BicycleRepairMan' does. BRM is a refactoring toolkit for python, that
> > is able to be called into from vim, idle & emacs. Given the attachment
> > folk tend to get to their editor, allowing more folk to code in their
> > preferred environment, AND leverage smalltalk & the smalltalk tools in
> > their image would be fantastic. I think we are on the right path here
> > already.. just making a note of this.
> 
> FWIW I tend to prefer editors that run within the Smalltalk image as
> they tend to allow one to do things like immediately evaluate code
> fragments.  External editors may be more powerful at manipulating large
> bodies of text than most Smalltalk editors (in fact, I'm sure they are),
> but in Smalltalk the bits of text being edited tend to be small, and the
> tight link between editor and environment is a good trade-off, I find.
> 
> Choice is good, though :-) 

vim-python, which was my example, allows immediate evaluation of python
code fragments... the hypothetical vim-smalltalk would likewise allow
smalltalk code fragment evaluation.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

signature.asc
Description: This is a digitally signed message part