> On 2 Jul 2015, at 11:15 am, Charles Srstka wrote:
>
> and that you have the named function parameters to make it clear what’s going
> on
Amen :)
G.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or mode
On Jul 1, 2015, at 6:28 PM, Graham Cox wrote:
>
> Obviously it’s only a convention, but I think horizontal values should always
> precede vertical ones, if only because x comes before y in the alphabet, and
> map coordinates are that way around as well. The change to {origin, size} was
> also
> On 2 Jul 2015, at 7:22 am, Greg Parker wrote:
>
> Classic Mac OS was inconsistent. For example, the C struct initializer for
> Rect was { top, left, bottom, right }, but the initializer function was
> SetRect(&rect, left, top, right, bottom).
Ah, the good old days /sarc
Obviously it’s onl
> On Jul 1, 2015, at 8:58 AM, Charles Srstka wrote:
>
>> On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas wrote:
>>
>> Only because you are used to CGRect. QuickDraw used to defined a rect using
>> left, top, right, bottom values.
>
> Actually, it was top, left, bottom, right.
Classic Mac OS
> On Jul 1, 2015, at 09:07 , Roland King wrote:
>
> Named parameters is good syntax, autocomplete, which needs to still get
> better,
It needs to get SO MUCH BETTER.
• It still fails completely for me ALL the time, Xcode 6 or 7, there are times
when it simply won't offer any completions at a
On Jul 1, 2015, at 08:09 , Jean-Daniel Dupas wrote:
>
> Only because you are used to CGRect.
Well, that’s kinda what I was saying: “everyone” is used to CGRect. I’ve been
trying to think of other types that are as fundamental, but so far I haven’t
thought of any beyond NS/CGRect/Point/Size
>
> On 1 Jul 2015, at 23:58, Charles Srstka wrote:
>
> On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas wrote:
>>
>> Only because you are used to CGRect. QuickDraw used to defined a rect using
>> left, top, right, bottom values.
>
> Actually, it was top, left, bottom, right.
>
> Charles
>
And
On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas wrote:
>
> Only because you are used to CGRect. QuickDraw used to defined a rect using
> left, top, right, bottom values.
Actually, it was top, left, bottom, right.
Charles
___
Cocoa-dev mailing list (
> Le 30 juin 2015 à 23:46, Quincey Morris
> a écrit :
>
> On Jun 29, 2015, at 15:42 , Rick Mann wrote:
>>
>> Here's an example (and this is what I frequently encounter) where requiring
>> parameter names adds nothing but clutter:
>>
>> let config = WKWebViewConfiguration()
>> self.webVi
On Jun 30, 2015, at 15:10 , Charles Srstka wrote:
>
> This may be true for some cases, but I disagree with this particular example.
Yes, you’re right. I simply zoned out when making up that name. I really meant
something like ‘animateWithFrame’.
However this example wasn’t to suggest anything
On Jun 30, 2015, at 4:46 PM, Quincey Morris
wrote:
>
> 1. If the function/method being called has extremely well-known parameters,
> then I think I’d prefer the function to have a form that omits the names. In
> particular, CGRect, CGPoint and CGSize:
>
>> let rect = CGRect (x: 0, y: 0,
On Jun 29, 2015, at 15:42 , Rick Mann wrote:
>
> Here's an example (and this is what I frequently encounter) where requiring
> parameter names adds nothing but clutter:
>
>let config = WKWebViewConfiguration()
>self.webView = WKWebView(frame: self.webViewContainer.frame,
> configuratio
> On Jun 29, 2015, at 16:06 , Quincey Morris
> wrote:
>
> Please stop
Nice.
--
Rick Mann
rm...@latencyzero.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact
On Jun 29, 2015, at 15:42 , Rick Mann wrote:
>
> Here's an example (and this is what I frequently encounter) where requiring
> parameter names adds nothing but clutter:
>
>let config = WKWebViewConfiguration()
>self.webView = WKWebView(frame: self.webViewContainer.frame,
> configuratio
> On Jun 29, 2015, at 15:50 , Greg Parker wrote:
>
> Perhaps you would prefer a different whitespace convention, one with no
> spaces around the colon in actual parameters. That's a popular convention in
> Objective-C. Otherwise there is no difference between Objective-C and Swift
> here.
I
> On Jun 29, 2015, at 3:42 PM, Rick Mann wrote:
>
> Here's an example (and this is what I frequently encounter) where requiring
> parameter names adds nothing but clutter:
>
>let config = WKWebViewConfiguration()
>self.webView = WKWebView(frame: self.webViewContainer.frame,
> configur
Here's an example (and this is what I frequently encounter) where requiring
parameter names adds nothing but clutter:
let config = WKWebViewConfiguration()
self.webView = WKWebView(frame: self.webViewContainer.frame, configuration:
config);
If Code Completion worked 100% of the time, an
> On 25 Jun 2015, at 16:50, dangerwillrobinsondan...@gmail.com wrote:
>
>
>> On 2015/06/25, at 15:49, Britt Durbrow
>> wrote:
>>
>> IMHO, named parameters at call sites are one of the things that makes
>> Objective-C great; and I am VERY happy that Swift-2 enforces this.
>
> I agree whole h
> On 2015/06/25, at 15:49, Britt Durbrow
> wrote:
>
> IMHO, named parameters at call sites are one of the things that makes
> Objective-C great; and I am VERY happy that Swift-2 enforces this.
I agree whole heartedly.
But will call out that it is a considered and thoughtful design by Cocoa a
IMHO, named parameters at call sites are one of the things that makes
Objective-C great; and I am VERY happy that Swift-2 enforces this.
It is not any additional burden in any modern IDE to have this; as the IDE’s
autocomplete fills in the parameter names for you.
Also, consider a body of code
>> code such as that above wouldn’t be an issue.
>
> Again, pretty huge burden.
Only a burden to one who wants the ability to call functions or methods with
or without argument names. Many (most?) are not asking for that ability.
___
Cocoa-dev maili
> On 25 Jun 2015, at 8:13 am, Rick Mann wrote:
>
> I guess I disagree with this assertion. Generally, in a given body of code,
> the usage will be consistent, and of course there are the billions of lines
> of existing (C) code where no parameter names are specified.
Reminds me of when I fi
> On Jun 24, 2015, at 15:43 , Alex Kac wrote:
>
> As I wrote above, where you are assigning a type at that moment - no. Its
> quite obvious. You're doing it right there where its obvious. Frankly, I
> don't see the two things as being the two sides of the same coin. In one case
> the type is
> On Jun 24, 2015, at 16:37 , Marco S Hyman wrote:
>
> On Jun 24, 2015, at 4:09 PM, Rick Mann wrote:
>>
>> I guess I disagree: it's obvious in most cases. Again, I'm just arguing for
>> the OPTION. You can always choose to use the parameter name if you wish.
>
> You have the option. Given t
On Jun 24, 2015, at 4:09 PM, Rick Mann wrote:
>
> I guess I disagree: it's obvious in most cases. Again, I'm just arguing for
> the OPTION. You can always choose to use the parameter name if you wish.
You have the option. Given this signature:
func foo(intArg: Int, stringArg: String) -> Bo
> On Jun 24, 2015, at 14:53 , Greg Parker wrote:
>
> Swift 2 established a single default naming rule for all methods and global
> functions. Swift 1 had two different rules which was confusing. The naming
> rule (first parameter un-named, additional parameters named) was chosen
> because it
> On Jun 24, 2015, at 15:43 , Alex Kac wrote:
>
> As I wrote above, where you are assigning a type at that moment - no. Its
> quite obvious. You're doing it right there where its obvious. Frankly, I
> don't see the two things as being the two sides of the same coin. In one case
> the type is
As I wrote above, where you are assigning a type at that moment - no. Its
quite obvious. You're doing it right there where its obvious. Frankly, I
don't see the two things as being the two sides of the same coin. In one
case the type is seen pretty obviously because you're assigning it. In the
othe
> On Jun 24, 2015, at 15:25 , Alex Kac wrote:
>
> I guess I cannot agree with you, Rick. I love the fact that Objective-C and
> now Swift require parameter names. I prefer verbose function names,
> parameters, etc.. than obtuse ones. I don't want to have to infer. I want it
> to be explicit.
I guess I cannot agree with you, Rick. I love the fact that Objective-C and
now Swift require parameter names. I prefer verbose function names,
parameters, etc.. than obtuse ones. I don't want to have to infer. I want
it to be explicit. Infering types works because let myAttribString =
NSMutableAtt
> On Jun 24, 2015, at 14:53 , Greg Parker wrote:
>
> Swift's design is that the API author gets to choose what the call site looks
> like. Allowing the caller to choose whether to specify names or not hurts
> readability because of the inconsistency. It's bad for different calls to the
> same
> On Jun 24, 2015, at 2:09 PM, Rick Mann wrote:
>
> I'm really liking Swift 2, and after watching some of the WWDC2015 videos on
> the subject, I can't wait to use it in a real project.
>
> But one area where it REALLY bugs me is that external parameter names are
> required. I can see their u
> On Jun 24, 2015, at 2:09 PM, Rick Mann wrote:
>
> But I don't understand the need to require the use of external names at the
> call site. If there's enough information available to the compiler at the
> call site to unambiguously choose a function or method to call, why must I
> supply the
I'm really liking Swift 2, and after watching some of the WWDC2015 videos on
the subject, I can't wait to use it in a real project.
But one area where it REALLY bugs me is that external parameter names are
required. I can see their utility, particularly with regard to a set of default
values an
34 matches
Mail list logo
