Re: Just starting off in obj C
Re: Just starting off in obj C
- Subject: Re: Just starting off in obj C
- From: Ian Joyner <email@hidden>
- Date: Sun, 26 Oct 2008 14:16:37 +1100
On 25/10/2008, at 5:48 PM, Bill Bumgarner wrote:
On Oct 24, 2008, at 10:57 PM, Ian Joyner wrote:
I didn't really mean lazy in that sense. Dynamic binding is
desirable and by design. Rather that C compilers require a call
operator '()' to tell them what to do, whereas other languages work
that out (except COBOL and FORTRAN which need CALL). And things
like dereferencing either by '.' or '->' because C compilers can't
be bothered seeing if the variable is simple or pointer. Call is
the common case, generating a function reference is the rare case
(especially in OO languages, which at least hides this
implementation in dispatch tables). Loads of other junk in there
that makes C a verbose language that exposes implementation and
increases software brittleness.
Nothing about the original poster's question had to do with dynamic
binding; it was entirely focused on C's rather anal type
requirements and the lack of type checking in one particular case.
So anal, in fact, that dereferencing via "." vs. "->" mean entirely
different things;
I think the problem is we're talking at two different levels. I agree
they mean two different things at the implementation level, but at the
more abstract level, they mean "access this feature (value, function,
etc) of this object (structure)".
the difference between the two is rather quite extremely critical
to understanding what a piece of C code is doing.
Only if you are thinking of whether you are accessing a feature
directly or indirectly by dereferencing a pointer, thus thinking about
what is going on under the hood. This is not needed in an HLL and
should be done by the compiler – that's what I mean by C compilers
being 'lazy', not taking care of things and making the programmer do it.
As for brittleness, yup -- C *can* be brittle if you abuse
typecasting and ignore compiler warnings. But, from a compilation
standpoint, it is actually not brittle at all. Where C -- and
legacy Objective-C -- becomes brittle is in changes over time; a
seemingly innocuous change may require extensive recompilation to
work.
That's close to what what I mean, but worse is that changes not only
require recompilation, but require rework by a programmer (OK,
refactoring tools can help, but are they really needed?). The '.' - '-
>' distinction is a case in point. If you change a structure from
direct access to access through a pointer (for maybe efficiency or
sharing reasons), your code must be refactored. The refactoring tool
(or programmer work in other cases) is making up for the C compiler
being lazy!
I hope I have explained things a bit better.
Ian _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden