Readable code, taken too far (too Swift)?
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dog
class and changes it's name property to the value that is sent in the 2nd param (String
). The external variable for the first param (of typeDog
) isof
and the internal name of that same param isd
. The external name of the 2nd param ( -
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dog
class and changes it's name property to the value that is sent in the 2nd param (String
). The external variable for the first param (of typeDog
) isof
and the internal name of that same param isd
. The external name of the 2nd param (I did kinda like that when I first learned it but then... I think I'm too steeped in keeping code compact. Not Ruby-esque compact, but the need to explicitly name every input variable started grating. I do prefer the C# way where naming input parameters is opt-in instead of opt-out.
cheers Chris Maunder
-
I did kinda like that when I first learned it but then... I think I'm too steeped in keeping code compact. Not Ruby-esque compact, but the need to explicitly name every input variable started grating. I do prefer the C# way where naming input parameters is opt-in instead of opt-out.
cheers Chris Maunder
Maunder said:
the need to explicitly name every input variable started grating.
:thumbsup: 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.
-
Maunder said:
the need to explicitly name every input variable started grating.
:thumbsup: 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'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dog
class and changes it's name property to the value that is sent in the 2nd param (String
). The external variable for the first param (of typeDog
) isof
and the internal name of that same param isd
. The external name of the 2nd param (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 ischangeName(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, writechangeName(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 writechangeName(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
-
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 ischangeName(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, writechangeName(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 writechangeName(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'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dog
class and changes it's name property to the value that is sent in the 2nd param (String
). The external variable for the first param (of typeDog
) isof
and the internal name of that same param isd
. The external name of the 2nd param (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 ') :(
' to give expressions likeCHANGENAME(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 did kinda like that when I first learned it but then... I think I'm too steeped in keeping code compact. Not Ruby-esque compact, but the need to explicitly name every input variable started grating. I do prefer the C# way where naming input parameters is opt-in instead of opt-out.
cheers Chris Maunder
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dog
class and changes it's name property to the value that is sent in the 2nd param (String
). The external variable for the first param (of typeDog
) isof
and the internal name of that same param isd
. The external name of the 2nd param (Well I think we know where Osmo ended up. X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X|
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dog
class and changes it's name property to the value that is sent in the 2nd param (String
). The external variable for the first param (of typeDog
) isof
and the internal name of that same param isd
. The external name of the 2nd param (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.
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dog
class and changes it's name property to the value that is sent in the 2nd param (String
). The external variable for the first param (of typeDog
) isof
and the internal name of that same param isd
. The external name of the 2nd param (What if it's a cat? (Using C#, interfaces and "named parms")
Cat cat = new Cat(){ Name = "Whiskers" };
ChangeName( of: cat, to: "Fluffy" );
// OR
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
-
What if it's a cat? (Using C#, interfaces and "named parms")
Cat cat = new Cat(){ Name = "Whiskers" };
ChangeName( of: cat, to: "Fluffy" );
// OR
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
-
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.
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dog
class and changes it's name property to the value that is sent in the 2nd param (String
). The external variable for the first param (of typeDog
) isof
and the internal name of that same param isd
. The external name of the 2nd param (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 :suss: 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.
-
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 :suss: 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.
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dog
class and changes it's name property to the value that is sent in the 2nd param (String
). The external variable for the first param (of typeDog
) isof
and the internal name of that same param isd
. The external name of the 2nd param ( -
IMHO it's requiring coders do what's basically IDE's job. See the "Parameter name hints" in this Idea manpage: View code reference info - Help | IntelliJ IDEA[^]
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.
-
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.
-
The topic is on Swift language, not a particular IDE. And for the record, programmers at Apple are old-school idiots who think syntactic sparseness is compatible with security code worked by other 5000 people.
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dog
class and changes it's name property to the value that is sent in the 2nd param (String
). The external variable for the first param (of typeDog
) isof
and the internal name of that same param isd
. The external name of the 2nd param (Smalltalk had similar readability, achieved differently. In this case, an object
kennel
may define a methodchangeNameOf: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.