QUrl in KDE 4

Frans Englich 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
> 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" 

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



More information about the kde-core-devel mailing list