Environments

Otto Behrens wrote:

Thanks for the responses.

The Monticello publishing tools from VisualWorks appears to be an
option, although from Holger's message it does not appear to be plain
sailing. Once again, the namespacing problem is there. The easiest
route appears to be avoiding explicit namespaces references in a
method and to use the imports to determine which class to reference.
We can then monkey around with the GS symbol list when compling a
method to get hold of the appropriate class. ?

That seems to be an approach that holds promise ... If SymbolLists _can_ be used to faithfully reproduce the VW namespaces, then it becomes  a tool issue to manage the swapping in and out of SymbolLists ...

On Tue, Sep 28, 2010 at 9:18 PM, Dale Henrichs <[hidden email]> wrote:

Jon Paynter wrote:

Otto, Dale,
 Using a gemstone SymbolDictionary to represent a namespace in VW works
quite well when setting up your applications.  The only drawback you will
run into is you cant use the "dot" notation to reference other classes:
 NamespaceA.ClassName.  I found I had to use "NamespaceA at: #ClassName" in
order to get at classes
 The other issue you may run into is lack of support for a tree of
namespaces.  Im not sure if SymbolDictionaries allow for nesting -- Im sure
Dale can shed some light on that.
Jon.

Thanks Jon. SymbolLists are composed of a list of SymbolDictionaries, so no
nesting of SymbolLists within SymbolLists are allowed ... so any tree
structures would have to be flattened...

Dale

On Tue, Sep 28, 2010 at 10:10 AM, Dale Henrichs <[hidden email]
<mailto:[hidden email]>> wrote:

  Otto,

  I'm not familiar with VW namespaces, so I'm somewhat shooting in the
  dark here:)

  You should be able to define a SymbolList per namespace, building
  the list of namespeces although I guess that depends upon the
  details of the vw imports implementation...

  #compileMethod:dictionaries:category: takes a SymbolList not a
  SymbolDictionary, so by monkeying with Behavior a bit, you could
  arrange to pass in the correct symbollist for the class when
  compiling methods...

  Pool dictionaries are supported in GemStone, you just don't see them
  alot, the arg to #compileMethod:dictionaries:category: is probably
  "constrained" to be a SymbolList though...

  Dale


  Otto Behrens wrote:

      Hello,

      We would like to port a lot of code written in VisualWorks to
      GemStone. The idea is that we keep the code running in
      VisualWorks and
      in GemStone. In the same way that we are currently running a
Seaside
      application in Squeak and in GemStone. Any comments on this? Are we
      nuts? (Rhetorical Question)

      One preferable outcome is that, since we have to work with
      VisualWorks
      for quite some time, we can still manage source in Store. An
      option is
      to use the GemKit tools and then create another set of classes
      that is
      dedicated to GemStone. We are trying to avoid this by keeping
      one set
      of packages that will work in VisualWorks and GemStone.

      So, we are on a track to compile packages filed out from
VisualWorks
      (xml format) into Pharo and then GemStone. We something to work,
but
      guess what? Stuck on Namespaces. We will have to handle imports and
      all of that properly.

      We got the initial stuff to (sort of) work in Pharo 1.1, with some
      name mangling (eg. Namespace_ClassName). This can sort of work, but
      not without pain as you can imagine.

      I loaded Environments
      (<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.squeaksource.com/Environments.html" target="_blank">http://www.squeaksource.com/Environments.html)
      and looked at getting the thing going with that. (Will need to
      change
      Namespace.ClassName to Namespace ClassName when compiling, or
change
      the code to just use imports). Shared environments can work nicely
      here. OK?

      I had a look at how this could work in GemStone. Can
      poolDictionaries
      do the trick?

      One thing that puzzles me is that although
      #compileMethod:dictionaries:category: on Behavior takes a
      SymbolDictionary, possibly including poolDictionaries, I can't
      find a
      sender that passes anything but "GsSession currentSession
      symbolList",
      which excludes poolDictionaries. Are poolDictionaries still alive
in
      GemStone?

      I'll be grateful for any help or pointer in a direction.

      Thanks
      Otto