Please note that this question is not a duplicate of this or this, since the other questions do not have the operator component and do not ask about the details of parameters and arguments that I am asking about.
I am going to teach a first programming course using vb.net. Please note that this course will cover only procedural programming (with the focus on algorithmic thinking) and will not mention OOP, so no operator overloading.
I am seeking help in getting the terminology straight:
Is the following statement correct: a procedure can have parameters. If a procedure has parameters, then it accepts arguments?
Does the term parameter refer only to procedures or also to operators? That is, can I say that a binary operator has two parameters even when talking about built-in types (such as Integer)?
Is it wrong to say that an operator has operands? (just like it is wrong to say that a procedure has arguments)
Is the usage of two different terms -- argument and operand -- for procedures and operators, respectively, explained only by historical reasons or there is a fundamental difference between the two concepts?
Does a parameter of a procedure include the parameter's name? I think that in C++ (with the question asked about functions' parameters) the answer is "No"; what is it in vb.net?
Yes. When procedure is called, it receives arguments.
If you are looking at operator signature like +(a As Integer, b As Integer), parameters term is adequate in the context. If you are analyzing its execution then in 2 + 3 you have operands and when looking into operator method body, you just received arguments. So look into context.
Answered above.
Should be clear now. Operands are part of high-level view on operator. If analyzing expression tree, you can speak about operators and their operands. But if technically analyzing procedure for given operator, you go with parameters and arguments.
It does not. However, you can get to names using NameOf() operator or through the Reflection.
Related
What is the arity of the sql BETWEEN expression? I thought it was three (ternary) since the expression usually looks like:
WHERE...
1 BETWEEN 2 AND 3
But it's listed as binary on BigQuery's documentation, and I assume other places as well.
Source: Operators.
What is the arity of the BETWEEN expression and why? I think the answer is 3 from the following example:
select
~ (SELECT -1 AS expr_1) AS 'bitwise_arity_1',
(SELECT 1 AS expr_1) * (SELECT 2 AS expr_2) AS 'times_arity_2',
(SELECT 1 AS expr_1) BETWEEN
(SELECT 2 AS expr_2) AND (SELECT 3 AS expr_3) AS 'bitwise_arity_3?'
I suppose one way to interpret it might just be that the grammar is:
expr 'BETWEEN' logicalAndExpr
And so the two expressions in the logicalAnd are just grouped into one. Is that a correct understanding?
SQLFiddle: http://www.sqlfiddle.com/#!9/b28da2/2156
It's binary, in syntactic terms. See below for a discussion of syntax vs. semantics, where I note that a better syntactic term is "infix".
Similarly, function calls and array subscripting are postfix unary operators and the C family's conditional operator (often misnamed "the ternary operator" as though it were the only such thing) is also infix. The reason is that the interior operands (the operands between BETWEEN...AND, (...), [...], and ?...:, respectively) are fenced off from the rest of the syntax by the pair of surrounding terminal tokens which function as a syntactic barrier, like parentheses. Precedence does not penetrate to the enclosed operands; only the outer operand(s) remain floating in the syntax.
The semantic view is quite different, of course. BETWEEN...AND and ?...: are certainly three-argument functions, although since the latter is short-circuiting, only two of the three arguments are ever evaluated, which makes it hard to discuss in strict mathematical terms [Note 1]. Moreover, the semantic view is complicated by the fact that there is not just a single way to look at what an argument is. As noted in a comment, you can always curry functions into a series of unary applications of higher-order functions. Although you might be tempted to try to redefine "arity" as the length of that sequence, you will soon find higher-order functions which have different sequence lengths depending on the values of their arguments. Also, in most programming languages (unlike SQL) the function being called is a full expression which does not need to be evaluated at compile-time, and since different functions have different argument counts, there is no good way to describe the arity of a function call unless you respecify the call to be the application of a list-of-arguments object to a callable object. That's often done, but it's a bit unsatisfying because (in most languages), the list object does not really exist and cannot be observed as an object.
I'd suggest taking the Wikipedia article on arity with a good-sized saline dosage, because it completely misses the distinction between semantics and syntactic structure, giving rise to the confusing ambiguity between the semantic and syntactic view of SQL's range operator or C's conditional operator. Personally, I prefer to reserve "arity" for the semantic meaning, using "fixity" or "valence" for the syntactic feature. (The advantage of "fixity" is that it encourages the distinction between prefix and postfix, which is a real distinction hidden by calling both cases "unary operators".)
Notes
BETWEEN...AND could short-circuit, too, but standard SQL doesn't guarantee short-circuiting, as far as I know (although some SQL implementations do.)
I want to know if it's possible to pass in a list as a parameter in native queries.
When search up online, an article in Baeldung has exactly what I want to do:
Collection-Valued Positional Parameters usage
I did the exact same thing, except that in the article, they used "createQuery" and I used "createNativeQuery". Not sure if this is the reason why mine is not working.
CreateQuery means JPQL was passed in which is parsed and modified into SQL, which allows it to break the collection parameter into its components to pass each into the SQL statement. CreateNativeQuery uses your SQL which isn't modified, and JDBC doesn't understand collections so requires parameters broken up into individual arguments in the SQL. You have to do it yourself and dynamically build the SQL based on the number of parameters in the collection.
There are other questions with solutions that touch on other options, such as using SQL within criteria or JPQL queries that can let you get the best of both.
The 'xx' operator is interesting in that this:
(^100).pick xx 10
produces a list of 10 random Int's rather than one random Int repeated 10 times as a list.
Is the operator handled as a special case by the compiler? Or is it really just another sub that we can define ourselves too? (If so, I'd be very interested to know how...)
Thanks
Yes, this is one of a range of operators that currently exist as special forms in the compiler. Other examples include || and &&, which only evaluate the right hand side depending on the boolification of the left hand side.
At present, there's not a way to define such an operator yourself (or at least, not an officially supported one; if prepared to tinker in compiler internals all things are possible). However, macros - planned for the next major Raku language version - will enable this.
I was watching a course about JDBC and when the Instructor was speaking about ? (Question Mark) in Prepared Statement, he said:
Before I execute the Query, I have to fill in the placeholders or parameters.
he was talking about a query like this:
SELECT * FROM Employee where salary > ?
Now, my main question is:
what is difference between placeholder and parameter?
and isn't he wrong? can ? be either placeholder or parameter?
Edit:
I consider these two definition also:
argument is the value/variable/reference being passed in, parameter is the receiving variable
There is no difference, these are just two terms used for the same things. Which is probably why that phrase was used: to introduce both terms and indicate they can be used interchangeably. There is even a third variant where both are combined in a single term: parameter placeholder.
As I see it, the ? is a placeholder for a value, but at the same time a parameter for the query.
I would like to build a safe dynamic select statement that can handle multiple WHERE clauses.
For example the base SQL would look like:
SELECT * FROM Books Where Type='Novel'
I would pass the function something like:
SafeDynamicSQL("author,=,Herman Melville","pages,>,1000");
Which would sanitize inputs and concatenate like:
SELECT * FROM Books Where Type='Novel' AND author=#author AND pages>#pages
The function would sanitize the column name by checking against an array of predefined column names. The operator would only be allowed to be >,<,=. The value would be added as a normal paramater.
Would this still be vulnerable to SQL injection?
There will be some string manipulation and small loops which will affect performance but my thoughts are that this will only take a few milliseconds compared to the request which on average take 200ms. Would this tax the server more than I am thinking if these requests are made about once a second?
I know this isn't best practice by any means, but it will greatly speed up development. Please give me any other reasons why this could be a bad idea.
It looks like you're reinventing any number of existing ORM solutions which offer a similar API for creating WHERE clauses.
The answer to your question hinges on what you mean by "The value would be added as a normal paramater." If by that you mean performing string concatenation to produce the string you showed then yes, that would still be subject to SQL injection attack. If you mean using an actual parameterized query then you would be safe. In the later case, you would produce something like
SELECT * FROM Books Where Type='Novel' AND author=? AND pages > ?
and then bind that to a list of values like ['Herman Melville', 1000]. Exactly what it would look like depends on what programming language you're using.
Finally, if you pursue this path I would strongly recommend changing from comma-delimited arguments to three separate arguments, you'd save yourself a lot of programming time.
Pretty much any code that appends together (or interpolates) strings to create SQL is bad form from a security point of view, and is probably subject to some SQLi attack vector. Just use bound parameters and avoid the entire problem; avoiding SQL injection is super-easy.