[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: QUrl in KDE 4
From:       Frans Englich <frans.englich () telia ! com>
Date:       2005-05-20 1:54:00
Message-ID: 200505200202.31960.frans.englich () telia ! com
[Download RAW message or body]

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
> hostname).


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" 
level.

Hence, I don't see representation problem Thiago sees. Perhaps an elaboration 
can be provided?


Cheers,

		Frans
[prev in list] [next in list] [prev in thread] [next in thread]