Delphi 5：模拟“过时”的想法或“已弃用”方法？ [英] Delphi 5: Ideas for simulating "Obsolete" or "Deprecated" methods?

问题描述

我想将一种方法标记为过时，但是Delphi 5没有这种功能。

为了举例说明，以下是一个up方法已弃用，并采用了新的首选形式：

 过程TStormPeaksQuest.BlowHodirsHorn;超载; //过时的
过程TStormPeaksQuest.BlowHodirsHorn（UseProtection：Boolean）;超载; 
  

注意：对于此假设示例，我们假设使用无参数版本只是很糟糕。有些问题不是 使用保护-没有好的解决方案。没有人喜欢使用保护，但是没有人不想不使用保护。因此，当吹霍迪尔的号角时，我们让呼叫者决定是否要使用保护。如果我们默认无参数版本使用保护继续 not ：

 过程TStormPeaksQuest.BlowHodirsHorn; 
开始
 BlowHodirsHorn（False）; //没有保护。坏！ 
结尾； 
  

然后，开发人员就有各种讨厌的东西的风险。如果我们强制无参数版本使用保护：

 过程TStormPeaksQuest.BlowHodirsHorn; 
开始
 BlowHodirsHorn（True）; //使用保护；如果没有
则崩溃
  

然后，如果开发人员没有获得任何保护或不拥有该保护，就有可能出现问题

现在我可以重命名过时的方法：

 过程TStormPeaksQuest.BlowHodirsHorn_Deprecatedd;超载; //过时的
过程TStormPeaksQuest.BlowHodirsHorn（UseProtection：Boolean）;超载; 
  

但这会导致编译错误，人们会will我（我真的不会想听到他们的抱怨）。我希望他们得到一个 nag ，而不是一个实际的错误。

我考虑添加一个断言：

 程序TStormPeaksQuest.BlowHodirsHorn; //过时的
开始
 Assert（否， TStormPeaksQuest.BlowHodirsHorn已过时。请使用BlowHodirsHorn（Boolean））； 
 
 ... 
结束； 
  

但是我不能保证开发人员不会发布没有断言的版本，从而导致崩溃客户。

我考虑过仅在开发人员调试时才使用断言：

 程序TStormPeaksQuest.BlowHodirsHorn; //如果DebugHook>已过时
将以
开始0，然后
 Assert（false，‘TStormPeaksQuest.BlowHodirsHorn已过时。请使用BlowHodirsHorn（Boolean）’）； 
 
 ... 
结束； 
  

但是我真的不想造成任何崩溃。

我想显示一个MessageDlg（如果它们在调试器中）（这是我过去做过的一项技术）：

 程序TStormPeaksQuest.BlowHodirsHorn; //如果DebugHook>已过时
将以
开始0，然后
 MessageDlg（不建议使用TStormPeaksQuest.BlowHodirsHorn。请使用BlowHodirsHorn（Boolean），mtWarning，[mbOk]，0）； 
 
 ... 
结束； 
  

但这仍然太具破坏性。并引起了代码停留在显示模式对话框的问题，但对话框并不明显。

我希望收到某种警告消息那会坐在那里ing他们-直到他们挖出眼睛，最后改变他们的代码。

我想也许我要添加一个未使用的变量：

 过程TStormPeaksQuest.BlowHodirsHorn; //过时的
 var 
 ThisMethodIsObsolete：Boolean; 
开始
 ... 
结束； 
  

我希望这只有在引用了代码的情况下才会引起提示。但是即使您实际上并未使用过时的方法，Delphi也会显示提示。

有人还能想到别的吗？

解决方案

我最终使用的是选择进入一个系统的组合，在该系统中您同意不使用任何不赞成使用的代码，否则将输出调试字符串和断点。 p>

类似于 strict html，我创建了一个严格定义。

如果定义了严格，则所有公共单位的代码都已过时。这样，开发人员就同意他们不会在项目中使用过不赞成使用的代码：

  {$ IFNDEF Strict} 
 TStormPeaksQuest.BlowHaldirsHorn过程；超载; //过时的
 {$ ENDIF} 
过程TStormPeaksQuest.BlowHaldirsHorn（UseProtection：Boolean）; {$ IFNDEF Strict}超载； {$ ENDIF} 
 
 
 {$ IFNDEF Strict} 
过程TStormPeaksQuest.BlowHaldirsHorn; ///过时的
开始
 OutputDebugString（PAnsiChar（’TStormPeaksQuest.BlowHaldirsHorn已过时。请使用BlowHaldirsHorn（Boolean）’））; 
 
 //没有连接调试器就不要调试！ 
如果DebugHook> 0然后
 Windows.DebugBreak; 
 
 ... 
结束； 
  

因此，如果开发人员想要拥有适当的代码，则在新事物出现时必须执行代码更改不推荐使用的话，他们可以：

  {$ DEFINE Strict} 
  

如果没有，那么总是是一个OutputDebugString，并且任何具有调试视图可以看到（甚至是客户）。看到带有输出调试字符串的商用软件（甚至是Microsoft的软件）也很有趣。

最后，如果连接了调试器，他们将无处获得调试断点。如果有人问，我可以借此机会取笑他们。

i want to mark a method as obsolete, but Delphi 5 doesn't have such a feature.

For the sake of an example, here is a made-up method with it's deprecated and new preferred form:

procedure TStormPeaksQuest.BlowHodirsHorn; overload; //obsolete
procedure TStormPeaksQuest.BlowHodirsHorn(UseProtection: Boolean); overload;

Note: For this hypothetical example, we assume that using the parameterless version is just plain bad. There are problems with not "using protection" - which have no good solution. Nobody likes having to use protection, but nobody wants to not use protection. So we make the caller decide if they want to use protection or not when blowing Hodir's horn. If we default the parameterless version to continue not using protection:

procedure TStormPeaksQuest.BlowHodirsHorn;
begin
    BlowHodirsHorn(False); //No protection. Bad!
end;

then the developer is at risk of all kinds of nasty stuff. If we force the parameterless version to use protection:

procedure TStormPeaksQuest.BlowHodirsHorn;
begin
    BlowHodirsHorn(True); //Use protection; crash if there isn't any
end;

then there's a potential for problems if the developer didn't get any protection, or doesn't own any.

Now i could rename the obsolete method:

procedure TStormPeaksQuest.BlowHodirsHorn_Deprecatedd; overload; //obsolete
procedure TStormPeaksQuest.BlowHodirsHorn(UseProtection: Boolean); overload;

But that will cause a compile error, and people will bitch at me (and i really don't want to hear their whining). i want them to get a nag, rather than an actual error.

i thought about adding an assertion:

procedure TStormPeaksQuest.BlowHodirsHorn; //obsolete
begin
   Assert(false, 'TStormPeaksQuest.BlowHodirsHorn is deprecated. Use BlowHodirsHorn(Boolean)');

   ...
end;

But i cannot guarantee that the developer won't ship a version without assertions, causing a nasty crash for the customer.

i thought about using only throwing an assertion if the developer is debugging:

procedure TStormPeaksQuest.BlowHodirsHorn; //obsolete
begin
   if DebugHook > 0 then
      Assert(false, 'TStormPeaksQuest.BlowHodirsHorn is deprecated. Use BlowHodirsHorn(Boolean)');

   ...
end;

But i really don't want to be causing a crash at all.

i thought of showing a MessageDlg if they're in the debugger (which is a technique i've done in the past):

procedure TStormPeaksQuest.BlowHodirsHorn; //obsolete
begin
   if DebugHook > 0 then
        MessageDlg('TStormPeaksQuest.BlowHodirsHorn is deprecated. Use BlowHodirsHorn(Boolean)', mtWarning, [mbOk], 0);

   ...
end;

but that is still too disruptive. And it has caused problems where the code is stuck at showing a modal dialog, but the dialog box wasn't obviously visible.

i was hoping for some sort of warning message that will sit there nagging them - until they gouge their eyes out and finally change their code.

i thought perhaps if i added an unused variable:

procedure TStormPeaksQuest.BlowHodirsHorn; //obsolete
var
   ThisMethodIsObsolete: Boolean;
begin
   ...
end;

i was hoping this would cause a hint only if someone referenced the code. But Delphi shows a hint even if you don't call actually use the obsolete method.

Can anyone think of anything else?

解决方案

What I've ended up using was a combination of opting into a system where you agree to not have any deprecated code, with output debug strings and breakpoints otherwise.

Like strict html, I've created a Strict define.

All the common units have the obsolete code defined out if Strict is defined. That way the developer has agreed that they will not have deprecated code in their project:

{$IFNDEF Strict}
procedure TStormPeaksQuest.BlowHaldirsHorn; overload; //obsolete
{$ENDIF}
procedure TStormPeaksQuest.BlowHaldirsHorn(UseProtection: Boolean); {$IFNDEF Strict}overload;{$ENDIF}


{$IFNDEF Strict}
procedure TStormPeaksQuest.BlowHaldirsHorn; //obsolete
begin
   OutputDebugString(PAnsiChar('TStormPeaksQuest.BlowHaldirsHorn is deprecated. Use BlowHaldirsHorn(Boolean)'));

   //Don't debugbreak without a debugger attached!
   if DebugHook > 0 then
        Windows.DebugBreak;

   ...
end;

So if the developer wants to have proper code, suffering having to perform code-changes when new things are deprecated, they can:

{$DEFINE Strict}

If not, then there will always be an OutputDebugString, and anyone with Debug View can see (even customers). It's funny to see commercial software (even Microsoft's) with output debug strings left over.

And finally, if there's a debugger attached, then they'll get a debug breakpoint out of nowhere. If anyone asks about, i can take that opportunity to make fun of them.

这篇关于Delphi 5：模拟“过时”的想法或“已弃用”方法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！