func mapEachElement (inArray arr: [Int], withFunc aFunc: (Int))
Why would there be "inArray and then "arr"...what's the point?
Same for "withFunc and "aFunc", it makes it more code complicated and also messier to read, why are they even used?
inArray is external name which the caller of the function should use when passing parameters. arr is the internal name which the function implementer uses in the implementation to refer to the parameter. You don't have to supply external name.It makes it more readable. It is more like to make swift function names and parameters readable as Objective-C functions are.
I'm not sold on the issue of having different internal and external names either.
Having or not having external names makes sense to me.
object.BeepXTimes(6) doesn't need an external name for it's parameter because the function name implies the meaning of the parameter.
The rationale, I think, is that sometimes the naming of a function's external parameters is phrased to make sense to the caller in a sentence:
someView.animateInWithDuration(0.25, withTimingFunction: .easeIn)
The external name withTimingFunction makes the function call read like a sentence, but withTimingFunction makes a lousy internal parameter name. You would probably want your parameter name to be just timingFunction. Having separate internal and external parameter names lets you do that.
For me, though, the extra complexity this requires in the function definition doesn't seem worth it. The good news is that the default is to create parameters using the same name for both internal and external parameter names, so the standard syntax is simple and easy to read.
These are internal and external parameter names.
Just like in Obj-C, you might have
- (void)calculateFoo:(id)foo withBar:(id)bar ...
[object calculateFoo:var1 withBar:var2];
in Swift, we use
func calculateFoo(foo: AnyObject, withBar bar: AnyObject) ...
object.calculateFoo(var1, withBar: var2)
The internal names foo and bar are only accessible inside the function/method. The external names provide the argument labels which you use to call the function.
In your case, you need to use the internal name nibBundle. That's the one accessible inside the function body.
Related
I was looking inside the create_vlabel function and noted that to get the graph_name and label_name it is used graph_name = PG_GETARG_NAME(0) and label_name = PG_GETARG_NAME(1). Since these two variables are also passed as parameters, I was thinking that, if I wanted to add one more parameter to this function, then I would need to use PG_GETARG_NAME(2) to get this parameter and use it in the function's logic. Is my assumption correct or do I need to do more tweaks to do this?
You are correct, but you also need to change the function signature in the "age--1.2.0.sql" file, updating the arguments:
CREATE FUNCTION ag_catalog.create_vlabel(graph_name name, label_name name, type new_argument)
RETURNS void
LANGUAGE c
AS 'MODULE_PATHNAME';
Note that all arguments come as a "Datum" struct, and PG_GETARG_NAME automatically converts it to a "Name" struct. If you need an argument as int32, for example, you should use PG_GETARG_INT32(index_of_the_argument), for strings, PG_GETARG_CSTRING(n), and so on.
Yes, your assumption is correct. If you want to add an additional parameter to the create_vlabel function in PostgreSQL, you can retrieve the value of the third argument using PG_GETARG_NAME(2). Keep in mind that you may need to make additional modifications to the function's logic to handle the new parameter correctly.
The answers given by Fahad Zaheer and Marco Souza are correct, but you can also create a Variadic function, with which you could have n number of arguments but one drawback is that you would have to check the type yourself. You can find more information here. You can also check many Apache Age functions made this way e.g agtype_to_int2.
Why is it that, in Powershell, the System.DayOfWeek enum can be referred to like [System.DayOfWeek], whereas the System.Environment.SpecialFolder enum must be referred to like [System.Environment+SpecialFolder] (note the plus character)?
My guess is because SpecialFolder is part of the static Environment class and DayOfWeek is sitting directly in the System namespace, but I'm having trouble finding any information on this. Normally static members would use the "static member operator", but that doesn't work in this case, nor does anything else I try except the mysterious plus character...
[System.DayOfWeek] # returns enum type
[enum]::GetValues([System.DayOfWeek]) # returns enum values
[enum]::GetValues([System.Environment.SpecialFolder]) # exception: unable to find type
[enum]::GetValues([System.Environment]::SpecialFolder) # exception: value cannot be null
[enum]::GetValues([System.Environment+SpecialFolder]) # returns enum values
System.Environment.SpecialFolder is definitely a type, and in C# both enums work the same way:
Enum.GetValues(typeof(System.Environment.SpecialFolder)) // works fine
Enum.GetValues(typeof(System.DayOfWeek)) // also works
I'd really like to understand why there's a distinction in Powershell and the reasoning behind this behaviour. Does anyone know why this is the case?
System.Environment.SpecialFolder is definitely a type
Type SpecialFolder, which is nested inside type Environment, is located in namespace System:
C# references that type as a full type name as in the quoted passage; that is, it uses . not only to separate the namespace from the containing type's name, but also to separate the latter from its nested type's name.
By contrast, PowerShell uses a .NET reflection method, Type.GetType(), to obtain a reference to the type at runtime:
That method uses a language-agnostic notation to identify types, as specified in documentation topic Specifying fully qualified type names.Tip of the hat to PetSerAl.
In that notation, it is + that is used to separate a nested type from its containing type (not ., as in C#).
That is, a PowerShell type literal ([...]) such as:
[System.Environment+SpecialFolder]
is effectively the same as taking the content between [ and ], System.Environment+SpecialFolder, and passing it as a string argument to Type.GetType, namely (expressed in PowerShell syntax):
[Type]::GetType('System.Environment+SpecialFolder')
Note that PowerShell offers convenient extensions (simplifications) to .NET's language-agnostic type notation, notably the ability to use PowerShell's type accelerators (such as [regex] for [System.Text.RegularExpressions.Regex]), the ability to omit the System. prefix from namespaces (e.g. [Collections.Generic.List`1[string]] instead of [System.Collections.Generic.List`1[string]]), and not having to specify the generic arity (e.g. `1) when a list of type argument is passed (e.g. [Collections.Generic.List[string]] instead of [Collections.Generic.List`1[string]] - see this answer) for more information.
In Javascript you can use the spread syntax in a function call like this:
console.log(...[1,2,3]);
Is there an equivalent in Reason? I tried the following:
let bound = (number, lower, upper) => {
max(lower, min(upper, number));
};
let parameters = (1,0,20);
bound(...parameters) |> Js.log;
But this gives an unknown syntax error:
Try reason snippet
There's not. Reason is a statically typed language, and lists are dynamically-sized and homogenous. It would be of very limited use, and not at all obvious how it would deal with too few or too many arguments. If you want to pass a list, you should just accept a list and deal with it appropriately, as a separate function if desired.
You could of course use a tuple instead, which is fixed-size and heterogenous, but I don't see a use-case for that either, since you might as well just call the function directly then.
For JavaScript FFI there is however the bs.splice attribute, which will allow you to apply a variable number of arguments to a js function using an array. But it needs to be called with an array literal, not just any array.
func mapEachElement (inArray arr: [Int], withFunc aFunc: (Int))
Why would there be "inArray and then "arr"...what's the point?
Same for "withFunc and "aFunc", it makes it more code complicated and also messier to read, why are they even used?
inArray is external name which the caller of the function should use when passing parameters. arr is the internal name which the function implementer uses in the implementation to refer to the parameter. You don't have to supply external name.It makes it more readable. It is more like to make swift function names and parameters readable as Objective-C functions are.
I'm not sold on the issue of having different internal and external names either.
Having or not having external names makes sense to me.
object.BeepXTimes(6) doesn't need an external name for it's parameter because the function name implies the meaning of the parameter.
The rationale, I think, is that sometimes the naming of a function's external parameters is phrased to make sense to the caller in a sentence:
someView.animateInWithDuration(0.25, withTimingFunction: .easeIn)
The external name withTimingFunction makes the function call read like a sentence, but withTimingFunction makes a lousy internal parameter name. You would probably want your parameter name to be just timingFunction. Having separate internal and external parameter names lets you do that.
For me, though, the extra complexity this requires in the function definition doesn't seem worth it. The good news is that the default is to create parameters using the same name for both internal and external parameter names, so the standard syntax is simple and easy to read.
These are internal and external parameter names.
Just like in Obj-C, you might have
- (void)calculateFoo:(id)foo withBar:(id)bar ...
[object calculateFoo:var1 withBar:var2];
in Swift, we use
func calculateFoo(foo: AnyObject, withBar bar: AnyObject) ...
object.calculateFoo(var1, withBar: var2)
The internal names foo and bar are only accessible inside the function/method. The external names provide the argument labels which you use to call the function.
In your case, you need to use the internal name nibBundle. That's the one accessible inside the function body.
I had a doubt
I know that main difference between a function and procedure is
The function compulsory returns a value where as a procedure may or may not returns value.
But when we use a function of type void it returns nothing.
Can u people please clarify my doubt.
Traditionally, a procedure returning a value has been called a function (see below), however, many modern languages dispense with the term procedure altogether, preferring to use the term function for all named code blocks.
Read more at Suite101: Procedure, subroutine or function?: Programming terminology 101 - a look at the differences in approach and definition of procedures, subroutines and functions. http://www.suite101.com/content/procedure--subroutine-or-function--a8208#ixzz1GqkE7HjE
In C and its derivatives, the term "procedure" is rarely used. C has functions some of which return a value and some of which don't. I think this is an artefact of C's heritage where before the introduction of void in ANSI C, there was no way to not return a value. By default functions returned an int which you could ignore (can still) and might be some random number if no explicit return value was specified.
In the Pascal language family, the difference is explicit, functions return a value and procedures don't. A different keyword is used in each case for the definition. Visual Basic also differentiates with functions and subroutines(?).
Since we are talking about Objective-C, there are some further issues to confuse you. Functions associated with a class or object are known as "methods" (class methods and instance methods respectively).
Also, if we are being pedantic, you don't call Objective-C methods, you invoke them by sending a message to the object. The distinction is actually quite important because the message name (aka "selector") does not necessarily always refer to the same method, it can be changed at run time. This is fundamentally different to languages like Java and C++ where a particular method name for a particular class is really just a symbolic name for the address of the block of code constituting the body of the method.
Depending on the programming language, the distinction may be not so clear. Let's take a conservative language, Pascal:
procedure indeed has no return value. It is used for operations which do not have a return value, or have multiple return values. In the latter case, multiple arguments (the return-arguments or output-arguments) are passed by reference (using the var keyword) and their values are directly modified from inside the procedure. (Note that this latter case may not be considered good practice, depending on the circumstances).
function has a single return value, and usually we do not expect it to change the value of any of its arguments (which arguments may then be passed by value, or via the const keyword). Multiple return values may be returned by bundling them into a record.
C or Java does not distinguish syntactically, so a function of return type void can be thought of as a procedure. Scala distinguished between them by the presence of an equals sign between the method head and method body.
Generally, no matter how an actual language calls its construct, we would ideally expect that
A function takes arguments, doesn't modify any state (like mutating arguments, global variables, or printing info for the user to the console), and returns the result of computation.
A procedure takes arguments, performs operations which can have side-effects (writing to a database, printing to the console, maybe mutating variables), but hopefully doesn't mutate any arguments.
In practice however, depending on the situation, blends of these expectations can be observed. Sticking to these guidelines helps I think.