|Subject||Re: [Firebird-Architect] Exec. statement parameters|
> Vlad Khorsun escreveu:The both purposes is assignment. This is the key of the inconsistency. There is no such
> > I.e. this is assignment operator. Is it consistent to have one assignment operator (:=)
> > for one purpose, and another (=) from another purposes ? I don't think so
> It's inconsistent to use (=) here, as the purposes is different.
> When you use (:=), you are assigning to something in another "layer" (a
> calling procedure/function parameter or a named parameter).
> (=) is used to compare and assign in the same PSQL module.
syntax construction as "layer", sorry.
> >>> Yes. But how it related to the our question ? Also i suggest not allow to mix named and unnamedAdriano, this is just our inability to understand each other. I planned named input parameters
> >>> parameters at one query.
> >> And it's not good to have different syntax regarding named/unnamed
> >> parameter is used inside the exec. stmt. string.
> > EXEC STMT will use named parameters only. At least at first implementation.
> It seems you're not planning this feature good enough. You first said it
> named and unnamed parameters is (already?) available... And...
for EXEC STMT from the day one.
> > And this named parameters wouldn't been implemented at DSQL level. As we allow to call EXEC STMT fromI not creating any new parameter mechanism. I just need to set correspondence between
> > PSQL only i see no problem with compatibility in future.
> ... are creating a different parameter mechanism that work only for EXEC
> STMT, and the current existing one will not work for EXEC STMT.
named parameter and its value. Not at DSQL level. Not at PSQL level. Just in EXEC STMT
code. That is all. DSQL still worked with plain "?" as parameters.
> > Please, don't make generic statements, show examples when possible. Else we neverAgain you not understand what i want to say. Or don't want to understand
> > understand each other.
> Examples of ambiguous expressions has already posted.
> >> How many features has more votes than it? It was one of the more votedThis list is a wrong place to discuss usability of our voting system. Currently
> >> things when I looked.
> > Again, 10 votes is equal to no votes at all. My opinion of course. Currently i didn't consider
> > voting system as working\representative.
> If the voting system is not representative is another problem.
> Among the voted things, it's the more voted feature.
i don't take it into account as not representative, like you it or not. This is offtopic
here so i see no reason to continue disscussion of this theme in this list.
Ask this 10 people who vote for boolean support - "what exactly do you want".
And you get the answer - "delphi must understand boolean data type of table's fields".
Look at how boolean data type is "implemented" in IB and ask IB users if they need
something more. This is about "quality" of this votes...
> statement:Tell me please, why "x = a = b" is not ambiguous in PSQL block of code
> x = a -- always assignment
> where x = a -- always expression
> x = a = b -- a = b should always be expression with boolean
but is ambiguous in EXEC STMT input parameter syntax ???
> > Anyway, i need to move forward. I'll implement following syntax for input parameters of EXEC STMT :And to make good explanation with clean arguments
> > param_name = expression [, param_name = expression]
> > If we'll decide to change syntax it wouldn't been too hard as only parser would need to be changed
> As long you not introduce it in the main branches, I see no problem.
> One main purpose of this list is to not create features that causes
> future ones to not be possible.
> I see no problem in staged implementations (first named params. forI never said VBA is a good example of how language syntax may looks. As for Oracle - i don't
> EXEC. and latter for DSQL).
> But please do not think at current existing features only.
> Look at other implementations too. VBA uses different operator (:= and
> =). Oracle too (=> and :=).
know reasons why they introduced this ugly construction.
But i always appreciate explanations and i can be convinced by the good ones.
And, you must know, change "=" by ":=" or "=>" in one place in parce.y is a not a hardest job :)
PS first time i send this message to Adriano instead of list, sorry