Jump to page: 1 2 3
Thread overview
Feature of Objective C, save&restore
Aug 22, 2001
nicO
Aug 22, 2001
Russ Lewis
Aug 22, 2001
Bradeeoh
Aug 22, 2001
Russ Lewis
Aug 22, 2001
Charles Hixson
Oct 23, 2001
Sean L. Palmer
Feb 09, 2002
Walter
Feb 09, 2002
Pavel Minayev
Feb 09, 2002
Walter
Feb 09, 2002
Pavel Minayev
Feb 09, 2002
Walter
Feb 09, 2002
Pavel Minayev
Aug 22, 2001
Kent Sandvik
Aug 23, 2001
nicO
Aug 24, 2001
e.sammer
Aug 24, 2001
Kent Sandvik
Aug 23, 2001
Axel Kittenberger
Aug 26, 2001
Dan Hursh
OT: Neat stuff with Java
Aug 26, 2001
Eric Gerlach
Aug 27, 2001
Dan Hursh
Aug 23, 2001
e.sammer
Aug 29, 2001
Walter
Aug 29, 2001
Bradeeoh
August 22, 2001
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
August 22, 2001
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.

August 22, 2001
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 22, 2001
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.

August 22, 2001
"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



August 22, 2001
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?

August 23, 2001
> 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)

August 23, 2001
...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?!) : )

August 23, 2001
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
August 24, 2001
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

« First   ‹ Prev
1 2 3