|
Maunder said: the need to explicitly name every input variable started grating.
Yeah i wondered if it might be nifty the first dozen times then become too much.
And I think the example is nifty but so odd to name the vars to help the function call make a natural language sentence.
|
|
|
|
|
Yeah - like a fluid interface. But not really.
cheers
Chris Maunder
|
|
|
|
|
I use this in VB (6, Applications, .Net) sometimes, but I'd prefer to have the option. Most of the time it simply doesn't help the readability of the calling code.
|
|
|
|
|
Gross. So it is foisted onto the development team to making the decision as to which pattern to consistently use: _ so the syntax is changeName(d, "Rover") or to use named external parameters so the syntax is changeName(of:d, to:"Rover") . That is, if it's even a conscious decision.
But of course, the next team / outsource group / other library may use the opposite pattern, so your Swift code will be a smattering of the two, and it seems like the only way to tell which one you need to use is by inspecting the function declaration? Because I seriously doubt whatever editor you use has sophisticated intellisense to help you, or am I wrong in this?
So, what is the benefit of named external parameters? Merely the fact that you can also, if you're Hungarian or like RPN, write changeName(to:"Rover", of:d) ??? Is there any concept of optional parameters that have default values if not set?
And even worse, can you mix the two, so you could write changeName(d, to:"Rover") ?
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Yes, you'd have to decide at the outset if you were really going to follow that type of pattern and it could get very mixed up.
Also, XCode does seem to help with a Intellisense type of functionality.
Marc Clifton wrote: And even worse, can you mix the two,
And, yes, you can definitely mix the two. The creator of the original function can use the _ to indicate the external name is not required and can use it on 0 or more params.
I can see that the language creators were trying to allow developers to convey more meaning but not sure external names really help.
It feels like what has recently been done with fluent interfaces[^]
mock.expects(once()).method("m").with( or(stringContains("hello"), stringContains("howdy")) );
The attempt to make it read like natural language. I think it works well with unit testing frameworks, but not sure about all code.
|
|
|
|
|
I remember that Algol 60 (used in my uni. days) had a different approach. When calling a function, you could separate parameters using either ', ' or ') <letter string> :( ' to give expressions like
CHANGENAME(D) THE DOG CHANGES NAME TO :( NEWNAME) (we only had uppercase characters ). I didn't use that syntax very much - it was confusing because the ) looked like an end of a parameter list, not the start of an inline comment
|
|
|
|
|
|
I think partly this is a holdover from Objective-C. For example, this Cocoa method call:
UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Hello!"
message:@"Hello, world!"
delegate:nil
cancelButtonTitle:@"Close"
otherButtonTitles:nil];
which calls initWithTitle to create a new pop-up with a message for the user. It uses the external notation and if I remember correctly (always problematic) the notation was required on all but the first argument, where it was optional.
This used to be more important when mixing Swift with Objective-C, but now most (if not all) of the various OS APIs are implemented in Swift, so it's less relevant. The exception is if you're using your own Objective-C code with Swift, or slowly converting a project over from one to the other.
|
|
|
|
|
Interesting, thanks for explaining by connecting it back to Objective-C.
|
|
|
|
|
What if it's a cat?
(Using C#, interfaces and "named parms")
Cat cat = new Cat(){ Name = "Whiskers" };
ChangeName( of: cat, to: "Fluffy" );
ChangeName( to: "Fluffy", of: cat );
public STATIC void ChangeName(IRenameable of, string to) {
of.Name = to;
}
public interface IRenameable {
string Name {get;set;}
}
public class Cat: IRenameable {
public string Name {get;set;}
}
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Nice example.
Do you prefer code in that style?
|
|
|
|
|
Wow. I've recently learned Prolog (though I still have a much greater fondness for TLA+[^]) so I appreciate the _ "forget-about-it" convention but wow, requiring named parameters in absence of "anonymous" ones? FeelsBadMan
Just use F#, C#, or others depending on your needs. Apple doesn't do anything well including their phone which is based mostly on advertising.
|
|
|
|
|
Jon McKee wrote: requiring named parameters in absence of "anonymous" ones? FeelsBadMan
I agree.
|
|
|
|
|
|
Quote: IMHO it's requiring coders do what's basically IDE's job.
Ding ding, we have a winner. Did not expect this from Apple.
|
|
|
|
|
Why Apple? Idea is Jet Brains'.
|
|
|
|
|
|
My point was that language designers spent time to add a future which enforces some stupid rule on developers, instead spending that time implementing an IDE plugin which does the job (likely faster and better than developers anyway). Because everybody uses IDE nowadays, right? Uhm... wait.
And for the recored, no-single-liners and no-assigment-in-comparison policies suddenly started to make sense... idiots.
|
|
|
|
|
Wow, I hadn't seen that Apple bug you linked before.
I mean seriously, most C compilers will produce a warning for that, let alone Lint-style tools. For a company in there position not to be using at least those on crucial code like SSL shows that they really have no respect for their users.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Smalltalk had similar readability, achieved differently.
In this case, an object kennel may define a method changeNameOf:To: would be invoked as follows:
kennel changeNameOf: d To: 'Fido'.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: Smalltalk had similar readability, achieved differently
Interesting.
So what you're saying is that Swift is trying to copy syntax that is used by a 46 year old language.
Just kidding.
|
|
|
|
|
I suppose it helps Swift code read more like Objective-C code.
That's important in this context, because Objective-C basically grafted Smalltalk's object system onto C. And so ObjC's object syntax ended up being very Smalltalk-like.
I really enjoyed it in Smalltalk. I felt that it made for very readable, understandable code. It didn't work as well and ObjC because there was a huge clash between the C syntax and the Smalltalk syntax.
At first, I disliked this syntax in Swift. But in the end, I decided it was just one of those things that I disliked because it was different than what I was used to. After a while, I didn't mind it so much.
I find it a lot uglier in Swift than in Smalltalk, however, since in Smalltalk you don't use brackets when sending a message to an object. The Smalltalk debugging environment is also way more fun. Test driven development is fun in Smalltalk, because if you write a test that calls a method that doesn't exist yet, it's no problem. The Smalltalk debugger will yell at you, pause execution, and then give you an opportunity to implement the method before resuming execution.
Like many things in life, though, it's definitely a matter of taste and opinion. Some people will never like this aspect of Swift, and I think it's completely fine for them to feel that way.
|
|
|
|
|
That's a nice summary of what Swift is trying to do and I wouldn't have known any of that about it coming from smalltalk etc. I do like readable code, but I find this type of syntax almost gets in the way since things get named very oddly just to make them begin to make natural language sentences.
I like things like a player object that has a bool property of hasSpecialAbility so I can do things like:
if (payer.hasSpecialAbility){
}
Maybe the Swift stuff will grow on me as I use it more. Only time will tell.
Thanks for the great discussion.
|
|
|
|
|
I'll have to learn and use Swift. This year ...
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Good luck. I started writing some of it up here at CP : iOS 12 Programming Fundamentals With Swift: Intro & Chpt1[^]
I find that learning Xcode (IDE) is a barrier too. I'm definitely accustomed to VStudio and Android Studio. The odd way that you add code when a button is clicked (see article) just doesn't feel natural to me.
|
|
|
|