Squint and read: CreateFormFromStings

[Darian Miller 361]

10.3.3 (I haven't checked when this was introduced)

 

System.Net.HttpClient

procedure THTTPClient.CreateFormFromStings(const ASource: TStrings; const AEncoding: TEncoding;
  const AHeaders: TNetHeaders; var ASourceStream: TStream; var ASourceHeaders: TNetHeaders);

 

Its used ten times in two units.  (twice in System.Net.HttpClientComponet)

 

As it's a public method, they would break backwards compatibility to fix it, but I suggest they fix it...

https://quality.embarcadero.com/browse/RSP-27358

 

Did I miss a conversation on this?  I didn't see any references.

[Dave Nottage 557]

1 hour ago, Darian Miller said:

I haven't checked when this was introduced

It was introduced in 10.3

 

1 hour ago, Darian Miller said:

I suggest they fix it

You're right that it's not a good look. If it were me, I'd change it and take the small amount of pain (if any) from developers, who would probably understand anyway

[Darian Miller 361]

Just now, Dave Nottage said:

It was introduced in 10.3

 

It's been out there for a little over a year and there hasn't been a long chain of comments yet?  : )   (At least none that I found.)   

 

Maybe that just means very few are using THTTPClient...

 

[Dave Nottage 557]

2 minutes ago, Darian Miller said:

Maybe that just means very few are using THTTPClient.

..or very few using that method, or very few that are vocal about the misspelling 😉

 

[Darian Miller 361]

Just now, Dave Nottage said:

..or very few using that method, or very few that are vocal about the misspelling 😉

 

 

Delphi programmers are typically not very shy at saying how horrible something like that looks!   Or opining about how bad the Quality Control is lately, or how the newer code is being created by low wage contractors instead of highly skilled craftsmen, etc...  The has all the makings of those sorts of comments.  And we've gone a year without it?  I had to look at it 3 times from Sunday to make sure my cross eyes weren't playing a trick on me.  I've done this sort of stupid thing multiple times and whenever I come across it, I typically immediately stop and fix all references.  (Or if someone else did it, I tell them to immediately stop and fix it!)  Call it a pet peeve I guess...

 

I imagine if I use it, I'll put in a class helper to fix the spelling!

[Lars Fosdal 1792]

For some reason, many of the programmers I know have various degrees of dyslexia - which leads me to mentally auto-correct the misspellings I find, and in many cases, leave them as is.  Usually, changing the spelling leads to something unpleasant happening, such as a mismatch between stream content and object property, DB field names, etc.

[Sherlock 663]

4 hours ago, Lars Fosdal said:

Usually, changing the spelling leads to something unpleasant happening, such as a mismatch between stream content and object property, DB field names, etc.

I get that, really I do, but my brain hurts...

[Lars Fosdal 1792]

2 minutes ago, Sherlock said:

I get that, really I do, but my brain hurts...

Mine too, especially when I've written the semantically correct word, but the compiler barfs because the actual word in the code is misspelled.

[Dave Nottage 557]

Not that it would affect many users (if any), but in FMX.Edit.Style:

 

  protected
    FNeedChange: Boolean;
    procedure Change; virtual;
    { Messages From Model}
    procedure MMSelLenghtChanged(var AMessage: TDispatchMessageWithValue<Integer>); message MM_EDIT_SELLENGTH_CHANGED;
    procedure MMSelStartChanged(var AMessage: TDispatchMessageWithValue<Integer>); message MM_EDIT_SELSTART_CHANGED;
    procedure MMCheckSpellingChanged(var AMessage: TDispatchMessageWithValue<Boolean>); message MM_EDIT_CHECKSPELLING_CHANGED;

Spot the typo. The last method name pictured is ironic.

 

Someone should whip up a "spell checker" (of sorts) to see how many of these there are 😉

 

[Darian Miller 361]

Ouch.  But at least that one is protected.  They can hopefully fix that one without much drama.

 

[Darian Miller 361]

On 1/8/2020 at 9:19 PM, Dave Nottage said:

Not that it would affect many users (if any), but in FMX.Edit.Style:

 

  protected
    FNeedChange: Boolean;
    procedure Change; virtual;
    { Messages From Model}
    procedure MMSelLenghtChanged(var AMessage: TDispatchMessageWithValue<Integer>); message MM_EDIT_SELLENGTH_CHANGED;
    procedure MMSelStartChanged(var AMessage: TDispatchMessageWithValue<Integer>); message MM_EDIT_SELSTART_CHANGED;
    procedure MMCheckSpellingChanged(var AMessage: TDispatchMessageWithValue<Boolean>); message MM_EDIT_CHECKSPELLING_CHANGED;

 

 

Reported:

https://quality.embarcadero.com/browse/RSP-27412

 

Funny thing is, they found/replaced the same spelling issue in FMX.Edit.Win.pas (reported August 2015 by John Kaster on https://quality.embarcadero.com/browse/RSP-11800)

 

But the same spelling error appears in

FMX.Edit.Android.pas
and FMX.Edit.iOS.pas
and FMX.Edit.Style.pas

 

[Darian Miller 361]

Not sure I agree with this closure https://quality.embarcadero.com/browse/RSP-27358  with "Yes, too late, we'll live with it"

"Method CreateFormFromStings spelling mistake"

 

You should be able to fix spelling mistakes of public methods from a recently published version...backwards compatibility is not 100% written in stone

 

 

 

[Vandrovnik 214]

They could create method with correct name and for some time keep the bad one in place too, just marked as deprecated... Just if there were a will to fix things.

[Dave Nottage 557]

35 minutes ago, Darian Miller said:

You should be able to fix spelling mistakes of public methods from a recently published version

More a case of: a major release is the best time to do it, since it can be interface breaking.

 

If, after the change, a users code does not compile, I doubt they're going to say: "I want it back with the incorrect spelling". They're more likely to say: "I'm upset that you spelled it wrong in the first place, but fixing it is way better".

[Larry Hengen 39]

It is really discouraging to see the excuse that we can't fix it because it might break someone else's code...again and again.  I would encourage the bug reporter to contest the "resolution" on such tickets and put comments I see here on those tickets.  Without push back, there will be no change and I don't think the decision was made at a very high level.  I bet @Marco wouldn't support that decision publicly.

[Darian Miller 361]

And... RSP-27358  is back open again.   Minor victory!

 

Thanks Bruneau Babet and those that commented on this and https://quality.embarcadero.com/browse/RSP-27412