From kde-core-devel  Fri May 20 03:35:11 2005
From: Michael Pyne <pynm0001 () comcast ! net>
Date: Fri, 20 May 2005 03:35:11 +0000
To: kde-core-devel
Subject: Re: QUrl in KDE 4
Message-Id: <200505192335.12168.pynm0001 () comcast ! net>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111656015010066
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1723836.MfvgP0pe2Z"

--nextPart1723836.MfvgP0pe2Z
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 19 May 2005 11:08 pm, John Firebaugh wrote:
> On May 19, 2005, at 7:02 PM, Frans Englich wrote:
> > 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.
>
> [snip]
>
> > Hence, I don't see representation problem Thiago sees. Perhaps an
> > elaboration
> > can be provided?
>
> On the contrary, class hierarchies are ill suited to this type of
> subset relationship:

The theory's all well and good guys, but if people are using a URL, it's=20
because they don't *need* a URI, which generally means they're not doing=20
URI-like things to it.  If programs are trying to turn URLs into URIs in a=
=20
class that doesn't design it, they're buggy.

Besides, in the hypothetical Square.setDim(10, 5) example, you could have t=
he=20
Square throw an exception or otherwise not comply.  It is, after all, a=20
Square.

Regards,
 - Michael Pyne

--nextPart1723836.MfvgP0pe2Z
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCjVrwqjQYp5Omm0oRAlCAAKCI21OyWnD9M9DRee8v+IfDjFXX3QCg1E0E
qjP+qhlh6siJ0OoxGhtfj6c=
=Y+GF
-----END PGP SIGNATURE-----

--nextPart1723836.MfvgP0pe2Z--