• Charles Hixson (14/14) Aug 16 2001 It would be desireable if D provided support for the implementation of
• Kent Sandvik (9/13) Aug 16 2001 I agree, something I liked in C# was the flattening of data structures
• Tim Sweeney (8/22) Aug 17 2001 If a language has complete support for introspection (discovering all fi...
• Richard Krehbiel (10/12) Aug 20 2001 fields
• Sean L. Palmer (8/20) Oct 29 2001 for
• weingart cs.ualberta.ca (Tobias Weingartner) (6/11) Aug 20 2001 To the best of my knowledge, you can't serialize functions in java.
• Sean L. Palmer (15/26) Oct 29 2001 fields
• Walter (9/37) Nov 09 2001 I intend for D to support introspection. It makes garbage collection mor...

Charles Hixson <charleshixsn earthlink.net> writes:

It would be desireable if D provided support for the implementation of 
persistant objects.  Basically some way of reading back in as objects of 
the same type that they were when they were stored, and then using them 
as objects of that type.

As far as I can tell, this requires that "virtual" objects be allowed to 
be called by any function, and that they raise a "Does Not Understand" 
exception if the object that they actually turn out to be doesn't 
understand the method.  Since type identification information is already 
being stored with each object, a large part of the necessary is already 
in place.

N.B.:  I am not saying that D should implement these features.  Merely 
that it would be desireable if the support for them were designed into 
the language, so that if they were implemented as libraries, they would 
fit in smoothly.

"Kent Sandvik" <sandvik excitehome.net> writes:

structures. This would make it really easy to integrate code that relates to
for example SOAP or any other http transaction, saving state, profiles, and
so forth. Wish more languages had a similar simple mapping (now this could
be done with an library, but having it built into the language would enforce
the use of it. --Kent

"Charles Hixson" <charleshixsn earthlink.net> wrote in message
news:3B7BF417.5030509 earthlink.net...
 It would be desireable if D provided support for the implementation of
 persistant objects.  Basically some way of reading back in as objects of
 the same type that they were when they were stored, and then using them
 as objects of that type.

"Tim Sweeney" <tim epicgames.com> writes:

If a language has complete support for introspection (discovering all fields
of objects at runtime), then it's easy for users to implement arbitrary
persistence algorithms, such as XML or various binary formats.  So a desire
for persistence can be simplified into a more general desire for complete
(perhaps Java-style) introspection support.

-Tim

"Charles Hixson" <charleshixsn earthlink.net> wrote in message
news:3B7BF417.5030509 earthlink.net...
 It would be desireable if D provided support for the implementation of
 persistant objects.  Basically some way of reading back in as objects of
 the same type that they were when they were stored, and then using them
 as objects of that type.

 As far as I can tell, this requires that "virtual" objects be allowed to
 be called by any function, and that they raise a "Does Not Understand"
 exception if the object that they actually turn out to be doesn't
 understand the method.  Since type identification information is already
 being stored with each object, a large part of the necessary is already
 in place.

 N.B.:  I am not saying that D should implement these features.  Merely
 that it would be desireable if the support for them were designed into
 the language, so that if they were implemented as libraries, they would
 fit in smoothly.

"Richard Krehbiel" <rich kastle.com> writes:

"Tim Sweeney" <tim epicgames.com> wrote in message
news:9lkgfr$2ogq$1 digitaldaemon.com...
 If a language has complete support for introspection (discovering all

fields
 of objects at runtime),

Gads, no!  I would rather not have to carry around the type information for
all my temporary loop variables, on the zilch-chance that I'll be
serializing them.

If I need Java, I know where to find it.

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 home.com (personal)

"Sean L. Palmer" <spalmer iname.com> writes:

"Richard Krehbiel" <rich kastle.com> wrote in message
news:9lr7mf$mtk$1 digitaldaemon.com...
 "Tim Sweeney" <tim epicgames.com> wrote in message
 news:9lkgfr$2ogq$1 digitaldaemon.com...
 If a language has complete support for introspection (discovering all

 fields
 of objects at runtime),

 Gads, no!  I would rather not have to carry around the type information

for
 all my temporary loop variables, on the zilch-chance that I'll be
 serializing them.

 If I need Java, I know where to find it.

 --
 Richard Krehbiel, Arlington, VA, USA
 rich kastle.com (work) or krehbiel3 home.com (personal)

If the compiler can tell if something is being serialized or not, it can
decide not to include any type info.  In any case the type info generally
becomes part of the vtable for polymorphic classes, and is essentially
static overhead *per class*, not per object.

Sean

weingart cs.ualberta.ca (Tobias Weingartner) writes:

In article <9lkgfr$2ogq$1 digitaldaemon.com>, Tim Sweeney wrote:
 If a language has complete support for introspection (discovering all fields
 of objects at runtime), then it's easy for users to implement arbitrary
 persistence algorithms, such as XML or various binary formats.  So a desire
 for persistence can be simplified into a more general desire for complete
 (perhaps Java-style) introspection support.

To the best of my knowledge, you can't serialize functions in java.
Then again, I might be wrong.  Seems I remember something like this
from the smalltalk-byte-code -> java-byte-code translater I helped do a
little while ago...

--Toby.

"Sean L. Palmer" <spalmer iname.com> writes:

"Tobias Weingartner" <weingart cs.ualberta.ca> wrote in message
news:slrn9o2g6i.3ej.weingart irricana.cs.ualberta.ca...
 In article <9lkgfr$2ogq$1 digitaldaemon.com>, Tim Sweeney wrote:
 If a language has complete support for introspection (discovering all


fields
 of objects at runtime), then it's easy for users to implement arbitrary
 persistence algorithms, such as XML or various binary formats.  So a


desire
 for persistence can be simplified into a more general desire for


complete
 (perhaps Java-style) introspection support.

 To the best of my knowledge, you can't serialize functions in java.
 Then again, I might be wrong.  Seems I remember something like this
 from the smalltalk-byte-code -> java-byte-code translater I helped do a
 little while ago...

 --Toby.

Why would you want to serialize a function?  You can't dynamically generate
a function anyway, at least not in C++ or, from what I've seen so far, in D.
You can have pointers to functions that you can point at code you've built
somewhere in some OS-specific way, but you'll likely have to override the
serialization behavior for this kind of thing to make sure the function it
points to gets generated on load if it hasn't been already.

Not something I'm particularly concerned with, but serialization in general
is such a mundane issue I'd really like to have the compiler help automate
it, if not standardize it.

Sean

"Walter" <walter digitalmars.com> writes:

I intend for D to support introspection. It makes garbage collection more
effective, as well as making persistance possible. It also makes it easier
for debuggers <g>.

"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9rj8hb$2tfo$1 digitaldaemon.com...
 "Tobias Weingartner" <weingart cs.ualberta.ca> wrote in message
 news:slrn9o2g6i.3ej.weingart irricana.cs.ualberta.ca...
 In article <9lkgfr$2ogq$1 digitaldaemon.com>, Tim Sweeney wrote:
 If a language has complete support for introspection (discovering all


 fields
 of objects at runtime), then it's easy for users to implement



arbitrary
 persistence algorithms, such as XML or various binary formats.  So a


 desire
 for persistence can be simplified into a more general desire for


 complete
 (perhaps Java-style) introspection support.

 To the best of my knowledge, you can't serialize functions in java.
 Then again, I might be wrong.  Seems I remember something like this
 from the smalltalk-byte-code -> java-byte-code translater I helped do a
 little while ago...

 --Toby.

 Why would you want to serialize a function?  You can't dynamically

generate
 a function anyway, at least not in C++ or, from what I've seen so far, in

D.
 You can have pointers to functions that you can point at code you've built
 somewhere in some OS-specific way, but you'll likely have to override the
 serialization behavior for this kind of thing to make sure the function it
 points to gets generated on load if it hasn't been already.

 Not something I'm particularly concerned with, but serialization in

general
 is such a mundane issue I'd really like to have the compiler help automate
 it, if not standardize it.

 Sean