[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Should separate media spans (Span) from hull spans (SpanArea)
- To: ZZ Development <zzdev@xxxxxxxxxx>
- Subject: Should separate media spans (Span) from hull spans (SpanArea)
- From: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Date: Fri, 20 Apr 2001 22:43:19 +0200
The doc of Span currently asks:
This means that there are actually two fundamental types
of spans: one which denotes a particular, fixed block of
media, and another which denotes all media in a general area.
The content of the second type is not immutable and does not
actually make much sense to look at; rather, that type is mostly
used for building trees.
XXX Should these be different classes?
I'd say yes. The current implementation of spans is already getting very
messy-- NOT good. Plus, intersect(Span) and even hull(Span) get much
harder when hull spans are treated just like media spans. Comparisons we
shouldn't even think of. Additionally, we _can_ only implement
intersect, hull etc. if we _explicitly_ distinguish between
"PhysicalSpan"s and "LogicalSpan"s (media and hull spans), because Span
doesn't give us a way to retrieve any kind of address for it (save
through the currently undefined toString()). And this means that an
implementation of Span that implements neither LogicalSpan nor
PhysicalSpan will break the system.
To me, this suggests very strongly the common Span interface doesn't
make much sense.
I suggest to have Span and SpanArea. Span should be what's PhysicalSpan
now, and SpanArea should be what's LogicalSpan. You can build a SpanArea
that is just the same area as a corresponding Span-- but you can _use_
it differently. Namely, we can ask whether a SpanArea intersects another
SpanArea, we can compare or hull them, and we do not need to separate
different cases-- we can compare the scroll blocks of the start and end
spans of the two areas, and if that's still ambiguous, we can call the
respective methods of the start and end spans. We can have intersections
and comparisons inside Spans, but here we know the object we
compare/intersect with is a media span and thus limited to one scroll
block. We can request its scroll block and compare it to ours. In
intersect, when the scroll blocks are different we already know there's
no intersection. When the scroll blocks are equal, we know we're talking
about the same kind of media; we can thus compare the offsets inside the block.
So I'd say let's get rid of the current complexity ASAP. SpanArea can
probably be a final class.