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.

I agree, something I liked in C# was the flattening of data structures directly into XML, and reading XML structures directly into C# data 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.

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.
>

"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)

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.

"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

"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

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
>
>