On 13 Nov 2004, at 18:48, Tim Bray wrote:
On Nov 13, 2004, at 1:29 AM, Henry Story wrote:
Reading this thread really quickly I noticed that there are a few overlapping problems that are tending to make the thinking about this a little more complicated that necessary:
I am increasingly tending to -1 on EntriesAllTheWayDown, the "simplification" it introduces feels strained and spurious. It is natural for a feed to consist of a header and some entries. Yes, they share some fields.
I think Robert Sayre's proposal shows that they don't just share a few fields, but that they share quasi all fields. That is really all that we need to show that we are in fact speaking about the same concepts.
It may seem odd to people who have been in this field for a really long time, to be told that two things they thought were distinct are really the same. But that is where one needs a little flexibility of mind.
Not only is it not "strained and spurious", this simplification is natural and obvious. When James Gosling wrote BlogEd he made the head an entry. I think this is a simplification that will feel completely natural to any OO (or other) software engineer. You have two things with a one to one mapping between their field types: immediately look to see if there is a similarity.
This would fall under Martin Fowler's "Extract Superclass" Refactoring pattern (p336):
Duplicate code is one of the principal bad things in systems. If you say things
in multiple places, then when it comes time to change what you say, you have more
things to change than you should.
One form of duplicate code is two classes that do similar things in the same way
or similar things in different ways. Objects provide a build-in mechanism to
simplify this situation with inheritance. However, you often don't notice the
commonalities until you have created some classes, in which case you need to create
the inheritance structure later.
In our case we have the limit case of this refactoring, in which after the extraction
of the commonalities of head and entry, nothing more is left. Ie we have simplified our
code from two classes down to one.
The same is clearly true in writing specifications.
Trying to pretend that the header is an entry doesn't really seem helpful. -Tim
I think this is so clearly helpful in the clarity of the spec, I find it difficult to see how this is not evident. Line number count would be a simple objective measurement of this.
When I wrote:
I noticed that there are a few overlapping problems
that are tending to make the thinking about this a little more complicated that necessary:
1- do the feed head and entry elements resemble themselves enough?
2- is a Feed an Entry?
3- is a Feed a sequence of Entries with the head element being special?
4- how does making changes affect the already dodgy inheritance problem?
5- Bob Wyman's proposals about needing to keep the whole metadata of a feed for an
Entry.
I meant that 1 is clearly to be answered in the positive. The other questions need not be affected by refactoring the head as an Entry. They are different questions. Treating them all together confuses the issue. Let's look at them one by one seperately.
Henry Story
