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.
 
 


Perhaps it should be a primitive feature of Object that was overridden 
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




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


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


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






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


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


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


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


 
 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


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