[Dbix-class] RFC - merits of overloading ops versus not doing so

Rob Kinyon rob.kinyon at gmail.com
Thu Apr 15 12:38:13 GMT 2010


On Thu, Apr 15, 2010 at 00:03, Darren Duncan <darren at darrenduncan.net> wrote:
> Right now, Muldis D has support for the overloading of operators between
> disjoint types, such that you can invoke a virtual operator in your code and
> then what would actually execute is one of several concrete operators that
> are
> specific to the data types of the primary arguments.  However, I don't yet
> spec
> any use of this feature aside from ordered and ordinal specific operators
> such
> as comparison or sorting operators.

The spec for SQLA2 actually has no support for operators at all.
Instead, what would be an operator is treated as a function. The
proximate reason for this was to handle string concatenation. MySQL
has the CONCAT function, Oracle has the infix || operator, and
SQL*Server has the infix + operator. But, MySQL uses || to mean a
C-like OR and everyone else uses infix + operator for numeric addition
(with or without implicit casting). So, it was just easier to define
functions based on operations and not operators.

Once you start talking about functions, going to multimethods is a
very natural (and rather small) step. Now, you have functions that
dispatch on both the name and the argument types (with or without
implicit casting).

I think that solves almost all the issues you're describing with
operator overloading.

-- 
Thanks,
Rob Kinyon



More information about the DBIx-Class mailing list