On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas mail...@xenonium.com 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
___
On 1 Jul 2015, at 23:58, Charles Srstka cocoa...@charlessoft.com wrote:
On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas mail...@xenonium.com 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,
Le 30 juin 2015 à 23:46, Quincey Morris quinceymor...@rivergatesoftware.com
a écrit :
On Jun 29, 2015, at 15:42 , Rick Mann rm...@latencyzero.com wrote:
Here's an example (and this is what I frequently encounter) where requiring
parameter names adds nothing but clutter:
let config
On Jul 1, 2015, at 09:07 , Roland King r...@rols.org 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
On Jul 1, 2015, at 8:58 AM, Charles Srstka cocoa...@charlessoft.com wrote:
On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas mail...@xenonium.com wrote:
Only because you are used to CGRect. QuickDraw used to defined a rect using
left, top, right, bottom values.
Actually, it was top,
On Jul 1, 2015, at 08:09 , Jean-Daniel Dupas mail...@xenonium.com 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
On 2 Jul 2015, at 11:15 am, Charles Srstka cocoa...@charlessoft.com 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
On 2 Jul 2015, at 7:22 am, Greg Parker gpar...@apple.com 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
On Jul 1, 2015, at 6:28 PM, Graham Cox graham@bigpond.com 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,
On Jun 29, 2015, at 15:42 , Rick Mann rm...@latencyzero.com 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,
On Jun 30, 2015, at 15:10 , Charles Srstka cocoa...@charlessoft.com 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
On Jun 30, 2015, at 4:46 PM, Quincey Morris
quinceymor...@rivergatesoftware.com 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:
On Jun 29, 2015, at 3:42 PM, Rick Mann rm...@latencyzero.com 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:
On Jun 29, 2015, at 15:50 , Greg Parker gpar...@apple.com 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'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,
On Jun 29, 2015, at 16:06 , Quincey Morris
quinceymor...@rivergatesoftware.com 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
On Jun 29, 2015, at 15:42 , Rick Mann rm...@latencyzero.com 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,
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
On 25 Jun 2015, at 16:50, dangerwillrobinsondan...@gmail.com wrote:
On 2015/06/25, at 15:49, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com 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
On 2015/06/25, at 15:49, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com 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
On Jun 24, 2015, at 15:25 , Alex Kac a...@webis.net 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
On Jun 24, 2015, at 14:53 , Greg Parker gpar...@apple.com 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
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
On Jun 24, 2015, at 2:09 PM, Rick Mann rm...@latencyzero.com 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
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
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 =
NSMutableAttributableString() is very clear. That's my two cents.
Again, I'm just asking for the option
On Jun 24, 2015, at 2:09 PM, Rick Mann rm...@latencyzero.com 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
On Jun 24, 2015, at 15:43 , Alex Kac a...@webis.net 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
On Jun 24, 2015, at 16:37 , Marco S Hyman m...@snafu.org wrote:
On Jun 24, 2015, at 4:09 PM, Rick Mann rm...@latencyzero.com 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
On 25 Jun 2015, at 8:13 am, Rick Mann rm...@latencyzero.com 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.
On Jun 24, 2015, at 4:09 PM, Rick Mann rm...@latencyzero.com 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,
On Jun 24, 2015, at 15:43 , Alex Kac a...@webis.net 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
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 mailing
On Jun 24, 2015, at 14:53 , Greg Parker gpar...@apple.com 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
34 matches
Mail list logo
