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

G. Wade Johnson gwadej at anomaly.org
Thu Apr 15 12:14:54 GMT 2010


On Wed, 14 Apr 2010 21:03:05 -0700
Darren Duncan <darren at darrenduncan.net> wrote:

> Hello,
> 
> I'm hoping for some quick feedback that would influence my Muldis D
> language design (which can express anything you can express in SQL,
> but better, and from which you can generate SQL) in the short term,
> but it also applies to language design in general.

[snip]

> My apologies if you find any of this message difficult to follow, but
> mainly what I just want to know is your opinion in a programming
> language if you prefer to use overloaded syntax or type specific
> syntax.  Or if you prefer either depending on context, then what
> kinds of contexts those are.  Thank you.

[snip]

Having worked in C++ with a pretty generic operator-overloading system
and Forth which supports no overloading (not even adding integers and
floats). I can definitely say that the answer is not trivial.

Although operator overloading can be used badly (which we saw 15 years
ago in C++), it can be done well provided you remember a simple rule:
"do as the ints do".

With numerics types, operator overloading is essential for reasonable
expressiveness. Otherwise, the actual expressions become overwhelmed by
type conversions or 17 different '+' operators. But, you should not
overload a single operator to do something outside the functionality of
something integer-like.

Concatenation on string-types is another place where operator
overloading seems to work well. Converting between different string
types does not help to express what you need in the code.

As for the collections, having methods that are too generic can be a
problem. However, if they are specified well, this can be done. The
issue may need to be specifying multiple operations with more narrowly
defined behaviors and specifying the cost of use.

This is another case where C++ is a good example, the operations on
what used to be called the STL collections are carefully specified to
tell you exactly what will be returned and how much it costs.

In other languages, I've sometimes had to rely on profiling to figure
out whether or not a particular method was doing what I expect. That
wasn't an issue with the STL.

G. Wade
-- 
Controlling complexity is the essence of computer programming
                                                  -- Brian Kernighan



More information about the DBIx-Class mailing list