i've just learned how to do coding and archiving with cocoa. Why do
one's have to implements NSCodind protocol in order to to archiving ?
Wouldn't it be possible to use objective-c's built in introspection
mecanism (to find the attributes to save) and just us NSCoding as a
flag ?

(and yeah, i know, i'm (again) thinking about java...sorry :-)

Pierre

From:	Michael Ash
Subject:	Re: introspection and archiving
Date:	Fri, 17 Dec 2004 05:37:50 -0600

Pierre Chatel wrote:
> i've just learned how to do coding and archiving with cocoa. Why do
> one's have to implements NSCodind protocol in order to to archiving ?
> Wouldn't it be possible to use objective-c's built in introspection
> mecanism (to find the attributes to save) and just us NSCoding as a
> flag ?
>
> (and yeah, i know, i'm (again) thinking about java...sorry :-)

Basically, an automatic archive doesn't give you enough control. You might
have parent pointers that you want to be conditionally archived, or you
might have instance variables that can be regenerated instead of saved.
Automatic archiving will also kill any possibility of compatibility
between code revisions.

That said, it's not that hard to do. You can write your own and play with
it. I did this, and ultimately found it to be pretty useless, but you
might not.

From:	David Stes
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 06:53:17 GMT

Michael Ash wrote:
>
> Basically, an automatic archive doesn't give you enough control.

It's convenient if it's there.

If you have a project where you want to invest in manual archiving, you can
still add it.

But when there is time pressure, it is very convenient that you can just
automatically archive classes.

From:	David Stes
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 06:50:30 GMT

Pierre Chatel wrote:
> i've just learned how to do coding and archiving with cocoa. Why do
> one's have to implements NSCodind protocol in order to to archiving ?
> Wouldn't it be possible to use objective-c's built in introspection
> mecanism (to find the attributes to save) and just us NSCoding as a
> flag ?
>
> (and yeah, i know, i'm (again) thinking about java...sorry :-)

Pierre,

the "Filer" classes of POC do this. AsciiFiler is a class that automatically
files out a id variables of a class, even if you don't write your own methods
to archive it.

This uses introspection; in the original AsciiFiler class, it was more
complete than in the current POC implementation (POC has still some limitations
on the Filer class)

It is also described in the book on Objective-C by Cox & Novobilski (see FAQ)

David Stes

From:	Charlton Wilbur
Subject:	Re: introspection and archiving
Date:	Fri, 17 Dec 2004 04:14:38 GMT

>>>>> "PC" == Pierre Chatel writes:

PC> i've just learned how to do coding and archiving with
PC> cocoa. Why do one's have to implements NSCodind protocol in
PC> order to to archiving ? Wouldn't it be possible to use
PC> objective-c's built in introspection mecanism (to find the
PC> attributes to save) and just us NSCoding as a flag ?

In part, because some attributes need to be serialized and some do
not, and only the programmer can say with any reliability what these are.

It might be sensible to have a *default* implementation that saves
everything, but I'm not sure what that really buys you.

Charlton

--
cwilbur at chromatico dot net
cwilbur at mac dot com

From:	David Stes
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 06:51:54 GMT

Charlton Wilbur wrote:
>
> In part, because some attributes need to be serialized and some do
> not, and only the programmer can say with any reliability what these are.

If that is the case, then you can model these needs in term of classes.

If you have a class with attributes that need not be serialized, write a class
with the attributes that you do want to be archived.

In other words, you model the output of the archive in an object-oriented
way (classes describe the contents of the archive)

From:	Charlton Wilbur
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 10:14:36 GMT

>>>>> "DS" == David Stes writes:

DS> Charlton Wilbur wrote:

>> In part, because some attributes need to be serialized and
>> some do not, and only the programmer can say with any
>> reliability what these are.

DS> If that is the case, then you can model these needs in term of
DS> classes.

DS> If you have a class with attributes that need not be
DS> serialized, write a class with the attributes that you do want
DS> to be archived.

In other words, instead of writing a method that serializes those
attributes that need it, I should decompose the class into two
classes. I'll grant that I save the effort it would take to write the
method, and get a little bit of aesthetic purity to appreciate -- but
I break encapsulation and make the rest of the code a lot more complex
as a result.

As a working example, I have a half-dozen or so classes in the project
I'm working on now. They all have calculation to do, and they are
dependent for that calculation on variables that come from outside the
class, which they request when needed. They all inherit from a common
parent class that handles requesting the variables and caching them as
needed; still, when I serialize an object of any of those classes, it
is foolish to serialize the cache since it will most likely be
entirely invalid when the object is reconstituted.

I suppose I could have a parent object that's composed of a class of
things that get serialized and a class of cached data that doesn't get
serialized, but that seems like a ridiculous amount of work and a
needless complication of the object model (which is already
complicated enough, as it reflects a real-world situation) when the
alternative is writing a 7-line archiving or unarchiving method
instead of an 8-line archiving or unarchiving method.

It also tends to get really complicated really fast when some of the
attributes aren't comparatively primitive data such as strings or
numbers but are user-created objects themselves: you need some way to
know which attributes are of classes that should be serialized, and
which are not, and merely using introspection seems inadequate to this
task -- especially if some attributes should be serialized in some
instances but not in others.

In short, if you serialize more than one object at a time -- and you
really need to, in order to preserve the relationships among objects
-- then introspection isn't really adequate to the task, because
there's no easy introspective way to determine which objects in a
graph should be serialized and which should not. The programmer, by
contrast, can determine this easily, though how he communicates that
is entirely dependent on the object library used.

Charlton

--
cwilbur at chromatico dot net
cwilbur at mac dot com

From:	David Stes
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 11:40:57 GMT

Charlton Wilbur wrote:
>
> DS> If you have a class with attributes that need not be
> DS> serialized, write a class with the attributes that you do want
> DS> to be archived.
>
> In other words, instead of writing a method that serializes those
> attributes that need it, I should decompose the class into two
> classes.

Indeed, this would in fact encourage you to do a proper design of what you
actually write to the archive.

It's an object-oriented representation of what is in the archive.

From:	Charlton Wilbur
Subject:	Re: introspection and archiving
Date:	Sun, 19 Dec 2004 06:44:36 GMT

>>>>> "DS" == David Stes writes:

DS> Charlton Wilbur wrote:
>>
DS> If you have a class with attributes that need not be
DS> serialized, write a class with the attributes that you do want
DS> to be archived.
>> In other words, instead of writing a method that serializes
>> those attributes that need it, I should decompose the class
>> into two classes.

DS> Indeed, this would in fact encourage you to do a proper design
DS> of what you actually write to the archive.

DS> It's an object-oriented representation of what is in the
DS> archive.

Okay, here's a question for you. I have a real-world process that I'm
modeling, and it involves lots of objects. I'm interested in how
you'd model this.

* Each object depends on a number of numeric values (represented by
keys), some of which are provided by other objects, but some of
which are provided by the user or the system state at runtime. The
fundamental design problem is how to efficiently and cleanly
propagate updates to the other objects in its group, such as when a
key-value pair changes or when a new object is added.

* Each object registers the keys it depends on and the keys it is
willing to provide with a central object for that group. This
object is actually an application-wide singleton, part of the
library I'm using, that handles this sort of notification message.

* When the object changes the value of one of its published key-value
pairs, it sends a message to the central object, which relays it to
the object-collection object, which knows which of its objects
depends on that key-value pair; the object-collection sends a message
to each object that has registered an interest in that key-value
pair, with the new value. This propagates changes.

* When an object needs the value of one of the key-value pairs it
depends on, it sends a message to the central object, which relays
it to the object-collection object, which knows which of its objects
publish that value; the object-collection sends a message to each
object that has registered as a publisher for that key-value pair,
requesting that they re-publish the value.

* Objects maintain a cache of the key-value pairs they depend on.
When they are notified that the key-value pair has changed, they
recalculate the values they publish, and only send appropriate
notifications if they have changed.

Now, the issue here is that the attributes of the object which
determine what key-value pairs they publish and what key-value pairs
they depend on *should* serialized, but the dependency information in
the object-collection object and the per-object caches *should not* be
serialized.

So if I modelled the objects containing only attributes that should be
serialized, I'd have to omit the per-object cache. If I eliminated it
entirely, the system would have a lot more overhead, because instead
of only having to propagate when a value *changed*, each object would
need to query other objects for the variables it depended on before
being able to answer a query for the variables it publishes, and in
that circumstance a simple screen refresh, which might require
displaying information on 20 objects, could result in well over a
thousand method calls: each object may depend on variables published
by 2 or more objects, which themselves depend on variables.... This
is not an acceptable price to pay for aesthetic purity.

Modelling the objects with a central cache for all objects is
attractive, but the objects themselves come in sets, and the cache
would just be an attribute of the object-collection object rather than
the objects themselves. As the object-collection object itself needs
to be serialized, without the cache, this is not an acceptable option.

Similar problems exist with the dependency information; as this is to
a large extent dependent on the system condition and the user input at
the time the application is run, there's no point in serializing it to
make it persistent. And yet the dependency information *is* an
attribute of the object-collection object; it's just an easily derived
one that can be recreated.

Now, a question in more plain language.

I have instance variables that look like this:

@interface ModelObject : Object
{
Dictionary *cache;
String *name;
Dictionary *publishedVariables;
}

What you're telling me is that it would be better to have *two*
objects that look like this:

@interface ModelObject : Object
{
String *name;
Dictionary *publishedVariables;
ModelObjectVariableCache *cache;
}

@interface ModelObjectVariableCache : Object
{
Dictionary *cache;
}

Now, suppose the object library has support for a -serialize; method,
and that all objects support it. If I say [aModelObject serialize],
under the first declaration, I get data containing cache, name, and
publishedVariables. But under the second -- unless I write code to
override -serialize, perhaps by returning nil to indicate that the
object shouldn't be serialized -- then I get data containing name,
publishedVariables, and cache -- because there's no way for
ModelObject to know which instance variables should be serialized and
which should not.

Now, I could just override -serialize in ModelObjectVariableCache.
But if I have to do that anyway, I don't see why I shouldn't just
overide -serialize in the first definition of ModelObject to prevent
serializing the cache Dictionary object. And as ModelObject, in my
real-world code, is not a single class but a dozen or so classes all
inheriting from a single parent class, requiring an additional class
each time I have something in a child class I don't want serialized
gets old FAST.

In other words, in order to maintain the aesthetic purity of not
having to manually specify which instance variables I want serialized,
I have to write substantially more code -- easily two orders of
magnitude *more* code that I would have had to write if I was manually
specifying the serialization. Isn't the idea of not having to
manually specify the serialization that it should *save me* work?

If I'm missing something obvious, please enlighten me.

Charlton

--
cwilbur at chromatico dot net
cwilbur at mac dot com

From:	David Stes
Subject:	Re: introspection and archiving
Date:	Sun, 19 Dec 2004 08:41:15 GMT

Charlton Wilbur wrote:
> DS> It's an object-oriented representation of what is in the
> DS> archive.
>
> Okay, here's a question for you. I have a real-world process that I'm
> modeling, and it involves lots of objects. I'm interested in how
> you'd model this.

There is an example of an archived object in the old AsciiFiler layout at:

http://users.pandora.be/stes/stes.pub

This is in fact an archived PublicKey object.

POC archiving is not as powerful as the old Stepstone AsciiFiler which was
more complete;

POC as a precompiler automaticaly generates code to archive an instance.

While in the Stepstone compiler, the compiler would automatically generate
a string to encode the instance variables. This string is then used at runtime
(full introspection) to serialize the object.

The latter is a bit more powerful or general than what POC does.

From:	Charlton Wilbur
Subject:	Re: introspection and archiving
Date:	Sun, 19 Dec 2004 19:44:37 GMT

>>>>> "DS" == David Stes writes:

DS> Charlton Wilbur wrote: It's
DS> an object-oriented representation of what is in the archive.
>> Okay, here's a question for you. I have a real-world process
>> that I'm modeling, and it involves lots of objects. I'm
>> interested in how you'd model this.

DS> POC archiving is not as powerful as the old Stepstone
DS> AsciiFiler which was more complete;

DS> POC as a precompiler automaticaly generates code to archive an
DS> instance.

And how does it handle attributes that should not be archived? It
does not seem to me that pulling out those attributes into another
object makes one whit of difference.

You seem to be claiming that automatically generating archiving code
in all circumstances is inherently good. Given the situation I
described -- in which objects have some attributes that need to be
archived and some attributes that should not be archived, how does
POC's automatic archiving or Stepstone's AsciiFiler work?

Right now I'm handling this by writing very brief methods that encode
the attributes that need serializing, in the way prescribed by the
class library I'm using. You seem to be claiming that this is both a
flaw in the class library *and* an instance of poor object
decomposition; because of this, given that you've built object
libraries and applications, I'm interested in knowing how you'd solve
the problem -- particularly the constraint that all objects have some
data that *should not* be serialized.

Based on your indirect answer, I interpret your stance as one of these:

* Objects should serialize all data, whether it is meaningful or not.
If objects have attributes that are only relevant when instantiated,
or that depend on run-time information or user input, they should be
serialized all the same, and restored but ignored when the object is
re-created.

In the case of the specific problem I described, this is an
unacceptable solution because the data are redundant and dependent
on run-time behavior. So 1/3 to 1/2 of the space taken by the
serialized object would be useless. Keeping this cache in memory
when the object is active is a worthwhile tradeoff for speed.
Keeping this cache on disk when the object is serialized is
wasteful.

* Objects should not contain any data which should not be serialized.
If objects need to maintain temporary data, they should be paired
with a separate object that is not serialized. (Exactly how it is
indicated that this temporary object should not be serialized is
unclear.)

In the case of the specific problem I described, this is an
unacceptable solution. Eliminating any cache altogether results in
a combinatorial explosion of method calls each time an object is
queried for its published variables. And having a cache either
requires that it be an attribute of *something* or that it be some
sort of global cache; in the former case, the question of how you
determine what needs serializing is still present, and in the latter
case, the design gets ugly because a single caching object needs to
be visible process-wide (if you make it an attribute of something,
limiting its scope, it gets serialized).

Now, I doubt that either of these is what you mean to answer, because
neither one proves your underlying claim, which is that it is
automatically superior for the class library to serialize everything
by introspection. (If you recall, this thread was spawned when a
prior poster asked why one might not want to just serialize
everything, and you claimed that having an object design in which not
all attributes of an object should be serialized was a sign of poor
design. And yet, you haven't explained how you would improve the
design, just that you'd use an object library that serializes
everything.)

Charlton

--
cwilbur at chromatico dot net
cwilbur at mac dot com

From:	Michael Ash
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 05:36:23 -0600

David Stes wrote:
> Charlton Wilbur wrote:
>>
>> In part, because some attributes need to be serialized and some do
>> not, and only the programmer can say with any reliability what these are.
>
> If that is the case, then you can model these needs in term of classes.
>
> If you have a class with attributes that need not be serialized, write a class
> with the attributes that you do want to be archived.
>
> In other words, you model the output of the archive in an object-oriented
> way (classes describe the contents of the archive)

I'm not sure I quite understand your suggestion. You seem to be saying
that I should take this:

int dontSerialize1;
int dontSerialize2;
...

And transform it into this:

id dontSerializeVariables;

Where this ivar points to an instance of a class that contains
dontSerialize1, dontSerialize2, etc. Is that correct? How does this
actually help? Won't the automatic serializer just follow the id reference
and serialize everything anyway?

From:	David Stes
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 11:43:06 GMT

Michael Ash wrote:
>
> Won't the automatic serializer just follow the id reference
> and serialize everything anyway?

Suppose you want to archive publickeys and privatekeys for public key
cryptography.

You write a class to represent a public key and one private key and what you
actually want to be archived.

Now, it is of course possible that you need other objects, runtime structures,
additional attributes for public keys and private keys, while you manipulate
those objects in memory. But these need not be the classes that you use for
archiving ...

From:	Michael Ash
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 06:27:24 -0600

David Stes wrote:
> Michael Ash wrote:
>>
>> Won't the automatic serializer just follow the id reference
>> and serialize everything anyway?
>
> Suppose you want to archive publickeys and privatekeys for public key
> cryptography.
>
> You write a class to represent a public key and one private key and what you
> actually want to be archived.
>
> Now, it is of course possible that you need other objects, runtime structures,
> additional attributes for public keys and private keys, while you manipulate
> those objects in memory. But these need not be the classes that you use for
> archiving ...

Yes, yes, I understand all of that. Please read the question. I'm not
asking why you'd do that, or what it would be good for, I'm asking you
*how it works*. How does separating these things into separate classes
prevent them from getting archived? Won't 'id dontArchive' get serialized
just like 'int dontArchive'?

From:	Pierre Chatel
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 21:46:04 GMT

On 2004-12-18 07:27:24 -0500, Michael Ash said:

> David Stes wrote:
>> Michael Ash wrote:
>>>
>>> Won't the automatic serializer just follow the id reference and
>>> serialize everything anyway?
>>
>> Suppose you want to archive publickeys and privatekeys for public key
>> cryptography.
>>
>> You write a class to represent a public key and one private key and what you
>> actually want to be archived.
>>
>> Now, it is of course possible that you need other objects, runtime structures,
>> additional attributes for public keys and private keys, while you manipulate
>> those objects in memory. But these need not be the classes that you use for
>> archiving ...
>
> Yes, yes, I understand all of that. Please read the question. I'm not
> asking why you'd do that, or what it would be good for, I'm asking you
> *how it works*. How does separating these things into separate classes
> prevent them from getting archived? Won't 'id dontArchive' get
> serialized just like 'int dontArchive'?

maybe i'm getting a little to simple here, but if the class of "id
dontArchive" (wich can be found because serialization is a runtime
process) is flaged (inherits from some archiving flagging protocol)
then it will be serialized. It'll not be archived in the other case.
I do understand your concerns about the fact that manual archiving add
more power to the whole process (i'm not even sure of that, because
there *must* be a way to implement conditionnal archiving using pure
object-oriented paradigms, if that exists) but i think automatic filing
*should* be the *default* behavior. You could always redefine some
methods later...

Sorry for my bad english....
Pierre

From:	Michael Ash
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 18:10:52 -0600

Pierre Chatel wrote:
> On 2004-12-18 07:27:24 -0500, Michael Ash said:
>
>> David Stes wrote:
>>> Michael Ash wrote:
>>>>
>>>> Won't the automatic serializer just follow the id reference and
>>>> serialize everything anyway?
>>>
>>> Suppose you want to archive publickeys and privatekeys for public key
>>> cryptography.
>>>
>>> You write a class to represent a public key and one private key and what you
>>> actually want to be archived.
>>>
>>> Now, it is of course possible that you need other objects, runtime structures,
>>> additional attributes for public keys and private keys, while you manipulate
>>> those objects in memory. But these need not be the classes that you use for
>>> archiving ...
>>
>> Yes, yes, I understand all of that. Please read the question. I'm not
>> asking why you'd do that, or what it would be good for, I'm asking you
>> *how it works*. How does separating these things into separate classes
>> prevent them from getting archived? Won't 'id dontArchive' get
>> serialized just like 'int dontArchive'?
>
> maybe i'm getting a little to simple here, but if the class of "id
> dontArchive" (wich can be found because serialization is a runtime
> process) is flaged (inherits from some archiving flagging protocol)
> then it will be serialized. It'll not be archived in the other case.

The way I understand it, POC's automatic archiver is handled in a separate
class and doesn't rely on any support from the classes being archived. If
that's true, then I don't see how Stes's proposal could work. It may not
be true. Since Stes is apparently incapable of giving a straight answer to
anything, we may never know.

> I do understand your concerns about the fact that manual archiving add
> more power to the whole process (i'm not even sure of that, because
> there *must* be a way to implement conditionnal archiving using pure
> object-oriented paradigms, if that exists) but i think automatic filing
> *should* be the *default* behavior. You could always redefine some
> methods later...

I actually agree completely. I don't see any reason *not* to include a
default automatic implementation that blindly archives everything, and
allow you to specialize that behavior as desired. It would be convenient.
However, I don't think it would be a huge time-saver, so IMO it's not a
big deal.

From:	Pierre Chatel
Subject:	Re: introspection and archiving
Date:	Sun, 19 Dec 2004 00:58:22 GMT

>
> The way I understand it, POC's automatic archiver is handled in a
> separate class and doesn't rely on any support from the classes being
> archived. If that's true, then I don't see how Stes's proposal could
> work. It may not be true. Since Stes is apparently incapable of giving
> a straight answer to anything, we may never know.

In fact he actually pointed u to some online/offline ressouces
(AsciiFiler and POC are related, so documention on the first one should
help us): But i don't know if they give any answer for this specific
concern :
"There is a discussion on AsciiFiler or filing in the Cox & Novobilski book
and certainly one in the Stepstone manuals on the Objective-C compiler."

>
> I actually agree completely. I don't see any reason *not* to include a
> default automatic implementation that blindly archives everything, and
> allow you to specialize that behavior as desired. It would be
> convenient. However, I don't think it would be a huge time-saver, so
> IMO it's not a big deal.

I'm pretty new to Objective-C programming, but as an experienced
(kinda) Java user it seems to me that the Java way is pretty much
smarter and time-saving than the Obj-C way. But it's highly probable
that it can't be implemented du to the dynamic (typing, binding,
loading) and weak typing aspects of obj-c.
IMHO, even if it's not time saving, it will be a lot more cleaner than
the actual state. Here, we are not talking about some last minute code
tweaking by the compiler (i mean parsing of the classes, then dumping
some batch serializing method), rather a rewrite of the archiving
system wich could be more object-programming friendly (extensive use of
introspection and everything). This approach of adding an other layer
of processing between the code and the final product remains me too
much of C++ :-)
Maybe we can deal with this using categories...

and no, this post IS NOT a flame :-)

My 2 cents...

Pierre

From:	Marcel Weiher
Subject:	Re: introspection and archiving
Date:	Tue, 28 Dec 2004 12:49:02 +0100

On Sun, 19 Dec 2004, Pierre Chatel wrote:

> > I actually agree completely. I don't see any reason *not* to include a
> > default automatic implementation that blindly archives everything, and
> > allow you to specialize that behavior as desired. It would be
> > convenient. However, I don't think it would be a huge time-saver, so
> > IMO it's not a big deal.
>
> I'm pretty new to Objective-C programming, but as an experienced
> (kinda) Java user it seems to me that the Java way is pretty much
> smarter and time-saving than the Obj-C way. But it's highly probable
> that it can't be implemented du to the dynamic (typing, binding,
> loading) and weak typing aspects of obj-c.

It is actually quite simple, and it is the dynamic aspects of Objective-C
that make it simple (just as it is the dynamic aspects that make it
possbile in Java).

I don't have the implementation with me, but a rough sketch is as follows:

- encode-/decodeWithCoder:
ask myself for a list of instance variable names to (de-)serialize
loop over list and use KVC to get/set the attributes

- list of attributes to serialize
default implementation gets the list of all attributes
and subtracts an "exception list"
(subclass can easily compute a list in a different way)

- list of all attributes
default implementation munges Objective-C runtime structures

- exception list
default implementation returns 'isa'

Marcel

From:	Michael Ash
Subject:	Re: introspection and archiving
Date:	Sun, 19 Dec 2004 17:10:48 -0600

Pierre Chatel wrote:
>>
>> The way I understand it, POC's automatic archiver is handled in a
>> separate class and doesn't rely on any support from the classes being
>> archived. If that's true, then I don't see how Stes's proposal could
>> work. It may not be true. Since Stes is apparently incapable of giving
>> a straight answer to anything, we may never know.
>
> In fact he actually pointed u to some online/offline ressouces
> (AsciiFiler and POC are related, so documention on the first one should
> help us): But i don't know if they give any answer for this specific
> concern :
> "There is a discussion on AsciiFiler or filing in the Cox & Novobilski book
> and certainly one in the Stepstone manuals on the Objective-C compiler."

It seems to me that my question could be answered by a few sentences.
However, instead of actually giving me an answer, or at least having the
courtesy of saying, "this is too complicated for a short answer", he
treats me like a child. I don't care enough about POC to go looking for
the answer.

>> I actually agree completely. I don't see any reason *not* to include a
>> default automatic implementation that blindly archives everything, and
>> allow you to specialize that behavior as desired. It would be
>> convenient. However, I don't think it would be a huge time-saver, so
>> IMO it's not a big deal.
>
> I'm pretty new to Objective-C programming, but as an experienced
> (kinda) Java user it seems to me that the Java way is pretty much
> smarter and time-saving than the Obj-C way. But it's highly probable
> that it can't be implemented du to the dynamic (typing, binding,
> loading) and weak typing aspects of obj-c.
> IMHO, even if it's not time saving, it will be a lot more cleaner than
> the actual state. Here, we are not talking about some last minute code
> tweaking by the compiler (i mean parsing of the classes, then dumping
> some batch serializing method), rather a rewrite of the archiving
> system wich could be more object-programming friendly (extensive use of
> introspection and everything). This approach of adding an other layer
> of processing between the code and the final product remains me too
> much of C++ :-)
> Maybe we can deal with this using categories...

You could always write an implementation of -encodeWithCoder: and
-initWithCoder: as a category on NSObject. Make them introspect into the
object's class to grab all of the instance variables, and you have the
default implementation you're looking for. It won't be trivial, but it
won't be terribly hard either. You wouldn't have to change the archiving
system at all, just provide a default implementation of the methods that
it looks for.

From:	David Stes
Subject:	Re: introspection and archiving
Date:	Mon, 20 Dec 2004 18:18:56 GMT

Michael Ash wrote:
>
> Make them introspect into the
> object's class to grab all of the instance variables, and you have the
> default implementation you're looking for. It won't be trivial, but it
> won't be terribly hard either.

Object-oriented programming is supposed to help reusability, so it is
weird if you have to do your own implementation of something that is a service
to all classes.

Designing a decent memory management isn't terrible hard either.
It isn't trivial, either.

I detect a pattern here ...

From:	David Stes
Subject:	Re: introspection and archiving
Date:	Sun, 19 Dec 2004 08:29:37 GMT

Pierre Chatel wrote:
>
> but i think automatic filing
> *should* be the *default* behavior. You could always redefine some
> methods later...

Yes, and this is how it is in Objective-C.

From:	David Stes
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 14:07:18 GMT

Michael Ash wrote:
>
> Yes, yes, I understand all of that. Please read the question. I'm not
> asking why you'd do that, or what it would be good for, I'm asking you
> *how it works*.

There is a discussion on AsciiFiler or filing in the Cox & Novobilski book,
and certainly one in the Stepstone manuals on the Objective-C compiler.

I'd suggest you'd read up some on Objective-C.

Filing is a hyper-classical feature of Objective-C (removed by Apple of course
in their implementation back in 1987 or 1988). Probably they did not have the
necessary intellectual capital at the time (and well, never since) to get
around implementing automatic filing. POC's automatic filing isn't complete
either, but there is the most essential stuff.

Objective-C took the idea from Smalltalk; it's not that critical, but it is
handy at times. As I said, you can always implement manual archiving if
you want or like, but it is certainly useful in some circumstances to have
automatic filing.

From:	Michael Ash
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 12:13:30 -0600

David Stes wrote:
> Michael Ash wrote:
>>
>> Yes, yes, I understand all of that. Please read the question. I'm not
>> asking why you'd do that, or what it would be good for, I'm asking you
>> *how it works*.
>
> There is a discussion on AsciiFiler or filing in the Cox & Novobilski book,
> and certainly one in the Stepstone manuals on the Objective-C compiler.
>
> I'd suggest you'd read up some on Objective-C.
>
> Filing is a hyper-classical feature of Objective-C (removed by Apple of course
> in their implementation back in 1987 or 1988). Probably they did not have the
> necessary intellectual capital at the time (and well, never since) to get
> around implementing automatic filing. POC's automatic filing isn't complete
> either, but there is the most essential stuff.
>
> Objective-C took the idea from Smalltalk; it's not that critical, but it is
> handy at times. As I said, you can always implement manual archiving if
> you want or like, but it is certainly useful in some circumstances to have
> automatic filing.

David, I make a living coding Objective-C, you don't need to lecture me on
the basics. I asked you a single, very simple question. I'm not attacking
you or trying to maneuver you into a corner. I simply want to know why
your suggestion would work. Why can't you answer one simple question?

From:	David Stes
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 19:10:27 GMT

Michael Ash wrote:
>>
>> I'd suggest you'd read up some on Objective-C.
>
> I simply want to know why your suggestion would work.

I do wonder, Michael, whether reading some books would work, in your case.

From:	Michael Ash
Subject:	Re: introspection and archiving
Date:	Sat, 18 Dec 2004 13:27:54 -0600

David Stes wrote:
> Michael Ash wrote:
>>>
>>> I'd suggest you'd read up some on Objective-C.
>>
>> I simply want to know why your suggestion would work.
>
> I do wonder, Michael, whether reading some books would work, in your case.

Time for the killfile for you. Post under a different name whenever you
decide not to be an asshole.