Board index » delphi » H2365 Override method AbCd should match case of ancestor Abcd

H2365 Override method AbCd should match case of ancestor Abcd

See also QC 23419...
Since when was Delphi a case-sensitive language?
Can someone PLEASE explain why this hint has been forced upon us,
without an option to selectively disable it?

If it only were easy to do case corrections - but I have hundreds of unit
tests with TTestCase.Setup/Teardown, not CamelCapped as in the base class...
with all the diff noise that generates, I would like to know that it is all
for a VERY good reason...

--
Kristofer

 

Re:H2365 Override method AbCd should match case of ancestor Abcd


Quote
Kristofer Skaug wrote:
> See also QC 23419...
> Since when was Delphi a case-sensitive language?
> Can someone PLEASE explain why this hint has been forced upon us,
> without an option to selectively disable it?

.NET is case sensitive so a guess would be this is warning that
there could be problems when/if this code is moved to it.

Quote
> If it only were easy to do case corrections - but I have hundreds of unit
> tests with TTestCase.Setup/Teardown, not CamelCapped as in the base class...
> with all the diff noise that generates, I would like to know that it is all
> for a VERY good reason...

In Delphi 2006 at least Refactor->Rename makes doing case corrections
easy. It knows Delphi syntax and scope rules plus it can show you
all the places it will do a rename before you have it do them.
I renamed a control to itself to clean up the variety of differently
cased version in code added to an application over several years.
Quick and no collateral damage from false matches like what
often happens when doing a simple search and replace.

Brian

Re:H2365 Override method AbCd should match case of ancestor Abcd


Quote
Brian Evans wrote:

> .NET is case sensitive so a guess would be this is warning that
> there could be problems when/if this code is moved to it.

I'll gladly believe that the .NET CLR is case-sensitive, but is also the
Delphi.NET language so?
Anyway I would put this message in the same category as the 'unsafe code'
warnings, which at least you can turn off (and, in fact, are now disabled by
default in Delphi/Win32!)..

Quote
> In Delphi 2006 at least Refactor->Rename makes doing case
> corrections easy.

I'm not worried about the mechanics of performing the rename (as you say,
the Rename refactoring is probably very good at that, but even dumb search &
replace usually works fine for me...) - but just thinking about the massive
amounts of diff's this generates!

I am maintaining a code library of more than 130 units. Each unit has its
own versioning and is stored on a network share with read-only access. With
each individual release I perform regression testing against the complete
dependancy tree. My colleagues (the end users) carefully inspect the changes
in each new release by diff'ing against release N-1.
Reformatting and renaming stuff for no clear gain is therefore considered to
be a PITA.

<rant>
Eliminating all these case-inconsistencies means changing several dozens of
files ( = dozens of new releases to be administered) for no better purpose
than that the D10 compiler will gush messages at you uncontrollably for the
rest of your life, if you don't. Not because you have illegal or unsound
code, oh no! just because a dude at Borland invented a new type of hint that
can't be turned off, without considering the consequences.
</rant>

Reminds me strangely of the new Platform warnings for D6, which Borland
almost forgot to provide a switch for (well, they made it a semi-unsupported
"extreme toy" <g>).

--
Kristofer

Re:H2365 Override method AbCd should match case of ancestor Abcd


Quote
Kristofer Skaug wrote:

> I'll gladly believe that the .NET CLR is case-sensitive, but is also the
> Delphi.NET language so?
> Anyway I would put this message in the same category as the 'unsafe code'
> warnings, which at least you can turn off (and, in fact, are now disabled by
> default in Delphi/Win32!)..

It's not that Delphi itself is case sensitive. It's external code
looking in that probably expects the names to be consistent as if
they were case sensitive. A generic de{*word*81} or code explorer for
.NET apps working at the object interface level would be one example.
This warning might have put in to help Borland get things working
better under .NET and fleshing it out by putting in a way for it to be
suppressed was overlooked.

Quote
> I'm not worried about the mechanics of performing the rename (as you say,
> the Rename refactoring is probably very good at that, but even dumb search &
> replace usually works fine for me...) - but just thinking about the massive
> amounts of diff's this generates!

> I am maintaining a code library of more than 130 units. Each unit has its
> own versioning and is stored on a network share with read-only access. With
> each individual release I perform regression testing against the complete
> dependancy tree. My colleagues (the end users) carefully inspect the changes
> in each new release by diff'ing against release N-1.
> Reformatting and renaming stuff for no clear gain is therefore considered to
> be a PITA.

My guess is if the code is ever going to be used under .NET the cleanup
will have to be done at some point. It's not good to be forced
into it now however just to get rid of warnings.

Quote
> <rant>
> Eliminating all these case-inconsistencies means changing several dozens of
> files ( = dozens of new releases to be administered) for no better purpose
> than that the D10 compiler will gush messages at you uncontrollably for the
> rest of your life, if you don't. Not because you have illegal or unsound
> code, oh no! just because a dude at Borland invented a new type of hint that
> can't be turned off, without considering the consequences.
> </rant>

> Reminds me strangely of the new Platform warnings for D6, which Borland
> almost forgot to provide a switch for (well, they made it a semi-unsupported
> "extreme toy" <g>).

I agree there should be a way to turn this and any other warnings
not already listed off. Keep in mind I am making what I think is
a good guess of why this warning exists but it's still a guess and
I could be wrong.

Brian

Re:H2365 Override method AbCd should match case of ancestor Abcd


Quote
Kristofer Skaug wrote:
> Brian Evans wrote:

> > .NET is case sensitive so a guess would be this is warning that
> > there could be problems when/if this code is moved to it.

> I'll gladly believe that the .NET CLR is case-sensitive, but is also
> the Delphi.NET language so?

No, but if you interface with the CLR, you must respect that. Actually,
the same is true for interfacing with Win32:

  program Project7;

  {$APPTYPE CONSOLE}

  function GetSYsColor(nIndex: Integer): Cardinal;
    external 'user32.dll';

  begin
    Writeln(GetSysColor(0));
    Readln;
  end.

Only if you change the declaration to GetSysColor, it will work.

--
Rudy Velthuis [TeamB]      http://rvelthuis.de/

"We have art to save ourselves from the truth."
    - Friedrich Nietzsche (1844-1900)

Re:H2365 Override method AbCd should match case of ancestor Abcd


Quote
Brian Evans wrote:

> It's not that Delphi itself is case sensitive. It's external code
> looking in that probably expects the names to be consistent as if
> they were case sensitive.

OK that might make sense.

Quote
> My guess is if the code is ever going to be used under .NET the
> cleanup will have to be done at some point. It's not good to be forced
> into it now however just to get rid of warnings.

IF being the operative word here ... we still have no concrete plans to
migrate to .NET.

--
Kristofer

Re:H2365 Override method AbCd should match case of ancestor Abcd


Quote
Rudy Velthuis [TeamB] wrote:
> No, but if you interface with the CLR, you must respect that.
> Actually, the same is true for interfacing with Win32:

Sure - in fact, for 3rd party libraries/API's, our company coding standard
(which I wrote, BTW) recommends following the capitalization conventions in
the declarations of that API, even if/when it violates our internal
capitalization rules. I'm all for consistency in all aspects of coding
practice (that's why we have a coding standard), but I'm an even bigger fan
of "live and let live".

--
Kristofer

Re:H2365 Override method AbCd should match case of ancestor Abcd


Quote
Kristofer Skaug wrote:
> Rudy Velthuis [TeamB] wrote:
> > No, but if you interface with the CLR, you must respect that.
> > Actually, the same is true for interfacing with Win32:

> Sure - in fact, for 3rd party libraries/API's, our company coding
> standard (which I wrote, BTW) recommends following the capitalization
> conventions in the declarations of that API, even if/when it violates
> our internal capitalization rules. I'm all for consistency in all
> aspects of coding practice (that's why we have a coding standard),
> but I'm an even bigger fan of "live and let live".

It is not just a coding standard, it means it won't work if you don't
respect it.

--
Rudy Velthuis [TeamB]      http://rvelthuis.de/

"I don't know why we are here, but I'm pretty sure that it is not in
order to enjoy ourselves."
    - Ludwig Wittgenstein (1889-1951)

Re:H2365 Override method AbCd should match case of ancestor Abcd


Quote
Rudy Velthuis [TeamB] wrote:
> It is not just a coding standard, it means it won't work if you don't
> respect it.

In your example (a DLL import declaration) this is true.
In the general case - for DLL/library calls etc. this is generally not true.
As I said above, normally I'd promote consistency, but not at all costs.

BTW - slightly digressing - in the new Object Inspector, all boolean
property values are shown as 'true/false' (all lowercased).
Traditionally the boolean constants were always 'True/False' for Delphi, but
this has clearly had to yield to the sensitivities of the new C++
personality next-door.
It really irks me right now, but I guess we'll just have to grin and bear it
... <g>  what to do about it in the coding standard, though...?

--
Kristofer

Re:H2365 Override method AbCd should match case of ancestor Abcd


At 01:05:22, 19.01.2006, Kristofer Skaug wrote:

Quote
> Rudy Velthuis [TeamB] wrote:
> > It is not just a coding standard, it means it won't work if you don't
> > respect it.

> In your example (a DLL import declaration) this is true.
> In the general case - for DLL/library calls etc. this is generally not
> true.

That is because you use the alias in the import unit, and that can be
used case insensitively. In .NET, there are no aliases, you directly
access the types and functions from the assembly. No need to write import
units anymore. The assembly is its own import unit, for all languages
using it.

--
Rudy Velthuis [TeamB]        http://rvelthuis.de/

"A friendship founded on business is better than a business founded on
friendship."
    - John D. Rockefeller (1874-1960)

Re:H2365 Override method AbCd should match case of ancestor Abcd


Quote
Rudy Velthuis [TeamB] wrote:
> In .NET, there are no aliases, you directly
> access the types and functions from the assembly. No need to write
> import units anymore. The assembly is its own import unit, for all
> languages using it.

I'm aware of that. And I'm sure Borland had a good reason for introducing
the H2365 hint originally, only they forgot to tell us the reason and they
forgot to provide a mechanism to turn it off. None of this makes it less
annoying for Win32 developers with no .NET migration plans.

--
Kristofer

Re:H2365 Override method AbCd should match case of ancestor Abcd


At 14:11:20, 19.01.2006, Kristofer Skaug wrote:

Quote
> Rudy Velthuis [TeamB] wrote:
> > In .NET, there are no aliases, you directly
> > access the types and functions from the assembly. No need to write
> > import units anymore. The assembly is its own import unit, for all
> > languages using it.

> I'm aware of that. And I'm sure Borland had a good reason for
> introducing the H2365 hint originally, only they forgot to tell us the
> reason and they forgot to provide a mechanism to turn it off. None of
> this makes it less annoying for Win32 developers with no .NET migration
> plans.

What was your code?

--
Rudy Velthuis [TeamB]        http://rvelthuis.de/

"Maybe this world is another planet's Hell."
    - Aldous Huxley (1894-1963)

Re:H2365 Override method AbCd should match case of ancestor Abcd


Quote
Rudy Velthuis [TeamB] wrote:

> What was your code?

in short (simplified):

uses ... ,TestFramework; // (DUnit)

TMyTest = class(TTestCase)
protected
  procedure Setup; override;  // <- H2365 hint
  procedure Teardown; override; // <- H2365 hint
published
  ... {Test methods}
end;

In the DUnit framework, the virtual methods are camel-capped as 'SetUp' and
'TearDown' but over the years I've grown lazy (er, 'more efficient') and
have tended to drop the CamelCapping because these words are short and it
doesn't significantly affect the readability either way.

However now I'm stuck with hundreds of these compiler messages...

--
Kristofer

Re:H2365 Override method AbCd should match case of ancestor Abcd


Quote
Kristofer Skaug wrote:
> In the DUnit framework, the virtual methods are camel-capped as
> 'SetUp' and 'TearDown' but over the years I've grown lazy (er, 'more
> efficient') and have tended to drop the CamelCapping because these
> words are short and it doesn't significantly affect the readability
> either way.

> However now I'm stuck with hundreds of these compiler messages...

And that was in D7? Weird.

--
Rudy Velthuis [TeamB]      http://rvelthuis.de/

"All our knowledge merely helps us to die a more painful death than
 animals that know nothing." -- Maurice Maeterlinck.

Re:H2365 Override method AbCd should match case of ancestor Abcd


At 13:17:34, 23.01.2006, Kristofer Skaug wrote:

Quote
> Rudy Velthuis [TeamB] wrote:

> > And that was in D7? Weird.

> No, D2006.

Must try that. Do you have a very simple piece of example code (a very
short console app, for instance)?

--
Rudy Velthuis [TeamB]        http://rvelthuis.de/

"A mathematician is a device for turning coffee into theorems."
    - Paul Erdos

Go to page: [1] [2]

Other Threads