VASmalltalk – 8.5 – “Deprecation Exception support”

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

VASmalltalk – 8.5 – “Deprecation Exception support”

Marten Feldtmann-2
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 ....

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/RHYptBB19oYJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: VASmalltalk – 8.5 – “Deprecation Exception support”

Thomas Koschate-2
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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/VhZkkvsOynQJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: VASmalltalk – 8.5 – “Deprecation Exception support”

jtuchel
In reply to this post by Marten Feldtmann-2
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 ;-)

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/me36MI0WTtAJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: VASmalltalk – 8.5 – “Deprecation Exception support”

John O'Keefe
In reply to this post by Marten Feldtmann-2
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
Reply | Threaded
Open this post in threaded view
|

Re: VASmalltalk – 8.5 – “Deprecation Exception support”

John O'Keefe
In reply to this post by Thomas Koschate-2
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
Reply | Threaded
Open this post in threaded view
|

Re: VASmalltalk – 8.5 – “Deprecation Exception support”

Thomas Koschate-2
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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/F584eBF6nlAJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: VASmalltalk – 8.5 – “Deprecation Exception support”

Marten Feldtmann-2
In reply to this post by John O'Keefe
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 ....


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/HSbSo27_xFkJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: VASmalltalk – 8.5 – “Deprecation Exception support”

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).
Reply | Threaded
Open this post in threaded view
|

Re: VASmalltalk – 8.5 – “Deprecation Exception support”

Gabriel Cotelli
In reply to this post by Marten Feldtmann-2
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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/qsORYeJM1ioJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.