Call the same method but with different arguments, better way - ruby

I have something like this in my function with calls the print_hash function three times but with different args. How to do it nicer?
The print_hash function is just only about print key and value.
print_hash(#hash1)
print_hash(#hash2)
print_hash(#hash3)
Thanks in advance

You can try something like:
[#hash1, #hash2, #hash3].each(&method(:print_hash))

Related

Function call as an another function argument (refactor)

I was looking for existing questions that could help me but I couldn't really find one - maybe I had trouble with "building" the question properly, So I'm sorry if this does exist already.
Let's get to the point: I have a function that takes one argument of List<string> type and returns let's say a formatted list:
private List<string> BasicMethod(List<string> addresses)
so normally, you would call
var someAddresses = AnotherMethod();
var formattedAddresses = BasicMethod(someAddresses);
But I wanted to refactor the code so I skipped the someAddresses variable and I called the function like that:
var formattedAddresses = BasicMethod(AnotherMethod());
Question: Is it considered a good thing to pass a function argument as an another function call or does this affect readability and the overall "cleanliness" of the code in the negative way?
Thanks for all of the answers and as always, happy coding!
I think if you use variable someAddresses only in this scope of code, then you can use a direct call of function instead variable. But you should name your function AnotherMethod in a good style for clearness.

Why would a bash function be enclosed within a variable using quotes?

I've seen how several Bash functions are often constructed, but I've never quite seen something like this:
TEST="
function mined {
// do something here
}
mined
"
I'm a little confused as to why anyone would create a function like above as opposed to simply normally creating the function and calling it? So if I understand this correctly, does the TEST variable represent a call to the mined function?

How to pass elements of an array as arguments without usage of asterisk

I have a method which returns two element arrays:
def method_from
....
[value1, value2]
end
I need to send this array to another method, which also may take additional arguments:
def method_to(param1, param2, opts = {})
I want to have a simple interface:
obj2.method_to obj1.method_from
obj2.method_to obj1.method_from, option: 'value'
It's possible make it with additional asterisk:
obj2.method_to *obj1.method_from, option: value
but the code does not seem clean, because I need to know response structure of method_from to call method_to.
Is it possible to make an interface without using an asterisk for this case?
When you observe "the code does not seem clean, because I need to know response structure of method_from to call method_to" you're sort of on the right track, but at the same time, you're also missing the bigger picture. You're trying to fit the output of one function to the inputs of another, and generally that means the two need to be compatible.
If method_from could emit some kind of object you can simply supply to method_to your problem is solved, you just pass it through. The trouble is these two methods were not designed to inter-operate that way.
This means you're stuck doing what you're doing with the asterisk, because after all what you want is a splat. The alternative is this even hackier solution:
def method_to(*args, **options)
param1, param2 = args.flatten
# Rest of code
end
Where that method can now take arguments of the form:
method_to(value1, value2, option: 'value')
Or the pass-through variant:
method_to([ value1, value2 ], option: 'value')

Understanding a Cobweb code

I'm trying to run a cobweb code in Mathematica and I need the following script:
ClearAll[CobwebPlot]
Options[CobwebPlot]=Join[{CobStyle->Automatic},Options[Graphics]];
CobwebPlot[f_,start_?NumericQ,n_,xrange:{xmin_,xmax_},opts:OptionsPattern[]]:=Module[{cob,x,g1,coor},
cob=NestList[f,N[start],n];
coor = Partition[Riffle[cob,cob],2,1];
coor[[1,2]]=0;
cobstyle=OptionValue[CobwebPlot,CobStyle];
cobstyle=If[cobstyle===Automatic,Red,cobstyle];
g1=Graphics[{cobstyle,Line[coor]}];
Show[{Plot[{x,f[x]},{x,xmin,xmax},PlotStyle->{{Thick,Black},Black}],g1},FilterRules[{opts},Options[Graphics]]]
]
Manipulate[CobwebPlot[Sqrt[3#-1]&,\[Alpha],40,{0,5},PlotRange->{{0,4.5},{0,3.65}},Frame->True,Axes->False,CobStyle->Directive[Dashed,Red],PlotRangePadding->None],{\[Alpha],0.5,4.375}]
I found the script online but I don't understand some features, such as what is the purpose of the following characters, # and &, in the Manipulate[] segment of the code:
Manipulate[CobwebPlot[Sqrt[3#-1]&,\[Alpha],40,{0,5},PlotRange->{{0,4.5},{0,3.65}},Frame->True,Axes->False,CobStyle->Directive[Dashed,Red],PlotRangePadding->None],{\[Alpha],0.5,4.375}]
Can you help me?
See this Mathematica documentation page on pure functions, or what other languages call anonymous functions, or lambda functions.
To give a cute example, suppose you have the function
doItTwice[x_,f_] := f[f[x]];
Now say you want to use this function to square the number seven twice. One way to do this would be to define a square function like this:
square[x_] := x^2;
doItTwice[7, square]
Well, there is a cleaner way to do this by simply writing the square function as a pure function, which would look like (#^2)&. The # is the parameter to the pure function, and the & is just there to indicate that it's a pure function. Really the parenthesis aren't even necessary, so you could write #^2&. Anyways, the following code is now a cleaner way to square seven twice:
doItTwice[7, (#^2)&]

Are there any avantages to using Call when calling a function in VBscript?

Forgive me if the answer is obvious as it has been a long time since I have programmed vbscript.
Are there any avantages to using Call when calling a function in vbscript?
For example:
SomeFunction param1, param2
vs
Call SomeFunction (param1, param2)
The difference as per MSDN -
To call a Sub procedure from another procedure, type the name of the procedure along with values for any required arguments, each separated by a comma. The Call statement is not required, but if you do use it, you must enclose any arguments in parentheses.
The following example shows two calls to the MyProc procedure. One uses the Call statement in the code; the other doesn't. Both do exactly the same thing.
Call MyProc(firstarg, secondarg)
MyProc firstarg, secondarg
Notice that the parentheses are omitted in the call when the Call statement isn't used.
No, there is not.
Call is usually used for subroutines and not functions, but either way there is no differences. However when it comes to functions you can retrieve a value return from the function, where as a subroutine can not. Example
result = SomeFunction("param1")
Function SomeFunction(someArg)
SomeFunction = someArg & "Hey There"
End Function
this would return "param1 Hey There" to the "result" value
result = SomeSub("param1")
Sub SomeSub(someArg)
SomeSub = someArg & "Hey There"
End Sub
but in this case "result" won't have any value, because subroutines can't do this.
It really just depends on how much you like parenthesis. Coming from a c-family background, it looks incredibly odd to me to not have them.

Resources