QUrl in KDE 4
frans.englich at telia.com
Fri May 20 03:02:31 BST 2005
On Thursday 19 May 2005 23:57, Richard Smith wrote:
> On Thursday 19 May 2005 21:56, Frans Englich wrote:
> > How would the performance impact be if QUrl was splitted into QUri and
> > Qurl(inheriting QUri)?
> That has the square-rectangle problem. A QUrl is not a QUri, since there
> are things you can do to a QUri that you cannot do to a QUrl (like set it
> to "foo:bar"). Likewise a QUri is not a QUrl, since there are things you
> can do to a QUrl that you cannot do to a QUri (like get/set the path or
As Thiago, I disagree, because with that approach you will find the problem in
any object oriented design; where something is a subset, constrainment, of
something wider -- what class hierarchies usually are about, AFAICT. A square
is a subset of the recangle's value space, so to speak.
If the rectangle/square problem exists for a QUri/QUrl scenario, I would say
it also exists for QValueList/QStringList. If a QUrl instance, instead of a
QUri one, is constructed from an URI string, it is a conscious decision to
constrain to "URL", and hence it is a choice to not be on the generic "URI"
Hence, I don't see representation problem Thiago sees. Perhaps an elaboration
can be provided?
More information about the kde-core-devel