home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11546 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  3.3 KB

  1. Xref: sparky comp.lang.c++:11546 comp.std.c++:958
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  4. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  5. Subject: Re: Language extensions for run-time type identification
  6. Message-ID: <1992Jul25.184058.29673@ucc.su.OZ.AU>
  7. Sender: news@ucc.su.OZ.AU
  8. Nntp-Posting-Host: extro.ucc.su.oz.au
  9. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  10. References: <1992Jul21.094204.20100@mole-end> <1992Jul24.142452.756@ucc.su.OZ.AU> <1992Jul25.072522.4316@uunet.uu.net!mole-end>
  11. Date: Sat, 25 Jul 1992 18:40:58 GMT
  12. Lines: 73
  13.  
  14. In article <1992Jul25.072522.4316@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
  15. >In article <1992Jul24.142452.756@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  16. >> In article <1992Jul23.183041.147@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
  17. >>     But I would make that argument backwards.
  18. >>     One often wants het. aggregates of unrelated types.
  19. >>     Actually, these are aggregates of the *same* type,
  20. >> namely, the union of the unrelated types.
  21. >
  22. >No, they are aggregates of objects which share some common property
  23. >represented by some base type.
  24.  
  25.     No wait, I said we often want aggregates of *unrelated* types.
  26. You cant change that on meb and say they have a common base!
  27.  
  28.     Example: aggregates of numbers, some float, some int.
  29.     There's no common base here.
  30.  
  31.     Example: baskets of fruit. No common base desired.
  32.     (the baskets are just for eating, the fruits have no
  33.     properties of interest)
  34. >
  35. >A union of three types, related or unrelated, is not any of those types.
  36. >It is something else.
  37.  
  38.     Yes, it is the union of the types. Which is a type.
  39. >>     On the otherhand, polymorphism is the mechanism by which
  40. >> the derived type NEED NOT BE KNOWN. Indeed, if we are to preserve
  41. >> the open/closed principle, MUST NOT BE KNOWN.
  42. >
  43. >Not so, since the current RTTI proposal would not look past private
  44. >derivation.
  45.  
  46.     I think you are confused here (but it might be me :-)
  47.  
  48.     Private derivation hides the BASE class.
  49.     A reference to a base class hides the derived class.
  50.     THAT is requires by the open/closed principle,
  51. the derived class --- JUST LIKE THE PRIVATE part of the
  52. base class --- is IMPLEMENTATION DETAIL and MUST BE HIDDEN
  53. for the SAME REASONS.
  54. >
  55. >>     So you (well, X3) is considering using RTTI in
  56. >> precisely the case it is not needed, and not supplying it
  57. >> when it actually could be useful :-)
  58. >
  59. >You are offering a type system error (union of A, B, and C as either
  60. >an A or a B or a C) instead of using the type system to support the
  61. >commonality deliberately programmed into the types.
  62.  
  63.     But you want the type system not to support the commonality
  64. (which it already does--thats called polymorphism )
  65. but to support the non-common bits.
  66. >
  67. >(Anyone got a good intro to either classical or modern category theory?
  68. >And I don't mean the mathematical muddle on morphisms ...)
  69.  
  70.     Tis not a muddle: tis a superb theory (the mathematical one).
  71.  
  72. >-- 
  73. > (This man's opinions are his own.)
  74. > From mole-end                Mark Terribile
  75. >
  76. > uunet!mole-end!mat, Somewhere in Matawan, NJ
  77.  
  78.  
  79. -- 
  80. ;----------------------------------------------------------------------
  81.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  82.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  83. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  84.