🚀 go-pugleaf

chased@rbbb.Eng.Sun.COM (David Chase) writes:

>And yes, I think closures are a good idea.  I have no special sympathy
>for existing code that uses pointers to member functions; first, I've
>never come across such code, and second, it wouldn't be the first time
>that a change to the language broke existing code.  I'm certain that
>I'd have more use for this than for (say) multiple inheritance (why
>so?  because I've needed to use this a couple of times already and
>simulated it clumsily, and because I haven't ever used multiple
>inheritance, even though it is already in the language.)

Yes, I also think closures are a good idea, but what I want to comment on,
is your other statements made in this paragraph.  I think pointers to
members are usable when implementing storable composite objects.  I've
done a hack using MI where every class that should be storeable inherits
from a base class "Tagged" which implements the functions store & fetch.
Essentially these functions parses a class static table of Tagged::*
and stores/fetch them from a file and/or stream.  Well, there's more to
it than that of course, in order to be able to store/fetch arbitary
object graphs.  This way, only the table need to be set up in collection
classes.  Primitive classes must of course implement an actual_store/
actual_fetch member to store/fetch its state.

					Niklas

-- 
Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG, Sweden     mcsun!sunic!chalmers!appli!niklas