On 16 Nov 2004, at 15:17, Bob Wyman wrote:

Henry Story wrote:
2. A Feed is a Entry ...
I think you would probably really like this model...
No. I don't like it at all.

Mhhhh. I wonder...

Please note that I've been arguing for PaceHeadInEntry. It should be
obvious that I think that: "An Entry is a Feed." I do not think that "A Feed
is an Entry".

The model I proposed as a solution to your problem and what you
are proposing is sooooo incredibly close then :-) I wonder if we are not talking at
cross purposes...


If PaceHeadInEntry is accepted, entry is most appropriately seen as
a restricted subclass of Feed -- with the restriction being that an entry
can contain no entries.

"restricted subclass"? That just so much sounds like a superclass to me.
Are you sure we are not agreeing here? :-) In the Feed is a Entry model too an Entry contains no Entries. No difference until here it seems.


An entry is simply a single entry feed

So you are proposing:

        (a)- an Entry is a subclass of a Feed
    (b)- an Entry is a Feed that contains one and only one Entry.

So we have a relation of inheritance and a relation of composition, like in the "Feed is a Entry" model.

But the way you put it, it seems a little weird, because we have a superclass that refers to its subclass and all kinds of weird things are required.


class Feed { List<Entry> entries;

                void addEntry(Entry e) {
                        if ((this instanceof Entry && entries.size() < 1 )
                                entries.add(e);
                        else if (!this instanceOf Entry)
                                entries.add(e);                 
                }

        }

class Entry extends Feed {

void addEntry(Entry e) { //empty method
}

}

So where do the Entry stuff go, such as the title, etc...? In the Entry class or the Feed class?


and we do
some markup minimization that allows us to remove the "entry" wrapper tag
around the entry specific elements. Unfortunately, I think UML can't express
this.

I think that when you come to the conclusion that you have an idea that a widely deployed modelling tool cannot express then you should be suspicious about your idea.
Especially if you also want it to be easy to understand.


Is there any other way you could model this? Say using logic or set theory?


Saying that "A Feed is an Entry" may result in simpler UML, shorter
documents, etc. However, I think that such simplifications should not be
pursued if the cost is a loss of accuracy in the model. Elegance at the cost
of truth provides no gain.

As I said before, I don't think the vocabulary of accuracy or "truth" is a good one here. There is no Platonic reality to which we can go to see if our model is the "right" one. What you mean to say is


"elegance at the cost of functionality provides no gain".

And I think, as I will show below, that there is no loss of functionality.

        If PaceHeadInEntry is accepted, then conceptually, an Entry looks
like this:
        <entry>
                <head></head>
                <entry>
                 .. elements of entry ...
                </entry>
        </entry>

Don't you then have an infinite recursion?

        <entry>
                <head></head>
                <entry>
                        <head></head>
                        <entry>
                                <head></head>
                                <entry>
                                ....
                                ....
                                </entry>  
                 .. elements of entry ...
                </entry>
        </entry>


However, given that the inner instance of the entry tag provides no utility, we have chosen to save a few bytes and encode an entry as: <entry> <head></head> .. elements of entry ... </entry>


Ok. You want to associate an Entry with the origin feed from which it stems.

One could easily add this in the following way

        <entry>
       <origin>the orgin entry</origin>
                the elements of the entry
        </entry>

if origin is the wrong term, we can always change it.


This model supports what I've often suggested when I say that I think that a feed is simply a sliding-window on a stream of events.

Yes. So does what I am proposing.

An Entry is simply a feed with a window-size of 1.

Very similar to where I am at.

This is an important observation
if you're in the composite or aggregate feed business -- like I am. What we
require is an atomic unit that can be moved about without information loss.

Seems quite feasible with the Feed is a Entry model. In any case it seems quite feasible with the refactoring that I have proposed.



I also believe that the inheritance of and from <head/> is much more intuitive if you view an entry as a single entry feed.

I find it really difficult to get my head around what you are saying. So it does not seem at all intuitive to me. I wonder if I am alone in this position?


Entries are single entry feeds.

That just sounds so recursive!

Feeds are not entries -- they are
merely streams or collections of entries.




bob wyman




Reply via email to