Cocoa mail archive
Re: Dynamic message typing problem
FROM : Julius Guzy
DATE : Sat May 17 13:55:32 2008
On 17 May 2008, at 0:58, Bill Bumgarner wrote:
> BTW: Nice paintings.
Thanks
>
>> I post the complete solution as an example and to check that I'm
>> not running close to the wind by using a dummy class definition.
>> The code gets no compiler warnings.
>
> You don't need the dummy class.
>
> I'd do it something like this (Mail Code -- this probably won't
> compile).
>
> Only I'd also pull out all of the #imports and move to using a
> shared precomp for the project...
I'm not sure I fully understand the ideas in the example code but
have started looking up the documentation re precompiled headers so
hopefully I'll get a handle on it by end of day.
My problem is that I am desperate to get up and running a number of
prototype examples of what my program is intended to do (e.g. see
http://animatedpaint.co.uk/nesta) as quickly as i possibly can and
the world is conspiring against me: in a weeks time i'll have to be
away from the computer for a month or so. I have a couple of key bits
of logic to implement after which I can better decide the
developmental path to take. So I'm trying to keep the system side as
simple as I can conceivably make it whilst always keeping an eye to
the future. I really like the idea of nibs and keeping things
independent from each other because i hate complexity and will go to
ends of the earth to avoid it. So i love messaging and the idea of
dynamic typing as a means of communicating between independent
subsystems. Why am I saying all of this... months of struggle and
then after making a major investment in a mac pro with 4 x 500GB
raid etc etc (and that not working properly either) and having some
key communications code fail on me... aaaarrrrgggghhhh. I'll get it
all sorted when i get back.
By the way, thanks to you all who have been emphasising the need to
really take notice of the compiler warnings. I do do this normally -
really I do. I hate having warnings anywhere near me!!!. In the case
of Dynamic Typing I just thought this happened to be one of those
hits to cleanliness one had to take. So very happilly I stand corrected.
And Jens yes, I will switch on the extra warnings flags, thanks.
I would like to ask you all this one extra question to further my
understanding.
According to the Defining a Class section of the The Objective-C 2.0
Programming Language documentation, the ability to identify the
identity of an object at runtime is given by the sequence: id -> isa -
> class description
vis:
< quote>
The id type is completely nonrestrictive. By itself, it yields no
information about an object, except that it is an object.
Since the id type designator can’t supply [the object's methods,
variables] to the compiler, each object has to be able to supply it
at runtime.
every object carries with it an isa instance variable that identifies
the object’s class—what kind of object it is.
Objects are thus dynamically typed at runtime. Whenever it needs to,
the runtime system can find the exact class that an object belongs
to, just by asking the object. Dynamic typing in Objective-C serves
as the foundation for dynamic binding, discussed later.
<end quote>
Assume a file which contains a call of the form
int tempVar = [idValue methodIdentifier:param];
Assume there is no header file to give information about
methodIdentifier and its parameters.
The problem for the compiler is to determine the return type and the
type of the parameter "param".
We have already established that (one way) this problem can be
resolved is if the calling file includes the header of a dummy class
which includes a method called "methodIdentifier:" of type say float
and that returns an integer say.
Could not the compiler have been given the exact same information
through coercion viz:
int tempVar = (int)[idValue methodIdentifier:(float)param];
This does not work but what is wrong with this line of reasoning and/
or why could the system not make use of coercion as part of a dynamic
typing mechanism?
Thanks again
Julius
http://juliuspaintings.co.uk
DATE : Sat May 17 13:55:32 2008
On 17 May 2008, at 0:58, Bill Bumgarner wrote:
> BTW: Nice paintings.
Thanks
>
>> I post the complete solution as an example and to check that I'm
>> not running close to the wind by using a dummy class definition.
>> The code gets no compiler warnings.
>
> You don't need the dummy class.
>
> I'd do it something like this (Mail Code -- this probably won't
> compile).
>
> Only I'd also pull out all of the #imports and move to using a
> shared precomp for the project...
I'm not sure I fully understand the ideas in the example code but
have started looking up the documentation re precompiled headers so
hopefully I'll get a handle on it by end of day.
My problem is that I am desperate to get up and running a number of
prototype examples of what my program is intended to do (e.g. see
http://animatedpaint.co.uk/nesta) as quickly as i possibly can and
the world is conspiring against me: in a weeks time i'll have to be
away from the computer for a month or so. I have a couple of key bits
of logic to implement after which I can better decide the
developmental path to take. So I'm trying to keep the system side as
simple as I can conceivably make it whilst always keeping an eye to
the future. I really like the idea of nibs and keeping things
independent from each other because i hate complexity and will go to
ends of the earth to avoid it. So i love messaging and the idea of
dynamic typing as a means of communicating between independent
subsystems. Why am I saying all of this... months of struggle and
then after making a major investment in a mac pro with 4 x 500GB
raid etc etc (and that not working properly either) and having some
key communications code fail on me... aaaarrrrgggghhhh. I'll get it
all sorted when i get back.
By the way, thanks to you all who have been emphasising the need to
really take notice of the compiler warnings. I do do this normally -
really I do. I hate having warnings anywhere near me!!!. In the case
of Dynamic Typing I just thought this happened to be one of those
hits to cleanliness one had to take. So very happilly I stand corrected.
And Jens yes, I will switch on the extra warnings flags, thanks.
I would like to ask you all this one extra question to further my
understanding.
According to the Defining a Class section of the The Objective-C 2.0
Programming Language documentation, the ability to identify the
identity of an object at runtime is given by the sequence: id -> isa -
> class description
vis:
< quote>
The id type is completely nonrestrictive. By itself, it yields no
information about an object, except that it is an object.
Since the id type designator can’t supply [the object's methods,
variables] to the compiler, each object has to be able to supply it
at runtime.
every object carries with it an isa instance variable that identifies
the object’s class—what kind of object it is.
Objects are thus dynamically typed at runtime. Whenever it needs to,
the runtime system can find the exact class that an object belongs
to, just by asking the object. Dynamic typing in Objective-C serves
as the foundation for dynamic binding, discussed later.
<end quote>
Assume a file which contains a call of the form
int tempVar = [idValue methodIdentifier:param];
Assume there is no header file to give information about
methodIdentifier and its parameters.
The problem for the compiler is to determine the return type and the
type of the parameter "param".
We have already established that (one way) this problem can be
resolved is if the calling file includes the header of a dummy class
which includes a method called "methodIdentifier:" of type say float
and that returns an integer say.
Could not the compiler have been given the exact same information
through coercion viz:
int tempVar = (int)[idValue methodIdentifier:(float)param];
This does not work but what is wrong with this line of reasoning and/
or why could the system not make use of coercion as part of a dynamic
typing mechanism?
Thanks again
Julius
http://juliuspaintings.co.uk
