About Methods' Syntax:
I heard about two syntaxes of parameter declaraton. I use the first one for MulT and the other one for MulV:
$MathObject = (New-Module {
function MulT([int]$Factor1, [int]$Factor2) {
$Factor1 * $Factor2
}
function MulV{
param(
[int]$Factor1,
[int]$Factor2
)
return $a * $b
}
} -AsCustomObject)
What's the difference between the syntax of MulT and the syntax of MulV? Which should I use?
Named Arguments:
Cmdlets can have named arguments:
Multiply-IntegerFactors -Factor1 5 -Factor2 8
Can methods of objects have named arguments too? I'm thinking about something like:
$MathObject.MulT(-Factor1 5, -Factor2 8)
EDIT: Do you think that it's a good solution to use a hash table as argument in order to store the named arguments there?: $MathObject.MulT(#{Faktor1=5, Faktor2=8}) - Or is there any better solution?
Conventions On Methods:
There are strict naming conventions on Cmdlets (Verb-CamelCaseNoun) and modules (CamelCaseModuleName). Are there any (naming) conventions on methods too?
Thanks.
The difference in how the parameters are declared will make no differences in these 2 functions. In general, you have more flexibility to modify parameters using attributes if you use the param() syntax. There does seem to be an issue with the names of the parameters and how they are referenced in the body of the MulV function ($factor1/2 and $a/$b).
As far as using named parameters for methods, that doesn't work.
Related
I am seeing the Kotlin code:
navController.navigate("sales_order/" + it.toString()) {
popUpTo(navController.graph.findStartDestination().id) {
saveState = true
}
launchSingleTop = true
restoreState = true
}
which I can describe as "function call" (navController.navigate) "with additional body" ({...}). How such construction is called (if I want to look it up in the docs) and what does it mean?
When I checked the type of navController.navigate(...) args, then there are 2 arguments. The first argument - string - is provided in () and I am trying to guess, that everything inside {...} is the content for the second argument which has type NavOptionsBuilder in this case. So, I can guess that NavOptionsBuilder has 3 arguments: 1 function call popUpTo that returns some object and 2 named arguments (launchSingleTop, restoreState) which are Boolean type.
Am I deciphering this construction right - just another way of passing arguments - or is there something deeper?
Am I deciphering this construction right
Almost. You got the beginning right, but the end is not exactly correct.
Let's start with what you got right, and throw in some vocabulary here for posterity. Indeed, you seem to be using the overload of navigate that takes 2 arguments: a string route and a builder function.
Functions in kotlin can be passed in multiple ways, but the most common (and the one used here) is passing a lambda expression. Because the syntax for lambda expressions is based on braces ({ ... }), it makes it look like blocks of code, so the Kotlin language went one step further and allowed to pass lambda expressions outside of the parentheses of the function call when the lambda is the last argument. The reason for this is exactly to allow this kind of constructions which look like their own configuration language. This is what is usually referred to as DSLs (Domain Specific Languages).
Now about what you got wrong:
So, I can guess that NavOptionsBuilder has 3 arguments
Not really. NavOptionsBuilder is the receiver of the function that is passed as the second argument of navigate. This means that, within the lambda that you pass, a NavOptionsBuilder instance is implicitly available as this.
This, in turn, means that you can access methods and properties of NavOptionsBuilder within that lambda block. This is what popUpTo, launchSingleTop, and restoreState are: methods and properties of NavOptionsBuilder - not "arguments".
You can find more general info about this here.
It is possible to use some i.e. local module to return let' say same calculated output. But how can you pass some parameters? So each time you will ask for the output value you will get different value according to the parameter(ie different prefix)
Is it possible to pass resource to module and enhance it with tags?
I can imagine that both cases are more likely to be case for providers, but for some simple case it should work maybe. The best would be if they implemented some custom function that you will be able to call at will.
It is possible in principle to write a Terraform module that only contains "named values", which is the broad term for the three module features Input Variables (analogous to function arguments), Local Values (analogous to local declarations inside your function), and Output Values (analogous to return values).
Such a module would not contain any resource or data blocks at all and would therefore be a "computation-only" module, which therefore has all of the same capabilities as a function in a functional programming language.
variable "a" {
type = number
}
variable "b" {
type = number
}
locals {
sum = var.a + var.b
}
output "sum" {
value = local.sum
}
The above example is contrived just to show the principle. A "function" this simple doesn't really need the local value local.sum, because its expression could just be written inline in the value of output "sum", but I wanted to show examples of all three of the relevant constructs here.
You would "call the function" by declaring a module call referring to the directory containing the file with the above source code in it:
module "example" {
source = "./modules/sum"
a = 1
b = 2
}
output "result" {
value = module.example.sum
}
I included the output "result" block here to show how you can refer to the result of the "function" elsewhere in your module, as module.example.sum.
Of course, this syntax is much more "chunky" than a typical function call, so in practice Terraform module authors will use this approach only when the factored out logic is significant enough to justify it. Verbosity aside though, you can include as many module blocks referring to that same module as you like if you need to call the "function" with different sets of arguments. Each call to the module can take a different set of input variable values and therefore produce a different result.
Kotlin is one of the languages that allow us to easily define behavior for various predefined operators, operation named operator overloading - https://kotlinlang.org/docs/reference/operator-overloading.html
My question is regarding the overloading part of the operation.
From what I see default the language only declares operators for the basic types - https://github.com/JetBrains/kotlin/blob/01a613dca4042dde8d2374ff0e6610cb9eddc415/core/builtins/native/kotlin/Primitives.kt
If I'm reading this correctly our custom types would not have any of this special methods - operators available by default. And indeed if we're to try
class A { }
val a = A()
System.out.println(a + a)
the compiler would try to find a suitable operator plus method to call but ultimately give a compilation error.
But if we do declare our own operator plus method
class A {
operator fun plus(other: A) = "Hello!"
}
val a = A()
System.out.println(a + a)
we would indeed have "Hello!" printed.
The above mechanism is called "operator overloading" but without a previous method with the same name we do not in fact use the OOP method overloading we all are accustomed to - https://en.wikipedia.org/wiki/Function_overloading.
So between the two mechanisms - operator overloading and method overloading there is really no connection, other than an unfortunate name clash?
Looks like you are confused about operators in general.
The thing about operators is that they are just inline functions and the operator keyword is just a language construct to give you the ability to group operators with classes.
Where you can find answers about this is definitely the source code. If we take a look at the tests, we can find the following:
// "Create local variable '-'" "false"
// ACTION: Create extension function 'A.minus'
// ACTION: Create member function 'A.minus'
// ACTION: Replace overloaded operator with function call
Sadly, I cannot find the source code where operator is transformed, but most certainly this must be the procedure where the operator overload is replaced with function call.
I have a project where we have a mix of different naming when a function needs to find an object using a property given in parameter. I am wondering if there is a naming convention for the following:
function getObjectUsingName(name){} // A
function getObjectByName(name){} // B
function getObjectWithName(name){} // C
More basically, it there a different meaning between them or it is only a matter of choosing one?
I would say it is only matters for easy to read the code. And usually people choose "by". So function getObjectByName(name){} would be the nicest way but it is only based on my experience.
what's the naming convention for a function that searches an entity by 4 parameters?
for instance GetCarByColourBrandStyleAndType sounds way too long although is descriptive enought IMO
Can't you just use SearchForCar for instance?
The paramaters (I expect are type, brand, color...) should give clarification? You can always make one or more parameters optional when you have for example another function saying GetCarByBrandColor()