home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.lang.c++:11546 comp.std.c++:958
- Newsgroups: comp.lang.c++,comp.std.c++
- Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
- From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
- Subject: Re: Language extensions for run-time type identification
- Message-ID: <1992Jul25.184058.29673@ucc.su.OZ.AU>
- Sender: news@ucc.su.OZ.AU
- Nntp-Posting-Host: extro.ucc.su.oz.au
- Organization: MAXTAL P/L C/- University Computing Centre, Sydney
- References: <1992Jul21.094204.20100@mole-end> <1992Jul24.142452.756@ucc.su.OZ.AU> <1992Jul25.072522.4316@uunet.uu.net!mole-end>
- Date: Sat, 25 Jul 1992 18:40:58 GMT
- Lines: 73
-
- In article <1992Jul25.072522.4316@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
- >In article <1992Jul24.142452.756@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
- >> In article <1992Jul23.183041.147@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
- >
- >> But I would make that argument backwards.
- >
- >> One often wants het. aggregates of unrelated types.
- >> Actually, these are aggregates of the *same* type,
- >> namely, the union of the unrelated types.
- >
- >No, they are aggregates of objects which share some common property
- >represented by some base type.
-
- No wait, I said we often want aggregates of *unrelated* types.
- You cant change that on meb and say they have a common base!
-
- Example: aggregates of numbers, some float, some int.
- There's no common base here.
-
- Example: baskets of fruit. No common base desired.
- (the baskets are just for eating, the fruits have no
- properties of interest)
- >
- >A union of three types, related or unrelated, is not any of those types.
- >It is something else.
-
- Yes, it is the union of the types. Which is a type.
- >
- >> On the otherhand, polymorphism is the mechanism by which
- >> the derived type NEED NOT BE KNOWN. Indeed, if we are to preserve
- >> the open/closed principle, MUST NOT BE KNOWN.
- >
- >Not so, since the current RTTI proposal would not look past private
- >derivation.
-
- I think you are confused here (but it might be me :-)
-
- Private derivation hides the BASE class.
- A reference to a base class hides the derived class.
- THAT is requires by the open/closed principle,
- the derived class --- JUST LIKE THE PRIVATE part of the
- base class --- is IMPLEMENTATION DETAIL and MUST BE HIDDEN
- for the SAME REASONS.
- >
- >> So you (well, X3) is considering using RTTI in
- >> precisely the case it is not needed, and not supplying it
- >> when it actually could be useful :-)
- >
- >You are offering a type system error (union of A, B, and C as either
- >an A or a B or a C) instead of using the type system to support the
- >commonality deliberately programmed into the types.
-
- But you want the type system not to support the commonality
- (which it already does--thats called polymorphism )
- but to support the non-common bits.
- >
- >(Anyone got a good intro to either classical or modern category theory?
- >And I don't mean the mathematical muddle on morphisms ...)
-
- Tis not a muddle: tis a superb theory (the mathematical one).
-
- >--
- > (This man's opinions are his own.)
- > From mole-end Mark Terribile
- >
- > uunet!mole-end!mat, Somewhere in Matawan, NJ
-
-
- --
- ;----------------------------------------------------------------------
- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au
- Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
- ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
-