Bug 29231 - override nint RowsInSection tableview should be tableView
Summary: override nint RowsInSection tableview should be tableView
Status: RESOLVED ANSWERED
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: XI 8.9.x (iOS 8.3)
Hardware: Macintosh Mac OS
: --- enhancement
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2015-04-19 15:53 UTC by Neal
Modified: 2015-04-21 08:45 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
I had about 20-30 of these, about 50% of the total methods (34.79 KB, image/png)
2015-04-20 10:41 UTC, Neal
Details
warning info (117.21 KB, image/png)
2015-04-21 08:44 UTC, Neal
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED ANSWERED

Description Neal 2015-04-19 15:53:09 UTC
Hello,

tableview should be tableView in:

public override nint RowsInSection (UITableView tableview, nint section)

---

=== Xamarin Studio ===

Version 5.8.3 (build 1)
Installation UUID: 25d1d6a6-72c5-479c-b704-f939b8920555
Runtime:
	Mono 3.12.1 ((detached/0849ec7)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 312010003

=== Apple Developer Tools ===

Xcode 6.3 (7569)
Build 6D570

=== Xamarin.iOS ===

Version: 8.9.1.3 (Business Edition)
Hash: f7736a4
Branch: 
Build date: 2015-04-09 04:22:08-0400

=== Xamarin.Android ===

Version: 4.20.2.1 (Business Edition)
Android SDK: /Users/Neal/Applications/android-sdk-macosx
	Supported Android versions:
		2.1   (API level 7)
		2.2   (API level 8)
		2.3   (API level 10)
		3.1   (API level 12)
		4.0.3 (API level 15)
		4.4   (API level 19)
Java SDK: /usr
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

=== Xamarin Android Player ===

Version: Unknown version
Location: /Applications/Xamarin Android Player.app

=== Xamarin.Mac ===

Version: 1.12.0.14 (Business Edition)

=== Build Information ===

Release ID: 508030001
Git revision: 6e8e725e0d689351901c2c70453bfa4ea25e293b
Build date: 2015-04-06 20:31:47-04
Xamarin addins: 051cd5f8c1b5dbfc87eaef80a74aec03f34c60a8

=== Operating System ===

Mac OS X 10.10.3
Darwin iMACRH.local 14.3.0 Darwin Kernel Version 14.3.0
    Mon Mar 23 11:59:05 PDT 2015
    root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64
Comment 1 Rolf Bjarne Kvinge [MSFT] 2015-04-20 07:48:11 UTC
This is technically a breaking change (code can fail to compile after changing parameter names), so I'm not sure this is worth it (in particular since you can just change the name of the variable yourself in the override if you wish).
Comment 2 Neal 2015-04-20 10:40:58 UTC
In searching our broad code base of a 3 year build out app we have mixed use of these params, some are tableView some are tableview which may have come from the unified conversion tool.  So I'm not sure if the conversion to unified "broke" the implementations or what the impact is but the concern should be as to what is in your customer's code now.  If I didn't have code analysis turned on to bring this to my attention I would have never noticed it and then of course would have had to catch some bad behavior in the app as a result and try to determine why.  I wish I could force all devs working on this project to have code analysis on, if I could do it in the solution that would be great but I don't think I can persist this feature on all devs so any and all future devs would see this issue.

So again, the concerns are:

1) How may are impacted now and don't know it
2) Should it be fixed and flagged in a future build to get corrected?

Thank you.
Comment 3 Neal 2015-04-20 10:41:31 UTC
Created attachment 10820 [details]
I had about 20-30 of these, about 50% of the total methods
Comment 4 Rolf Bjarne Kvinge [MSFT] 2015-04-21 05:36:47 UTC
(In reply to comment #2)
> In searching our broad code base of a 3 year build out app we have mixed use of
> these params, some are tableView some are tableview which may have come from
> the unified conversion tool.  So I'm not sure if the conversion to unified
> "broke" the implementations or what the impact is but the concern should be as
> to what is in your customer's code now.  If I didn't have code analysis turned
> on to bring this to my attention I would have never noticed it and then of
> course would have had to catch some bad behavior in the app as a result and try
> to determine why.

The warning "Parameter name differs in base method declaration" can safely be ignored, it's more a code style issue than something broken.

> 1) How may are impacted now and don't know it

This warning is completely harmless, and will not affect your app in any way whether you change your code or not.

> 2) Should it be fixed and flagged in a future build to get corrected?

If we change the base class declaration itself (which is the only thing we technically can do), then it is theoretically possible that other apps from other customers will fail to compile after upgrading. This is a serious consequence, and not worth it for an issue that is otherwise completely harmless.
Comment 5 Neal 2015-04-21 07:53:03 UTC
Thanks for the info Rolf.  The hover tip is a Warning (see screenshot, hint message is faded) - the source analysis folks may want to change this to a naming suggestion then.  It seemed more critical based on the hint associated, I consider "most" of source analysis suggestions NOT code styling but actual .NET compiler related and with this one producing a warning and potentially a compiler warning (yellow item in top center IDE area) during build it seemed more critical in nature.

Thanks again.
Comment 6 Neal 2015-04-21 08:25:04 UTC
Rolf - I'm going to reopen this, I do believe this generated a compiler warning so it's going to require action on Xamarin's part in either changing the warning to a naming suggestion or fix the problem that is high enough to be marked as a compiler warning.
Comment 7 Rolf Bjarne Kvinge [MSFT] 2015-04-21 08:30:53 UTC
Can you attach the build log so that we can have a look at the exact warning message?
Comment 8 Neal 2015-04-21 08:44:57 UTC
Created attachment 10839 [details]
warning info
Comment 9 Neal 2015-04-21 08:45:41 UTC
I stand corrected, it does NOT generate a "compiler" warning but a source analysis warning.  I navigated to the rule per the attached image.  I'll re-close this case.  Thank you.