Re: Function calling
Re: Function calling
- Subject: Re: Function calling
- From: Erik Buck <email@hidden>
- Date: Wed, 25 May 2005 21:57:34 -0400
It is starting to get off topic, but interestingly, if either MyFunc
() or Increment() are virtual in order to be polymorphic, the "good C+
+" can not "compile this with no functions called!" IMHO, without
the polymorphism, you might as well code this in C instead of C++.
MyClass* OtherClass::MyFunc() {
return &this->MyClassField;
}
void MyClass::Increment() {
this->Value++;
}
OtherClass Fred;
for (long i = 0; i < 10000000; i++) {
Fred.MyFunc->Increment();
}
Furthermore, it is impossible to tell what this code actually does
because any or all of the operators except '.' may have been
overloaded. :(
Following another thread, I have never tried Haskell, but I have used
Eiffel quite a bit. I think we are starting to obscure the
conversation about Objective-C because are not recognizing the
differences between open world vs. closed world problems.
From "Cocoa Programming"
There are two general types of applications: closed world and open
world.
Objective-C’s flexibility and power are generally inappropriate for
closed-world
applications, but much more suited for open-world applications, as
described in the
following sections.
Closed-World Applications
The engine compartment of an automobile is analogous to closed-world
applica-
tions. It is desirable to know in advance every component that will
be inside the
engine compartment and how they will fit together. Engines are
carefully designed
and their design is seldom modified after they leave the factory. Any
variation in the
connections between engine components is probably a manufacturing error.
Languages such as C++ and to a lesser extent Java provide language-
level features
that are well-suited to solving closed-world problems. The static
strong typing used
by C++ and Java enables the compiler to verify that all components
fit together as
planned at the cost of making variation, redesign, and modification
of existing appli-
cations more difficult. Some applications require the verifiability
of static strong
typing and can overcome the reduction in flexibility. Some
programmers are just
more comfortable solving closed-world style problems and might never
be satisfied
with Cocoa because it is designed to solve open-world problems.
Open-World Applications
The passenger compartment of an automobile is analogous to open-world
applica-
tions. Any constraints on the type or number of people and things
that can be
placed in the passenger compartment detract from the utility of the
automobile.
Some constraints are inevitable, but the designer of a passenger
compartment must
strive for maximum flexibility. The price of that flexibility is that
the designer
cannot anticipate everything that might be put in the passenger
compartment. The
designer must work with incomplete information. Objective-C provides
language-
level support for solving open-world problems. Objective-C objects
can operate with
anonymous objects in different applications. It is possible to send
messages to
objects even though the receiver might not understand the message. It
is possible to
add behaviors to existing compiled objects without recompiling them.
The flexibility
provided by Objective-C aids the development and life-cycle
modification of most
desktop applications, but the cost is that the compiler cannot always
verify that the
components fit together. In some cases, errors that might have been
caught by a
compiler with a different language cannot be caught until an
Objective-C applica-
tion is running.
Most graphical user interfaces are examples of open-world
applications. Restrictions
on the type and number of graphical components available reduce the
utility of user
interfaces. Sometimes it is necessary to create new user interface
components that
were not anticipated by the original designers and still be able to
integrate the new
components with the old components. Plug-ins and context menus are
other exam-
ples of open-world applications.
It is certainly possible to create open-world applications with
static strongly typed
languages, but it is more difficult. It is also possible to use
strong static typing with
Objective-C and gain many of the benefits at the cost of flexibility.
Cocoa and
Objective-C emphasize flexibility at the expense of compile time
verifiability. Much
of the increased programmer productivity attributed to using Cocoa
results from
Objective-C’s flexibility.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden