[Mono-osx] Patches for NSColor

[Regan Sarwas]

Miguel,

Glad the patches were satisfactory, I look forward to contributing more.

As requested, I changed the capitalization but did not drop "Component" in
the member names.  I will submit shortly, but wanted to resolve one other
naming issue first.

There are currently 30 ObjC methods named "numberOfXxx" in appkit.cs, and 1
in coreimage.cs and there does not seem to be a standard for the C# name.  I
have seen

  NumberOfXxx
  Xxx
  CountOfXxx
  XxxCount
  Count

Leaving it NumberOfXxx, doesn't seem very C#ish, and Count is only
appropriate if the object is clearly a collection.  Dropping the NumberOf is
usually confusing, for example shortening the NSColor method
numberOfComponents to just Components is mis-leading because it does not
return the components (which is an array of floats).  Granted intellisense
helps, but I think a good standard name helps make the code more readable.
 So, what should it be?

My vote is Count or XxxCount, depending on the object.


On Fri, Dec 31, 2010 at 4:45 AM, Miguel de Icaza <miguel at novell.com> wrote:

> Hello Regan,
>
> Attached is a git-diff output file for corrections to the NSColor interface
>> in appkit.cs
>> Also attached is NSColor.cs which provides strongly typed bindings for the
>> two obj-c methods that take *CGFloat input.
>> (I did not include the diff to the Makefile)
>>
>
> Thanks for the fixes, I liked them very much.   I am not sure how we even
> got those NSColor bindings there, I could have sworn I had reviewed every
> API that we checked in to remove bad names (although I still find some every
> once in a while).
>
>>
>> I added out parameters in the interface where appropriate, and the
>> generator created correct code in all case.  Of course this relies on
>> continuing correct behavior of the generator, but in my opinion is much
>> cleaner than creating additional wrapper methods to deal with an IntPtr.
>>
>
> Agreed.
>
> I did a minimal amount of method/parameter renaming to be internally
>> consist (as I saw it).
>>
>
> I liked them.   And these are important for two reasons: they show up on
> intellisense, and can provide valuable information to the developer while he
> is developing, without having to look up the documentation, and because with
> C# 4.0 users will be able to name their parameters.   So good parameter
> names are important.
>
>
>> I resisted the urge to do more extensive renaming, because I wasn't sure
>> it was appropriate.  I would like to rename XxxxxRGBA() to XxxxxRgba() for
>> consistency with MonoMac.CoreImage.CIColor and System.Drawing.Color. I also
>> considered dropping "Component" from xxxComponent. (i.e RedComponent { get;}
>> would become Red {get;}. Once again this would be consistent with CIColor
>> and Color,  furthermore Component seems to be a synonym for property.
>>  Thoughts?
>>
>
> Let us rename it.   The only case where we might have problems is with
> MacCore, as that API is already an API that is used by thousands of
> developers, so we can not just break their apps like that.
>
> For the "Component" part, I am do not remember why we did it this way, but
> I remember that it was not my first choice, I would have to investigate
> again why I chose to keep it that way.    For now, let us keep it as-is.
>
> This is my first submission, so feedback would be helpful.
>>
>
> Lovely work.   You just missed adding the new file to the src/Makefile
>
> Miguel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-osx/attachments/20101231/f92b9bb9/attachment-0001.html