Repackaging?

Before I go reinvent the world, anyone have something like the
following instance method of Package

    repackage: aPackageNameSymbol

   "Changes each class, resource, global, script, loose method
    owned by the receiver to be owned by the package named by
    the symbolic parameter (e.g., #Dolphin) indicated by
    aPackageSymbol.  If the package aPackageSymbol does not
    exist it is created in the default directory."

One could provide the more complete

    repackage: aPackageNameSymbol ifAbsentUseDirectory:
aDirectoryPathString

and represent the above as

    repackage: aPackageNameSymbol
       ^self repackage: aPackageNameSymbol
             ifAbsentUseDirectory: File workingDirectory.

Failing any such thingy, it looks like if one moves a class from one
package to another, its methods are _not_ automatically moved, but
must be moved one at a time.  Is that true?  If so, then it seems
a safe way to proceed is to move all the class and instance methods
to the new package first, and then follow them by the class.

--
---------------------------------------------------------------------
 Jan Theodore Galkowski                    [hidden email]
 The Smalltalk Idiom                       [hidden email]
*********************************************************************
             "Smalltalk?  Yes, it's really that slick."
---------------------------------------------------------------------
Want to know more?  Check out
           http://www.dnsmith.com/SmallFAQ/
           http://www.object-arts.com/DolphinWhitePaper.htm
           http://st-www.cs.uiuc.edu/users/johnson/smalltalk/
*********************************************************************

Jan Theodore Galkowski wrote:
>
> Before I go reinvent the world, anyone have something like the
> following instance method of Package
>
>     repackage: aPackageNameSymbol

Should probably be

      repackageIn: aPackageNameSymbol

instead.

Should be

      repackageIn: aPackageNameSymbol
         ifAbsentUseDirectory: aDirectoryPathString

instead.
>
> and represent the above as
>

[snip]


    repackageIn: aPackageNameSymbol
        ^self repackageIn: aPackageNameSymbol
              ifAbsentUseDirectory: File workingDirectory.

>
> Failing any such thingy, it looks like if one moves a class from one
> package to another, its methods are _not_ automatically moved, but
> must be moved one at a time.  Is that true?  If so, then it seems
> a safe way to proceed is to move all the class and instance methods
> to the new package first, and then follow them by the class.
>

[snip]

--
---------------------------------------------------------------------
 Jan Theodore Galkowski                    [hidden email]
 The Smalltalk Idiom                       [hidden email]
*********************************************************************
             "Smalltalk?  Yes, it's really that slick."
---------------------------------------------------------------------
Want to know more?  Check out
           http://www.dnsmith.com/SmallFAQ/
           http://www.object-arts.com/DolphinWhitePaper.htm
           http://st-www.cs.uiuc.edu/users/johnson/smalltalk/
*********************************************************************

Jan,

Do you really want to do this programmatically (maybe you're writing an
application that reorganises packages?) or are you just trying to find a
quick way of moving classes manually between packages. If it's the latter
then drag/drop in the PackageBrowser, which works for classes, loose methods
and AFAIK globals, is the easiest way I know of.

> Failing any such thingy, it looks like if one moves a class from one
> package to another, its methods are _not_ automatically moved, but
> must be moved one at a time.  Is that true?

How were you moving the class?. If you use the ClassBrowser to change a
class' package then all the methods that were in the same original package
as the class are moved as well.  If you were programmatically changing the
package for a class then it depends on how you were doing it but ...

PackageManager current
    renamePackage: (PackageManager current packageNamed: 'AvatarChat')
    to: 'Fred'

... seems to do what you want?

Ian

Ian Bartholomew wrote:
Ian,

No, I did not mean to imply there was anything at all wrong with
Dolphin.
There isn't.  But you solved my problem:  I didn't think of
drag-n-drop,
being a shell sort of guy.  The query about whether the methods move
with their package is what I came up with after looking at the
enumerators,
adders, and removers of Package.

> PackageManager current
>     renamePackage: (PackageManager current packageNamed: 'AvatarChat')
>     to: 'Fred'
>
> ... seems to do what you want?

Let me explain:  I just want to put several packages of things like
SUnit, T-Gen, and QSoul together in one after I've loaded them.
This would let me develop parts of an application in separate .pac
files then combine them into one at the end.  I know there's an
interdependency capabilty, but I haven't mastered that yet and,
besides, it's likely I won't need it.


  --Jan






[snip]



--
-----------------------------------------------------------------------
 Jan Theodore Galkowski        °o°          
[hidden email]      
 http://www.scguild.com/usr/1707I.html              [hidden email]
***********************************************************************
             "Smalltalk?  Yes, it's really that slick."
-----------------------------------------------------------------------
    Check out http://st-www.cs.uiuc.edu/users/johnson/smalltalk/,
              http://www.object-arts.com/DolphinWhitePaper.htm
              http://www.dnsmith.com/SmallFAQ/
***********************************************************************