Package question

Blair,

Given the darts (unjustly) thrown at the package manager recently, I hate to
even bring this up.  However, it would be worse to say nothing.

In working on the menu timeout, I found a method that was packaged loose in
D4, but ended up packaged in MVP Base in D5.  It's in Presenter, as a result
of CompositePresenter's demise.  Would loose methods in CompositePresenter
lose their packaging on import into D5?  If so, are there any classes other
than CompositePresenter that I should scan for methods that lost their way?

BTW, I see related methods that are packaged correctly, so it's possible
that I errantly unpackaged the offending method at some point (seems
unlikely though).  If there is a bug involved, it appears that it would need
to be random or apply only under specific circumstances.  A crazy idea would
be that it might be caused by virtual categories - maybe something appeared
in a weak collection just long enough to cause the repackaging???

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Blair,

> BTW, I see related methods that are packaged correctly, so it's possible
> that I errantly unpackaged the offending method at some point (seems
> unlikely though).  If there is a bug involved, it appears that it would
need
> to be random or apply only under specific circumstances.  A crazy idea
would
> be that it might be caused by virtual categories - maybe something
appeared
> in a weak collection just long enough to cause the repackaging???

There turns out to be a reason why I might have unpackaged it - the method
in question makes explicit use of a timer (it's pretty old) per your
suggestion that ultimately turned into the idle-timer.  It's possible that I
was getting ready to remove the old hack and forgot about it part way though
the job.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill

You wrote in message news:b4iv4o$1ukhoo$[hidden email]...
> ...
> In working on the menu timeout, I found a method that was packaged loose
in
> D4, but ended up packaged in MVP Base in D5.  It's in Presenter, as a
result
> of CompositePresenter's demise.  Would loose methods in CompositePresenter
> lose their packaging on import into D5?  If so, are there any classes
other
> than CompositePresenter that I should scan for methods that lost their
way?

I think there is a problem with loose methods associated with classes that
have been renamed, and which have been aliased. For backwards compatibility
the global CompositePresenter in D5 points to the Presenter class, and this
allows D4 packages to be loaded, however I suspect that the methods
collection is not being updated to reflect the name change.

Thanks for reporting it.

Regards

Blair

Bill Schwab wrote:

>... Given the darts (unjustly) thrown at the package manager recently, I hate to
>even bring this up.  However, it would be worse to say nothing.
>
Here's a somewhat related question / observation.

Dolphin is very clever in detecting that if I refer
to a global (class) defined in another package, then
that package must be a prerequisite for the package
using the class.

I really like this feature since it directs me to writing
code with a 'layered architecture'. A package can not be
loaded unless all its pre-requisites already exist.
Cyclical dependencies I believe, in general are bad.

Where this fails - I think - is with loose methods.
Say I have Object>>doSomething as a loose method in
package  LoosePKG, which also includes the class
ClooseCLS which is referred to in the method #doSomething.

Now in any of my packages I can call 'self doSomething',
and thus my application will depend on the existence
of the package LoosePKG. Yet LoosePKG is not listed
as a prerequisite of any of those packages which call
'self doSomething'.

Am I right?  

Thanks
-Panu Viljamaa

panu wrote:

> Now in any of my packages I can call 'self doSomething',
> and thus my application will depend on the existence
> of the package LoosePKG. Yet LoosePKG is not listed
> as a prerequisite of any of those packages which call
> 'self doSomething'.
>
> Am I right?

You are.

Q.  Say that you had two packages that each contained a loose method
named #foo, implemented in different classes.  Which of those two
packages should automatically be included as a prerequisite for another
package that contains the line "self foo"? e.g.

Object>>foo is loose in package A
  ObjectSubclass>>foo  is loose in package B
    ObjectSubclassSubclass>>test in package C sends "self foo"

FWIW. There are a couple of ways of manually forcing a prerequiste
package.

- Go to the packages properties and add the prerequisite loose method
package to the #manualPrerequisites list.  IIRC, the loose method
scenario was probably the main reason for adding this option.

- For an automated solution you can include a Global Symbol in the loose
method's package and then reference that symbol in the dependant
package.This should force the prerequisites to be recognised. i.e.
Evaluate

Smalltalk at: #LooseMethodPackage put: 'whatever'

Add LooseMethodPackage to the loose methods package (using the global
tab)

In one of the methods in your other package reference the global.

There are a number of variations on this theme.  It's (only?) advantage
is that you can move methods between packages and not worry about
manually updating the #manualPrerequisites list.

--
Ian