August 24, 2001
"nicO" <nicolas.boulay@ifrance.com> wrote in message news:3B85D272.4CD071F2@ifrance.com...
> Kent Sandvik a écrit :
> Does it possible to add a library which can read every type of data of
> what ever object you want ? I mean, how you could access data and data
> type "from the outside" ? For me, it's impossible, if it's not include
> in the compiler.

Yes, there's somewhere a line to be drawn, as it would be quite impossible to support all kinds of persistent objects, memory pointers, and so forth. But if the default was to stream out the member fields with the known values, and a way to override it for the special cases, that would be very good. A nice thing with XML formats is that they could be shipped around with XMLRPC or Soap, and there are more and more database interfaces that now imports and exports XML.--Kent



August 26, 2001
Axel Kittenberger wrote:
> 
> > Java doesn't do this particular feature, but it does provide a whole other
> > gangload of functionality at the "Object" class level.  And amazingly
> > useful
> > it is.  Let me tell you how nice it is to be guaranteed that every single
> > class has the ".equals( Object )" method, whether or not it was properly
> > overriden.
> 
> but Java does have this particular feature, they call it "serializeable", all you had to do was to add to say "implements serializeable" in the objects header. No code to write.
> 
> The technique that's missing in C (due to the way it gets compiled) is what java calls "Reflection". There is no generic way to access an object without knowing it, but in java there is, there are calls like: get the first field of that object, what type has it? what's it's name? the value? etc. Due to this, it is possible to write a generic object writer/reader. (java's ObjectStreams)

	I could be wrong, but I thought I heard the D had some of the
functionality to help the garbage collector.  I maybe remembering wrong,
or it may not be enough info or just not the right info.  It is probably
safe to assume that the info that is used by GC would/should be consider
implementation specific.
	BTW, I think the functionality you describe is call introspection and
that reflection is when the semantics of the language can be altered
from within the language.  (Java may have that too.  I don't get into
java that much.)

Dan
August 26, 2001
> 	BTW, I think the functionality you describe is call introspection and
> that reflection is when the semantics of the language can be altered
> from within the language.  (Java may have that too.  I don't get into
> java that much.)

I remember a friend of mine (who worked on Java VMs for a bit) said that one could create some Java byte code, pass it to a special class, and it would instantiate that byte code as a class, *at runtime*.  I always thought it was neat that your Java code could write Java code and have the VM run it.  Apparantly, some VM implementations even have a built-in compiler, so you can write human-readble code, compile it and instantiate it, all at runtime.

Now *that* is introspectioon. :)

August 27, 2001
Eric Gerlach wrote:
> 
> >       BTW, I think the functionality you describe is call introspection and
> > that reflection is when the semantics of the language can be altered
> > from within the language.  (Java may have that too.  I don't get into
> > java that much.)
> 
> I remember a friend of mine (who worked on Java VMs for a bit) said that one could create some Java byte code, pass it to a special class, and it would instantiate that byte code as a class, *at runtime*.  I always thought it was neat that your Java code could write Java code and have the VM run it.  Apparantly, some VM implementations even have a built-in compiler, so you can write human-readble code, compile it and instantiate it, all at runtime.
> 
> Now *that* is introspectioon. :)

	Actually, I think that gets pretty close to Reflection.

Dan
August 29, 2001
Java forgot the ".compare(Object)" method. That would make sorting so much
easier.


Bradeeoh wrote in message <9m14ji$171h$1@digitaldaemon.com>...
>My thought would be that, since all classes ultimately derive from
"object",
>it could be an (abstract?) feature of Object.
>
>Java doesn't do this particular feature, but it does provide a whole other gangload of functionality at the "Object" class level.  And amazingly
useful
>it is.  Let me tell you how nice it is to be guaranteed that every single class has the ".equals( Object )" method, whether or not it was properly overriden.
>
>And every single object having a ".toString()" method?  That has got to be one of the best programming "innovations" of the 20th century...
>
>(yes, I understand absolutely everything that is wrong with that statement,
>but it was afterall just an exaggeration)  :)
>
>>
>> This would probably be a good feature for a class in the standard
library.
>>
>
>
>
>


August 29, 2001
True...  but while that is absent from Object, it is in their much ballyhooed "Collections Framework".    See the Javadocs on the "Comparator" class.  http://java.sun.com/j2se/1.3/docs/api/java/util/Comparator.html

It's quite easy to use, but you're right - not as easy as
Object.compare( Object )".  Though, the Java philosophy was that you could
take a collection of Objects and they may actally sort to a different order
based on what sorting standard (or comparator) you use.

So, say, if I have a collection of String Objects, I can sort them with a "Alphabetical Order Comparator" or a "Reverse Alphabetical Order" Comparator and I don't need to change anything at all in the string class, just write a new comparator.

You gotta admit, it makes sense and is kinda elegent, in a watered-down Java kind of way...  :)

-Brady

ps - I can't find documentation on the Object class in the language spec - were you putting a ".compare()" in the Object class?  If so, I may start up the argument that I've just made about using an Object independent comparator for sorting...  :)

"Walter" <walter@digitalmars.com> wrote in message news:9mi4cd$2dh0$1@digitaldaemon.com...
> Java forgot the ".compare(Object)" method. That would make sorting so much
> easier.
>



October 23, 2001
To do simple streaming, it would be nice to know at runtime something about the type in question, some unique identifier that preferrably didn't change every time you recompile the source or even better would always be the same no matter what platform you compile the D code with.

Maybe there could be a property of any type that exposed a compiler generated hash value of the class name and size?  Without it, assigning each class one of these values is tedious, and is one of the reasons MFC uses macros.  And I know how much Walter hates the preprocessor.  ;)

Then you'd need to be able to create one of the types in question at runtime, given one of these hash ids.

class A : public Streamable
{
public:
  int v1;
  override void Read(inout Stream s) { s.Read(v1); }
  override void Write(inout Stream s) { s.Write(v1); }
}

class B : public A
{
public:
  int v2;
  override void Read(inout Stream s) { super.Read(s); s.Read(v2); }
  override void Write(inout Stream s) { super.Write(s); s.Write(v2); }
}

class C : public A
{
public:
  char[] v3;
  override void Read(inout Stream s) { super.Read(s); s.Read(v3); }
  override void Write(inout Stream s) { super.Write(s); s.Write(v3); }
}

class D : public Streamable
{
public:
  A* some_a;
  override void Read(inout Stream s)
  {
    type_hash id;
    s.Read(id);

    version(1)
    {
       // use a new language hack to allow new to work on type_hash values?
       some_a = new id;                   // the problem is... all of them
must provide a default ctor!!
    }
    version(2)
    {
       switch(id)
      {
        case A.hash: some_a = new A; break;
        case B.hash: some_a = new B; break;
        case C.hash: some_a = new C; break;
        default: throw CorruptedFileException;
      }
    }

    some_a->Read(s);
  }
  override void Write(inout Stream s)
  {
    type_hash id = typeof(*some_a).hash;
    s.Write(id);
    some_a->Write(s);
  }
}


Aside: Are members private by default, as in C++ classes, or public by default, as in C++ structs?  I prefer public by default since for tiny classes that only do one thing (think STL functors) that one thing is usually always public else nobody could use it.  If it's bigger than that you can afford to type in private where you want it.

Sean

"Russ Lewis" <russ@deming-os.org> wrote in message news:3B8418FA.3C2C90E7@deming-os.org...
> Bradeeoh wrote:
>
> > My thought would be that, since all classes ultimately derive from
"object",
> > it could be an (abstract?) feature of Object.
> >
> > Java doesn't do this particular feature, but it does provide a whole
other
> > gangload of functionality at the "Object" class level.  And amazingly
useful
> > it is.  Let me tell you how nice it is to be guaranteed that every
single
> > class has the ".equals( Object )" method, whether or not it was properly
> > overriden.
> >
> > And every single object having a ".toString()" method?  That has got to
be
> > one of the best programming "innovations" of the 20th century...
>
> Yes, toString was great, and it (or something similar) probably should be
a
> method of D's Object.
>
> I don't think that .equals() will be necessary, since we have a
distinction
> between pointers and actual objects.  In D, you can do these compares:
>
> Object *a,*b;
> if( a == b ) {...}; // compares pointers
> if( *a == *b ) {...}; // compares values
>
> Anyhow, I think that save/restore *should* be in the standard library, but
*not*
> in Object, since it doesn't make sense for some class types.
>


February 09, 2002
"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9r3ceq$9df$1@digitaldaemon.com...
> Maybe there could be a property of any type that exposed a compiler generated hash value of the class name and size?  Without it, assigning
each
> class one of these values is tedious, and is one of the reasons MFC uses macros.  And I know how much Walter hates the preprocessor.  ;)

Sounds like the COM GUID.

> Aside: Are members private by default, as in C++ classes, or public by default, as in C++ structs?  I prefer public by default since for tiny classes that only do one thing (think STL functors) that one thing is usually always public else nobody could use it.  If it's bigger than that you can afford to type in private where you want it.

They default to public. Private members is a more advanced technique, and so should require the extra typing.



February 09, 2002
"Walter" <walter@digitalmars.com> wrote in message news:a41oum$2sjd$1@digitaldaemon.com...

> > Maybe there could be a property of any type that exposed a compiler generated hash value of the class name and size?  Without it, assigning
> each
> > class one of these values is tedious, and is one of the reasons MFC uses macros.  And I know how much Walter hates the preprocessor.  ;)
>
> Sounds like the COM GUID.

...but automatically generated for the class.


February 09, 2002
"Pavel Minayev" <evilone@omen.ru> wrote in message news:a42jov$6ge$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a41oum$2sjd$1@digitaldaemon.com...
>
> > > Maybe there could be a property of any type that exposed a compiler generated hash value of the class name and size?  Without it,
assigning
> > each
> > > class one of these values is tedious, and is one of the reasons MFC
uses
> > > macros.  And I know how much Walter hates the preprocessor.  ;)
> >
> > Sounds like the COM GUID.
>
> ...but automatically generated for the class.

I understand. But some more syntax would be needed in the case where you want to map an interface onto an existing GUID.