I am asking two questions here, which are probably 100% independent. Thankfully, on the new platform we may choose more than one "correct answer", so this shouldn't be an issue.
Both questions are about user-defined types. To illustrate, suppose I developed a UDT FRAC to implement rational fractions - with a user-defined constructor FRAC(NUM integer, DEN integer). User defined rather than the default, because I want to check that the inputs are indeed integers - as PL/SQL doesn't see "integer" as a constraint - and that both are not null and the denominator is not zero.
To implement addition, I can create either a member function with one parameter, adding a "second" fraction given as argument to the "first" fraction (SELF), or I can create a static function FR_ADD with two parameters. I like the latter better, since adding two fractions is a "behavior" of the class, it is not a "behavior" of an individual fraction, even though logically they may be the same.
My first question - I believe the answer is no but I want to make sure - is: does PL/SQL support overloading of arithmetic operators? That is, instead of
FR_ADD(FRAC(2, 5), FRAC(1, 10))
I would like to be able to write
FRAC(2, 5) + FRAC(1, 10)
after defining + for the UDT. Is there any way to do that, or at least something close to it?
Second question: Suppose I defined a static function TO_FRAC(k INTEGER) returning FRAC(k, 1). Then, if I need to add, say, 33/5 and 12, I can write something like
FR_ADD(FRAC(33, 5), TO_FRAC(12))
What I would like to be able to do is something like
FR_ADD(FRAC(33, 5), 12)
but this would require the interpreter to recognize that the second argument is an integer, the function requires a fraction, there is a function to convert integers to fractions, and an implicit conversion is possible and valid in this context. Does anything like that exist? Or are there any tricks that get us there at least in some special cases?
Of course, ideally I would like to be able to do something like
FRAC(33, 5) + 12
combining both concepts; I am afraid that neither is possible, but I thought I'd ask rather than assume.