Smalltalk › Instantiations

Deprecation Support

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

John O'Keefe-3

Deprecation Support

This post is another in our series of V8.5 early-exposure items. We are adding support for the Deprecation exception in VA Smalltalk V8.5. You can see the design for this at Deprecation Support. Please post comments and suggestions here.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
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.

Douglas Swartz

Re: Deprecation Support

It might be useful to offer a variation on "Write to a log file and proceed", which writes a stack trace to the log, in addition to the message.

Doug Sartz

John O'Keefe-3

Re: Deprecation Support

Doug -

First, I have clarified the log option in Deprecation Support -- it adds to an in-memory collection (Bag) rather than write to a file.

The thought behind the 4 options is to give a continuum of notification levels from immediate (open a Warning dialog) to none. Based on this, I consider writing to the Transcript and writing to the log file to be the same level of notification, while writing to an in-memory collection is a "we collected the information, but we haven't disturbed you about it" level.

I'm thinking about your suggestion, but I'm having difficulty coming up with a scenario where I would want more information than who called the deprecated method -- can you help me here?

One thing we haven't decided on is how long deprecated methods will be carried along in the product. Seaside drops them at the next release -- a bit too fast for my taste. We have traditionally either a) left them in place forever (which kind of defeats the purpose) or b) moved them to a separate app and map (for example, ENVY/Image Obsolete PI) which is not normally loaded. My preference is b), but what we actually do in this area will depend in part on the volume of deprecation.

John

Ben van Dijk

Re: Deprecation Support

Hi John,

Kudos for the proposed deprecation support, will be handy.

A stack trace as suggested by Doug can give us more information on why and in which situation we use the deprecated api.
But mostly knowing the calling method will be enough

I suggest to add an option "open a debugger" when the deprecated api is called.
And a signal "will be deprecated in next release" will be very useful.

Greetz, ben

Marten Feldtmann-2

Re: Deprecation Support

Perhaps inserting a specific pragma would be helpful to identify such a method even in the browser and also notifications during packaging process when packaging such a method.

Using specific pragmas (at last a useful usage of that structure) and you may find senders of these messages - and then you can fix the senders in your application.

You may also - via menu - set automatically breakpoints in those pragma decorated methods.

Information during packaged runtimes via logs? Strange idea.