www.digitalmars.com         C & C++   DMDScript  

D - Feature of Objective C, save&restore

reply nicO <nicolas.boulay ifrance.com> writes:
Some friend told me about some "great" feature of Objective C. He said
that class have some default methode soon defined. 

For example the .restore() and .save("filename"), this function directly
store the content of the object into a file and restore() are used to
rebuild the old object. This kind of file could be written in XML or by
using presentation layer of the ISO model (to be not machine dependant).
So it save a lot of code to do it cleanly and without bug !

nicO
Aug 22 2001
parent reply Russ Lewis <russ deming-os.org> writes:
nicO wrote:

 Some friend told me about some "great" feature of Objective C. He said
 that class have some default methode soon defined.

 For example the .restore() and .save("filename"), this function directly
 store the content of the object into a file and restore() are used to
 rebuild the old object. This kind of file could be written in XML or by
 using presentation layer of the ISO model (to be not machine dependant).
 So it save a lot of code to do it cleanly and without bug !

 nicO

This would probably be a good feature for a class in the standard library.
Aug 22 2001
parent reply "Bradeeoh" <bradeeoh crosswinds.net> writes:
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.

Aug 22 2001
next sibling parent reply Russ Lewis <russ deming-os.org> writes:
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.
Aug 22 2001
next sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Russ Lewis wrote:
 ...
 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.
 
 

by a private null method in some classes? I don't yet understand how inheritance will be working in D. Does: int method (int, float); clash with: myInt method (int, float); ? what about with: int method (int, int); ? (I assume ok) int method (); ? (I assume ok) void method (int, float); ? hope it's ok. and I'm assuming that a method which is public in a parent can become private in a descendant via being overridden. If it's then made public again in a new descendant layer, is it a related function? What happens if you call super? Or can it be made public again?
Aug 22 2001
prev sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
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


 it could be an (abstract?) feature of Object.

 Java doesn't do this particular feature, but it does provide a whole


 gangload of functionality at the "Object" class level.  And amazingly


 it is.  Let me tell you how nice it is to be guaranteed that every


 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


 one of the best programming "innovations" of the 20th century...

Yes, toString was great, and it (or something similar) probably should be

 method of D's Object.

 I don't think that .equals() will be necessary, since we have a

 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

 in Object, since it doesn't make sense for some class types.

Oct 23 2001
parent reply "Walter" <walter digitalmars.com> writes:
"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

 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.
Feb 08 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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

 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.
Feb 08 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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,



 each
 class one of these values is tedious, and is one of the reasons MFC



 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.
Feb 09 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a42tcb$hrc$4 digitaldaemon.com...

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

Right. I remember Delphi had something like this: type IMalloc = interface(IInterface) ['{00000002-0000-0000-C000-000000000046}'] ... end; In D it could be an attribute: guid(00000002-0000-0000-C000-000000000046) interface IMalloc { }
Feb 09 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a4343e$l5c$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:a42tcb$hrc$4 digitaldaemon.com...

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

Right. I remember Delphi had something like this: type IMalloc = interface(IInterface) ['{00000002-0000-0000-C000-000000000046}'] ... end; In D it could be an attribute: guid(00000002-0000-0000-C000-000000000046) interface IMalloc { }

neither looks right <g>
Feb 09 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a43tq2$11uk$1 digitaldaemon.com...

 neither looks right <g>

Other ideas, then?
Feb 09 2002
prev sibling next sibling parent reply "Kent Sandvik" <sandvik excitehome.net> writes:
"Bradeeoh" <bradeeoh crosswinds.net> wrote in message
news:9m14ji$171h$1 digitaldaemon.com...
 My thought would be that, since all classes ultimately derive from

 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

 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.

Default persistent store and retrievals (maybe to XML format) would also be nice. But it's questionable if the language itself should implement this, most likely this should go to a runtime library environment. --Kent
Aug 22 2001
parent reply nicO <nicolas.boulay ifrance.com> writes:
Kent Sandvik a écrit :
 
 "Bradeeoh" <bradeeoh crosswinds.net> wrote in message
 news:9m14ji$171h$1 digitaldaemon.com...
 My thought would be that, since all classes ultimately derive from

 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

 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.

Default persistent store and retrievals (maybe to XML format) would also be nice. But it's questionable if the language itself should implement this, most likely this should go to a runtime library environment. --Kent

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. nicO
Aug 23 2001
next sibling parent "e.sammer" <eric lifeless.net> writes:
nicO wrote:
 
 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.
 
 nicO
 

actually, the way Apple does it in ObjC is something like this: (Apple calls them "plists" which is just a rigid xml dtd) <plist> <key>string</key> <value>hello world</value> <key>Array</key> <list> <value>foo is neat</value> <value>bar is better</value> </list> </plist> of course, that's not *exactly* how it's done, but you get the idea. this way, you know the datatype and the value. you can also do things like include the name of the member variable as an attribute to the <key> param like <key object="windowSize">int</key> and things like that. then, the name of the class could be an attribute to the <plist> tag, thus giving you a fully instantiatable object from an xml file. of course, this requires that you can translate a string of a class name to an instance of that class - which Cocoa (Apple's ObjC libs) can do. this is where the object introspection features come into play big time. you gotta love NeXT! e.sammer eric lifeless.net
Aug 24 2001
prev sibling parent "Kent Sandvik" <sandvik excitehome.net> writes:
"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
Aug 24 2001
prev sibling next sibling parent reply Axel Kittenberger <anshil gmx.net> writes:
 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)
Aug 23 2001
parent reply Dan Hursh <hursh infonet.isl.net> writes:
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
Aug 26 2001
parent reply Eric Gerlach <egerlach canada.com> writes:
 	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. :)
Aug 26 2001
parent Dan Hursh <hursh infonet.isl.net> writes:
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
Aug 26 2001
prev sibling next sibling parent "e.sammer" <eric lifeless.net> writes:
...in regard to ObjC's save/restore functionality...

Bradeeoh wrote:
 Java doesn't do this particular feature, but it does provide a whole other
 gangload of functionality at the "Object" class level. 
 

i'm certainly not a Java wiz, or anything, but doesn't Java have a Serialization class that some / most of the objects that are farther up the heiracrchy are derived from? i'm pretty sure (if not positive) that it is meant for sending objects across socket connections, et al, but i don't see why a swift little dev person wouldn't write them out to files. also, for the record, i'm pretty sure this class uses a binary format only used by Java - not something quite as flexible as XML. just on a side note, regarding ObjC... i do a bit of NeXT/MacOSX development with ObjC and there are some features that i now have a hard time living without - here are some and why i hold them dear... (take this with a grain of salt - most of this would fall under std class libs, but...) 1. delegates - talk about elegant! for gui development, delegates beat the crap out of callbacks (ick!) due to the ability to switch them very easily during runtime. of course, this could be done with function and member function pointers, but the nice thing is that delegates don't barf if there is no delegate. i suppose that's more implementation then anything else... 2. class / object introspection - ok, if i'm doing plugin development, this is a must. for the sake of system safety, it's a beautiful thing to be able to say: [anObject respondsToSelector:displayInWindow:]; (the C pseudo code, for those not used to ObjC style messaging, might be) ArrayType anObject; anObject.respondsToMethod(realloc(int size, ...)); 3. "implicit downcasting" / super virtual methods and classes - for this, i'll need to give some examples. first, this C++ code doesn't work too well... class A { public: A() { }; virtual ~A() { }; }; class B : public A { public: B(); ~B(); void do_something(); }; A* base = new B(); base->do_something(); delete base; this fails because class A doesn't declare "virtual void do_something()" and will not remember that it was instantiated with "= new B()". in ObjC, using the same imaginary classes, the call to "base->do_something()" (or in ObjC speak [base do_something];) would work because the "virtual aspect" of the class structure works (kinda) both ways! this of course means that you can implement methods in derived classes (not found in the base class), create a base class pointer, and legally call a method in the derived class. in C++, one would need to perform a "dynamic_cast<Derived>(BasePointer)" to acheive this result. the problem with this is HOW DO YOU KNOW WHICH CLASS YOU'RE CASTING TO AT RUNTIME!!!?!?! i suppose you could work around it with clever use of typeid calls and an if/else if/else if/... statement to kindom-come, but that's just plain ugly! what if you add another derived class? do you go back to your if/else code and add another "else"? that's not intuitive and certainly not really all that useful. ...in my humble opinion... 4. notifications - this is standard library stuff, but here goes... there is a standard NSNotification class which maintains a static object that acts as a notification center. you can get a pointer to that static instance and "listen" for all notifications that come down the pipe. you can also connect to the other side and post any notification you please. this makes some very commons tasks mega easy, like communicating between threads, event handling, objects about to go out of scope (post a ObjectAboutToDie notification in the deconstructor so your entire app knows when a thread is just about to finish or whatever), and gui programming (need to deallocate something when a child window is closing? listen for a WindowWillClose notification!) uh... i'm going to stop. in short, there are numerous things lurking in ObjC that make OO development *much* easier, more extendable, and intuitive. like i said before, most of this stuff is for standard libraries and the like, but i would imagine that designing a language with these features in mind first would help a bunch. the main problems with ObjC is speed (due to all of the information being thrown around at runtime) and type safety. somethings are just plain worth the tradeoff!!! just an opinion from a code monkey (working on a *very* big OpenGL project at the moment!) : ) e.sammer eric lifeless.net "i only say it because i wish i could code in a language that ports like java, with the speed of c, the runtime features of objc, the development time of perl, with the oo concepts of smalltalk..." (yea... don't we all wish?!) : )
Aug 23 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
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

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

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




Aug 29 2001
parent "Bradeeoh" <bradeeoh crosswinds.net> writes:
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.

Aug 29 2001