VASmalltalk – 8.5 – “Deprecation Exception support”

[Marten Feldtmann]

Grrrr, I described the usage of this feature at my blog and now I'm a victim of this feature.

I loaded the OLE feature and tried to generate code and got an exception !

I just looked around and found, that this code used #vaVersion, which is indicated a deprecated in V 8.5. Therefore I have some questions:

* why not introduce a nice dialog showing the reason for this problem and give the user (me) the possiblity

* why have you not changed all senders in your product to use the #imageVersion method ?????????

This is not user friendly ....

[Thomas Koschate]

I don't know that #imageVersion is an adequate substitute for #vaVersion.  The latter has the advantage of allowing one to write expressions where the version is immediately readable by normal humans.  I don't fancy trying to write config expressions for maps and applications using #imageVersion.  For those of us trying to transition code over multiple VA versions, this is an important feature.  And, I agree, Instantiations should have cleaned up their own usage before deprecating #vaVersion.

Tom

[jtu...@objektfabrik.de]

Instantiations:

Maybe a Dialog as Marten said is not necessary, if at least desirable at places like loading or generating code. A deprecated feature should not really keep you from doing something important as long as the method is still there...

In Seaside, there is also a deprecation support and they (almost) always throw the exception with some additional info. Thus you can see in the debugger what's wrong without digging too long.

Of course, if there's no real idea what replaces deprecated code, then we have a problem ;-)

[John O'Keefe]

Marten -

2 apps (AbtCommonAppBldrModelApp and GFST) that referenced
EmSystemConfiguration>>#vaVersion were changed (6/11/2011), but not released
for V8.5. I have opened a case to fix them.

This problem identifies a process error that we will be discussing during
our V8.5 post-mortem -- the objective is to find a way to prevent such
errors in the future.

If you see other references to EmSystemConfiguration>>#vaVersion, please let
us know.

The Deprecation support has 4 options for handling the exception that are
controlled by .INI file entries. These options are described in the
documentation
(http://www.instantiations.com/docs/85/wwhelp/wwhimpl/js/html/wwhelp.htm#href=sg/stug510.html).
I think you are asking for either the raising behavior (popup message box)
or the showing behavior (write message to the Transcript) -- by default, the
exception should be ignored.

John

--
View this message in context: http://forum.world.st/VASmalltalk-8-5-Deprecation-Exception-support-tp3826085p3827512.html
Sent from the Instantiations mailing list archive at Nabble.com.

[John O'Keefe]

Thomas -

In V8.0.3, /System vaVersion /answered 2052 (16r0803); in V8.5, /System
imageVersion /answers 2128 (16r0850). In other words, they both answer
aSmallInteger with identical format that is human readable (at least in the
hex format).

Your 2nd point is addressed in my response to Marten.

John

--
View this message in context: http://forum.world.st/VASmalltalk-8-5-Deprecation-Exception-support-tp3826085p3827531.html

[Thomas Koschate]

John, my problem with this is that I can't use imageVersion in VA 8.0.2, as it gives me an answer of 1024.  If you can suggest a method I can use for my config expressions that will remain consistent, starting with 8.0.2, I'll happily use it, but you can't go deprecating it on me!

Tom

[Marten Feldtmann]

StsAbtApplicationsOrganizerView>>confirmCloseRequest: confirmationCallData
GFST class>>stsAddToIcMap: aDictionary
AbtMigrationApp>>migratePartBuilders: aMigrationObject on: aClass in: anApp
AbtMigrationApp>>migrateFeatureBuilders: aMigrationObject on: aClass in: anApp
AbtClassUpdate>>interfaceBuilderRecord: anInterfaceBldrRecord
AbtAppBldrRecord>>initialize
AbtAppBldrPartClassUpdate>>partBuilderRecord: aPartBuilderRecord

These are my settings

[Kernel]
logDeprecations=
raiseDeprecations=
showDeprecations=
walkbackFilename=

and the exceptions are raised ....

[John O'Keefe]

Marten -

StsAbtApplicationsOrganizerView>>confirmCloseRequest: confirmationCallData
-- reference was removed on 06/11/2001, but app/map not released
GFST class>>stsAddToIcMap: aDictionary -- reference was removed on
06/11/2001, but app/map not released

AbtMigrationApp>>migratePartBuilders: aMigrationObject on: aClass in: anApp

-- OK

AbtMigrationApp>>migrateFeatureBuilders: aMigrationObject on: aClass in:

anApp -- OK
AbtClassUpdate>>interfaceBuilderRecord: anInterfaceBldrRecord -- OK
AbtAppBldrRecord>>initialize -- reference was updated on 06/11/2001, but
app/map not released
AbtAppBldrPartClassUpdate>>partBuilderRecord: aPartBuilderRecord -- OK

You missed AbtInterfaceBldrRecord>>initialize -- reference was updated on
06/11/2001, but app/map not released

The methods marked OK above contain valid sends of vaVersion (they are not
references to System>>vaVersion).

--
View this message in context: http://forum.world.st/VASmalltalk-8-5-Deprecation-Exception-support-tp3826085p3827765.html

[Gabriel Cotelli]

Marten,

I have a similar issue. As a workaround I implemented Deprecation>>signal as:

signal

   self class raising ifTrue: [ super signal ]

to avoid raising the Deprecation because some handler during the evaluation of configuration expressions handles the error and defaultAction is never evaluated.

Hope it helps

Gabriel