Re: Objects and Relations

On Jan 31, 1:29 am, "David BL" <davi..._at_iinet.net.au> wrote:
> On Jan 31, 4:10 pm, "Marshall" <marshall.spi..._at_gmail.com> wrote:
>
> > I also have an argument that encapsulation itself is merely
> > a crutch to make up for the fact that a language lacks
> > declarative integrity constraints.
>
> Yes, I can see the sense in which private/public become unnecessary
> when adequate integrity constraints can be enforced.

Well, try to think about it first before you--wait, what?

;-)

> > Not 100% sure I understand, but it sounds like you're saying
> > nested relations are a cop-out. If so I disagree. Again, this
> > is a theory group, so we do not have to restrict ourselves
> > to discussing existing implementations or SQL or whatever.
> > As a logical model nested relations have a long history of
> > study, and they do solve some problems. My personal model
> > includes nested relations.
>
> I'm only saying that at a higher level you are dealing with strings as
> ADTs.

I suppose.

> > Yes however I consider this a non-issue. The advantage of
> > recursive structures is that one can deal with each level
> > at a time, and not have to address them all at once.
>
> It seems to me that in some sense it's not *completely* relational.

Perhaps we might rather say "not exclusively relational."

> Anyway let's not get bogged down in definitions and take that as a
> positive because it means I have far fewer objections with your way of
> thinking.

Hear hear!

> > I don't believe I have made any claims as to where the anus of
> > proof lies.
>
> An interesting typo :)

I am occasionally a smart-aleck.

> Yes, looking back at what was said I can see I may have jumped to
> false conclusions.

No matter.

> > Join of two one-attribute relations on their single attributes is
> > set intersection, which I hope you will agree is a meaningful
> > and useful operator.
>
> I'm not suggesting that there is a problem. I'm trying to say
> (perhaps badly) that if you model strings relationally you don't
> suddenly get a whole bunch of simple select-project-join queries
> across multiple relations that give you useful results. I'm
> contrasting this with more conventional applications of RM where even
> simple queries give all sorts of useful information.

Um, but isn't the number of different possible, joins say, a function of the number of attributes? So we shouldn't be surprised that relations with fewer attributes have fewer possible joins.

> I'm treating this as merely an observation. It is only weakly
> suggestive that RA/RM may have little to offer.

Okay, let's move on.

> To keep things simple I won't parameterise on type. Here's a partial
> implementation. I'm just typing this in quickly so it may not compile
>
> class StringRange
> {
> public:
> StringRange(const char* _s1, const char* _s2) :
> s1(_s1), s2(_s2) {}
> operator bool() const { return s1 != s2; }
> int size() const { return s2 - s1; }
> char operator*() const { return *s1; }
> StringRange& operator++() { ++s1; return *this; }
> StringRange prefix(int len) const
> {
> return StringRange(s1,s1+len);
> }
>
> private:
> const char* s1;
> const char* s2;
>
> };
>
> inline bool operator==(StringRange s1, StringRange s2)
> {
> if (s1.size() != s2.size()) return false;
> while(s1)
> if (*s1++ != *s2++) return false;
> return true;
>
> }
>
> Note that the implicit conversion to bool is full of pitfalls and
> should be done differently.
>
> > Even if it's a complete solution, you
> > omit the code from the StringRange class, which has to be
> > accounted for to do a fair comparison with my code.
>
> A fair comparison is difficult and trying to count the total number of
> lines is not the best measure. The StringRange class is highly
> reusable and a good basis for writing lots of string processing
> functions. Its amortized cost is nearly zero!

Yes and yes. It's hard to compare the two approaches. In particular, the C++ world is happy to hide behind method invocation and even operator overloading, and this works well for them. It's actually less of a good idea for the relational approach because it limits the amount of global optimization that can be done.

> My one liner while statement above contained the essence of the
> solution. The missing parts are rather trivial.

I don't disagree, I'm just trying to make as accurate a comparison as possible. Which is quite hard!

> > Okay. What would you find to be a convincing demonstration? If nothing
> > else I claim my substring find is quite declarative; as much so as any
> > logic program. (In fact, one could make an argument that mine *is*
> > a logic program.)
>
> In some respects it is quite elegant, and I'm happy to entertain the
> idea that with practise it would become natural to think that way.
> I'm a little sceptical though.

Let's call it a conjecture for now; I hope to have more evidence (or at least experience) in a year or two.

Marshall Received on Thu Feb 01 2007 - 08:04:32 CET