On Fri, Jun 03, 2005 at 07:18:56PM +0200, Leopold Toetsch wrote: > Chip Salzenberg wrote: > >On Fri, Jun 03, 2005 at 02:50:38PM +0200, Leopold Toetsch wrote: > >>I've announced and summarized all these changes, e.g. > >>http://xrl.us/gayp on Apr. 8th > > > >I didn't realize the implications when that was posted. I think the > >I think the native fallbacks are important. > > ... and probably dangerous. Given two array-ish instances of a class > that implements __get_integer (get array size)
Well, aside from everything else, I think __get_integer shouldn't return array size. But anyway. > >> cl = subclass "Float", "MyFloat" > > > >In particular, I don't like the idea that an empty subclass provides > >functionality that ought to have been available already. > > ++verbose please. Perhaps I misunderstood, but I thought you were implying that MyFloat would automatically have some features that Float did not, just by virtue of the derivation. Sorry if I got that wrong. > I still don't see the point that an arbitrary "Foo" class shall have MMD > functions of a Float/Integer mix. Hm. That's an interesting point. One could argue that by providing __get_integer, Foo class is automatically implying that it would serve where an Integer would. This is obviously what Dan was expecting. :-, On the other hand, C++ has been down that road, and it has potholes. Just because an X->Y conversion exists does _not_ imply that an X will do every place you want a Y. Ask anyone who's accidentally passed a string as a char* without noticing. (C< operator char * () > is _not_ always your friend, and see also the C<explicit> keyword in ANSI C++.) The new status quo is looking better. -- Chip Salzenberg <[EMAIL PROTECTED]>
