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

[Bruce Badger]

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? 

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

If so, is this list searched in the order shown?  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)?

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

> 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 :-) 

> refactoring:
> I think gst suffers quite a bit not having a refactoring browser at the
> moment. The sheer beauty of the language saves us. That said the python
> community at large seems rather ignorant of refactoring: BRM is by no
> means a common tool there, for all of its utility. One of the
> opportunities I see for gnu-smalltalk is to be a scripting-language ..
> with a ref-browser out of the box.

Having the RB in G/ST would be brilliant!

I will say, though, that if we are talking about bringing some of the
more powerful GUI tools to G/ST, I'd rather see the an interactive
debugger first.

> If we can make quick-n-dirty scripting easy to do using smalltalk, I
> think it could really become useful to a bunch of folk that have been
> scared off by the impression that its just a gui environment for
> learning stuff in! (I've been told that by several folk ?!?). 

Scripting would be very welcome indeed.  This point has also been
recognised by the VisualWorks people, BTW.  VW 7.3 is slated to have a
scripting capability ... but it might slip into 7.4.

All the best,
        Bruce
-- 
Make the most of your skills - with OpenSkills
http://www.openskills.com

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