Replacing method

Hello,

I need to replace a method from my image, for example ListViewColumn
class>>publishedAspectsOfInstances. I create a new package MyPackage and
place new nethod there. To remove old method I add follow in preinstall
script:

ListViewColumn class
    removeSelector: #publishedAspectsOfInstances
    ifAbsent: [].

After storing and loading MyPackage I receive
PackageManager>>errorFileInCompatibilityCheck:overlap:.

Where am I wrong???

--
Dmitry Zamotkin

Dmitry,

> Where am I wrong???

I don't think you are. The package compatibility check is performed before
any scripts are evaluated so as the method exists in the package _and_ the
image the result is a refusal to load.  Some sort of pre-preinstall script,
that is evaluated before any other tests are made, has been suggested before
but ...

There are a few, all rather unpleasant ways around it. The nicest (i.e.
least unpleasant) general technique is probably just to save the method in a
.st file and then have a line in the pre or post install script that files
in the method. Alternatives, along the same lines, include storing the
methods source in the pre-install script along with some code to compile it
when the script is executed or to have the source in a dummy method which is
then edited/recompiled to overwrite the existing method.

Another way, in this particular case, is to change the package of the
existing method from "Development System" to "Dolphin". This works as the
compatibility check doesn't complain about overwriting individual methods in
the system (i.e. Dolphin) package.

All these techniques (and there are probably others) mean a bit more work as
you have to make sure that any changes you subsequently make to the
method/image are propagated as well.

[Aside] I had a bit of trouble getting the error message you describe until
I realised that is dependant on the way you start up the image. If you
double click on a package file in Windows then the Dolphin image is
automatically started (assuming a file association) but the attempted
package load fails with a walkback - as you describe. However, if you start
the image and then try to install the package you get a much more
explanatory warning dialog - not a walkback.  I don't know if this
difference is a bug or just one of those things (tm). Andy/Blair?

Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:Lr2m7.13960$NE.983746@wards...
> Dmitry,
>
> > Where am I wrong???
>
> I don't think you are. The package compatibility check is performed before
> any scripts are evaluated so as the method exists in the package _and_ the
> image the result is a refusal to load.  Some sort of pre-preinstall
script,
> that is evaluated before any other tests are made, has been suggested
before
> but ...
>
> There are a few, all rather unpleasant ways around it. The nicest (i.e.
> least unpleasant) general technique is probably just to save the method in
a
> .st file and then have a line in the pre or post install script that files
> in the method...

Tnanks, Ian!!! I've found this method as most suitable for me. It works!!!


> [Aside] I had a bit of trouble getting the error message you describe
until
> I realised that is dependant on the way you start up the image. If you
> double click on a package file in Windows then the Dolphin image is
> automatically started (assuming a file association) but the attempted
> package load fails with a walkback - as you describe. However, if you
start
> the image and then try to install the package you get a much more
> explanatory warning dialog - not a walkback.  I don't know if this
> difference is a bug or just one of those things (tm). Andy/Blair?

Oh, yes, I tried to say about a warning dialog, not a wallback. Sorry for my
weak English...

Tnanks again,
Dmitry

Ian

You wrote in message news:Lr2m7.13960$NE.983746@wards...
>... Alternatives, along the same lines, include storing the
> methods source in the pre-install script along with some code to compile
it
> when the script is executed ...

The scripts are chunk format files, and therefore no additional code is
needed. Just drag the definition out of the class browser and drop it over
the script to create the necessary method definition chunk. In the next
release these scripts are syntax highlighted correctly, whereas in 4.0 if
one puts chunk markers then despite the fact that everything is OK they will
show up in the red colour usually reserved for errors.

As a more general point the overriding of methods with loose methods (and
especially loose methods with other loose methods, which is not currently
permitted) is, we woudl admit, an area of the package system that needs
enhancement. In particular the current system does not provide a built in
mechanism for reinstating an overridden method when a package is uninstalled
(though it can be done in the scripts by saving away the old method on
pre-install and reinstating it on post-install). I'm afraid it is the
simplest thing that could possibly work in that regard.

> [Aside] I had a bit of trouble getting the error message you describe
until
> I realised that is dependant on the way you start up the image. If you
> double click on a package file in Windows then the Dolphin image is
> automatically started (assuming a file association) but the attempted
> package load fails with a walkback - as you describe. However, if you
start
> the image and then try to install the package you get a much more
> explanatory warning dialog - not a walkback.  I don't know if this
> difference is a bug or just one of those things (tm). Andy/Blair?

I think it is probably a "bug", though not a terribly important one.

Regards

Blair

Blair,

> As a more general point the overriding of methods with loose methods (and
> especially loose methods with other loose methods, which is not currently
> permitted) is, we woudl admit, an area of the package system that needs
> enhancement. In particular the current system does not provide a built in
> mechanism for reinstating an overridden method when a package is
uninstalled
> (though it can be done in the scripts by saving away the old method on
> pre-install and reinstating it on post-install).

That reminds me of something I've been meaning to mention.  When a package's
post install script is run the installation process has not yet finished,
and all the package's "properties" (in the sense of Object>>propertyAt:)
will be thrown away *after* the script has executed.

I don't know if that's a bug or by design, but I think it'd be better if it
didn't happen.  E.g, in this case, old versions of methods could be stored
in the package's properties.  Is there any chance of such a change ?  Please
?

BTW, you once agreed that it'd be a good idea for "this" to be set to the
owning package while that package's scripts are running.  Is that still on
the cards to appear someday ?

> Blair

    -- chris

Chris

You wrote in message
news:[hidden email]...
> ...
> That reminds me of something I've been meaning to mention.  When a
package's
> post install script is run the installation process has not yet finished,
> and all the package's "properties" (in the sense of Object>>propertyAt:)
> will be thrown away *after* the script has executed.
>
> I don't know if that's a bug or by design, but I think it'd be better if
it
> didn't happen.  E.g, in this case, old versions of methods could be stored
> in the package's properties.  Is there any chance of such a change ?
Please
> ?

It is by design - the properties are used to hold temporary information
required to install the package, and this information is discarded by
deliberately destroying all properties. It is rather heavy-handed though,
and I will enter a defect report to get it changed (#362).

>
> BTW, you once agreed that it'd be a good idea for "this" to be set to the
> owning package while that package's scripts are running.  Is that still on
> the cards to appear someday ?

It is again now (#363).

Regards

Blair