On Tuesday 12 February 2008 21:19, Naik, Roshan wrote:
One criticism I have is the overloading of the logical or/and operators, which will create confusion in people reading code that uses Castor. The logical operators have very precise and well-understood meaning for any C/C++ programmer, and what Castor uses them for definitely isn't it. I know some other people have very liberal views about operator overloading, but they're just wrong :)
Lets put it like this:
eq(x,"logical operators have very precise meaning") && eq(y, "it is well-understood meaning for any C/C++ programmer") && eq(z, "what Castor uses them for definitely isn't it")
"Logic"ally you stated : x && y && z. These logical operators are used logically. :)
You're kind of making my point as I'm sure I have no idea what you're talking about. I realize your operations correspond in a broad sense to types of logical or/and operations. My position is more like: if the operation doesn't return a bool, it shouldn't even be in the realm of consideration for overloading operator|| or operator&&.
Also, the relation class seems to be a bit nebulous, as in it seems to embody multiple ideas. It's a fact, it's a collection of facts, or maybe it's a rule too. This criticism may not be well founded though, as I said before I'm not speaking from any experience with logic programming here.
In LP the term "relation" is essentially "some set of information". Wether the information is made up of facts, rules, facts+rules or is empty or infinite it doesn't matter. The class relation in Castor is smiply a way to carry this information around and put it to use.
Ok, but there are no more specialized types corresponding to more specific ideas. It's sort of like building a program with nothing but one class called "object". So, you get into this position where you're doing things like having the dereferencing operator return a different result each time it's called, because maybe the relation is really a collection of relations, and you want to extract them individually somehow. It seems like you would be better off having a well defined container class that holds fact objects, for example. -- Frank