What means mixed type in Laravel documentation? Does it mean that function accepts parameters of different type?
For example, I was looking at bcc function to check if I could pass array of strings as a parameter, because currently I am passing only a single string, which is not inside an array.
mixed technically means any type of variable. It is often used when more than one type of variable can be used. In your specific case, there is a big chance you can use a single or an array.
https://wiki.php.net/rfc/mixed-typehint
Related
I am looping over a set of scalars which contain quarterly sif values. I would like to convert them to hrf format and keep them stored in scalars.
However, I found that format %tq only accepts variables. Hence, the only workaround seems to i) convert the scalar to a variable ii) apply format %tq iii) convert the variable to a scalar.
Is there a more elegant and faster way to do this? (I am using Stata MP 15.1.)
You can have string scalars, so you can do this. I can't see why it would be useful, but that could be failure of imagination; you could enlighten us on why you want this.
. scalar foo = yq(2018, 4)
. scalar foo = string(scalar(foo), "%tq")
. scalar list
foo = 2018q4
What is quite different for scalars is that there is no sense whatsoever in which a display format is attached to or associated with a scalar. You can hold a numeric date or a string date in a scalar, but those are the only choices. You can't have a numeric value with a format on the side that Stata will use for display when suitable. You found that out when you attempted to format a scalar.
Goodness knows whether this is faster (than what?) or more elegant (who decides?). The major difference is that a variable manifestly can contain many dates and a changed format made just once with format can apply to them consistently, whereas changing how you show a bunch of scalars requires a loop every time you do it so far as I can see. Further, it follows from above that you might need to keep two sets of scalars, one numeric for calculation and one string for display.
I've used date constants and typically found that either I use them directly (subtracting 2000 as base doesn't requiring putting it into anything) or I use local macros to hold them. But I can't see anything wrong with using scalars, except possibly indirection.
What's the difference between sending a string and sending a symbol to call a method dynamically, e.g., foo.public_send(:bar) vs foo.public_send('bar')? Is there a concrete difference in how these are handled?
If symbols are better, is it worth to do foo.public_send('bar'.to_sym) if for some reason you need to construct your method name as a string?
There is no difference between them, in fact, when passing a string it is converted to a symbol.
No need to convert it since that same conversion (e.g. 'bar'.to_sym) will be done if a string is provided.
From the docs:
Invokes the method identified by symbol, passing it any arguments
specified. Unlike send, #public_send calls public methods only. When
the method is identified by a string, the string is converted to a
symbol.
Will jmeter function FileToString(path) takes dynamic values.
I need to use around 400 json files as a input. so planning to use FileToString($fileName}) in body data. By providing the filename column in csv. But it seems Jmeter is checking filename as file instead of getting value from csv.
You need to wrap your ${fileName} into __eval() function. As per documentation:
The eval function returns the result of evaluating a string expression.
This allows one to interpolate variable and function references in a string which is stored in a variable.
So you need to change your expression to look like:
${__FileToString(${__eval(${fileName})},,)}
For more information on JMeter functions see How to Use JMeter Functions post series.
I've encountered a problem in my bash script.
I need to assign new variables according to files in my folder and assign them a number according to the amount of arguments the script gets (whether it's a script or not).
I'm trying to get a script written like this:
n_${array[*]}=`arg_count ${array[*]}`
while arg_count checks how many parameters a script gets.
for further use, I'm going to change those variables if there's a function with different arguments needed.
Thanks in advance!
In general, you can use the declare builtin to accomplish this, because it is a command whose argument is a string that resembles an assignment.
declare "n_${array[*]}=$(arg_count ${array[*]})"
However, note that unless you set IFS appropriately and the array contents are amenable, the expansion of ${array[*]} isn't going to be a string that forms part of a valid identifier.
You probably want to either use an associative array,
declare -A n
n[${array[*]}]=$(arg_count ${array[*]})
or write your code in a programming language that properly supports data structures.
I'm trying to pass a struct into a Go template using the built-in http/template library. I'm finding, though, that if I name the struct's variables with the first letters lowercase, they are not rendered in the template, but if I name them with the first letter uppercase, they are. I see here that structs can have both upper and lower case first letters. Why, then, does the Go templating engine not render both?
For examples, see:
Uppercase first letters
Lowercase first letters
Thanks in advance.
Simply put, the template engine can't see the members when they are written in lower case
as the template engine is in another package than your struct.
You may have noticed that Go does not use private or public keywords for visibility.
Instead, all functions, members, variables and the like are public when the first letter
of the identifier is in upper case. If the identifiers are not exported they can only
be used in the same package.
The spec on exporting identifiers:
An identifier may be exported to permit access to it from another
package. An identifier is exported if both:
the first character of the identifier's name is a Unicode upper case letter (Unicode class "Lu"); and
the identifier is declared in the package block or it is a field name or method name.
All other identifiers are not exported.
That is because the Go templating engine uses reflection to get the values out of types it doesn't "know" about. Only field names that begin with an uppercase letter are exported – and therefore available to the reflection model. See here for details on the rules of what gets exported and what does not:
[Where..] the first character of the identifier's name is a Unicode upper case letter (Unicode class "Lu")...
There are some other stipulations, but thats the most important one for this.
See this post for some great information on how reflection works in go.
lowercase means private in Go so the templating code is not allowed to access the fields.