WWDC2004 Session 302

Transcript

Kind: captions
Language: en
pair of tools this is what we're gonna
explore today I'd like to give you some
context for this language because I feel
it's important for understanding the
trick the design decisions the
trade-offs we made and in fact the roots
of both of these language languages if
you look at when C++ and Objective C
were born they were both born in the mid
80s roughly speaking and C++ drew
inspiration from Simula and objective-c
drew inspiration from small talk and
some of the terminology features and
mindsets and in fact culture that
surround these languages I hope to
expose to give you some sense for why
one language works one way another
language solves a different set of
problems and why the combination of them
is actually pretty exciting I I also
want to give you many examples because
if we just talk in the abstract you're
not going to get a good feel for the
language the best way to learn the
language is through example so the
examples I'm going to be giving are from
WebKit Safari there are some examples
from the Celestra application that
you've seen there are some examples from
our developer examples so if you want to
try some of these when you get home you
can go and look at the code that in fact
we'll be presenting here and and lastly
I want to talk about some gotchas it's a
very complex language and there are a
few gotchas I don't think they affect
too many people but it's still relevant
in the context of this talk and lastly I
don't have this on the slide but I'd
love to interact with you folks for
about 15 20 minutes so I'm hoping I
could zoom through the presentation and
customize it to what you guys want to
know afterwards so to cut to the chase
why why isn't cocoa written in C++ we
wouldn't be here talking about the
combined languages if in fact cocoa was
written in C++ and the simple answer is
it doesn't meet Coco's needs so before I
explain why it doesn't meet Coco's needs
I'm going to try and go through what are
Coco's needs what are the language
requirements want are the runtime
requirements that we have for
go to set the stage for understanding
the language number one easy to learn
less is more we want to be able to teach
someone the language the Cocos written
in in a week max I think we're gonna
cover most of the language here fairly
well and I think it'll get a feel for a
good feel for objective-c
in a couple of hours roughly but we want
people to focus on the API so we want to
take the spotlight from the language and
move it to the frameworks that's one of
the bigger reasons we wanted it to be
easy to learn we don't want you to focus
or struggle with the language we want to
embrace existing code this has been part
of the mindset for many years that is
this isn't Java where we're trying to
basically give you a clean new world
that you have to conform to in in a
homogeneous way we want you to be able
to bring over your C code your C++ code
and leverage it in the context of this
very dynamic environment and lastly and
most importantly we want a dynamic
object model the dynamic object model is
what enables many of the cool features
that you see in these presentations
whether it be cocoa bindings or
Automator many of these very cool
features are because we have dynamic
plumbing underneath the covers that
actually allows us to do some very very
interesting things and if you don't
write frameworks for a living you don't
sometimes think about it so if you're an
application programmer I'm hoping that
if you haven't thought about some of
these features we're going to put them
in a context that's going to make them
much more interesting to you so it's
very it's very important that we serve
the frameworks and the interactive tools
one of the runtime requirements as most
of you know in the mid-80s we weren't
dealing with machines and memory models
that were that were vast as vast as
today for instance objective-c ran
fairly well in two megabyte on two
megabyte workstations and today as you
know most workstation chip with 256
megabytes 512 whatever quite a bit more
than it was designed for so it's very
clear that objective-c having
born in that age scales nicely to
today's machines it's very critical that
when we ship new features that we don't
break your code okay now if you look at
how many releases of cocoa we've made
and lots of frameworks we've been very
successful in fact I think we were the
only operating system that I know of
that is fairly object-oriented and
hasn't in fact broken people with some
regularity so everything's shared and we
try not to break people we have a
sea-based API and this again doesn't
really affect you directly but
indirectly that is we feel strongly that
objective-c has to interact with other
languages so for instance the first two
up there cocoa Java is a bridge that
Apple supports Apple script studio is
another product that allows you from
Apple script to do cocoa programming and
then there's a whole bunch of
third-party scripting languages Python
for objective-c Ruby cocoa Perl and in
fact c-sharp is is being added to the
list of languages that are going to be
available to interact with cocoa and
bind with Objective C so we're really
excited to see third parties in fact
integrate with this runtime which we
consider fairly flexible so to wrap it
up it's designed to serve the dynamic
frameworks and tools and it enables you
to integrate your C code with cocoa but
what this talk is about is Objective C
plus plus which is the same exact design
point okay it just enables you to
integrate C++ code so it's it's it's not
as if the object modules are there to
compete they're there to work together
so now let's get back to why C++ doesn't
meet Coco's needs
it's a strongly type static object model
this is what one of the properties that
makes it hard to evolve systems over
time there's no runtime support for
dynamic loading a reflection again many
features that we provide in our tools
would not be possible with the standard
C++ definition as many of you use it
today it is possible to expand the
definition but we've used C++
as a standard language which we try not
to extend and run time model is fragile
and compiler dependent this is a feature
which is hurt C++ significantly one of
the reasons Java is is so popular today
is because it doesn't suffer from this
ok shared libraries are critical for
deploying code and it contributes to
this culture of code copying right where
if you can't share something and not
break it you want to own it you want to
copy it in yourself so in fact you won't
break and in fact if you have many
applications using many large frameworks
and they're all copied you can imagine
what the memory footprint of your system
would be like so objective C++ design
points peaceful coexistence right we
want to use C++ as the base and the
parser has been modified to layer
Objective C atop C++ one of the smartest
things I think we did was many years ago
was we implemented Objective C in the
canoe compiler and that that work
happened in 88 roughly and that work
along with the C++ work that was going
on enabled us to marry them with fairly
low effort both runtime systems are
unchanged
ok the native ABI the semantics and the
performance that you expect from C++ is
what you get it's not like we're
changing the way you do virtual function
dispatch or any other things in C++ we
are letting C++ have its own turf and
Objective C have its own turf and we
think that works very nicely now
subclassing across object models is not
supported aggregation we think works
great for this now in the early days
when we used to present this language
people got really freaked out by that
they said God you can't subclass is it
really useful if you can't subclass well
I think what's happened over time is
people actually have learned through
many iterations of designing object
systems that inheritance is is often not
the best tool for performing something
so one things I'm going to talk about is
how in
Cocco uses delegation composition and
aggregation as programming idioms and
tools which in fact again make it a
natural marriage because we don't
require sub classing just by virtue of
our dinette dynamism so sub classing
isn't supported so why don't we unify
the object models people sometimes ask
who haven't carefully considered some of
the implications why don't we just
change C++ to work like Objective C well
there are systems that have been tried
over time some is one of them the system
object model that Apple and IBM worked
on years ago and even come to some
extent by Microsoft that are actually
systems designed to try and fix some of
the problems with deploying C++ shared
shared objects and the static object
model it turns out that because they
were unsuccessful we chose not to to go
that path rather Mary Objective C and
C++ as we've done so let's go through
the benefits it's portable it's amazing
how even changing initialization order
of the order on which constructors are
run that that breaks some of you guys
out there we I work in the tools team
where we're constantly looking at easier
ways to port your apps and what
headbutts you bump into and
initialization order isn't something
that the standard dictates that is it
says each system can do it however it
wants well in fact by the letter of the
law
we we work just fine however we again
break some of your code because we don't
do it in a specific way that let's say
was born on Windows or Linux so again we
want to make things portable and if
initialization order is a problem if we
change the way dispatch work believe me
we break all of you so performance the
the performance of an application is
often dictated by the way it does
dispatch the fine-grained model
coarse-grained model of the object
orientation and objective-c is just
designed for more coarse-grained mid
grain dynamism and not the very
fine-grain stuff that people use C++
before so it would be naive to think
that the same performance considerations
that we apply to a dynamic more
coarse-grained object
apply to a fine grain once oh and and
thirdly we want to be pragmatic someone
said to me outside the other day how one
of the beauties of coming to this
conference and seeing what Apple does
and seeing Steve's Keena keynote is how
we we're very good at finding the sweet
spot right and that's why we're able to
make releases on a yearly basis and and
show you guys cool stuff is because we
find the sweet spot and I think
objective-c is a c++ is a good example
of that
it's pragmatic and it works so now let's
go into the code section of the talk
here is hello world in four dialects you
have the first header files stood I oh
you guys are all familiar with that
there's iostream
and then there's foundation so you can
see the standard printf hello world you
can see the C++ version it's in all the
C++ books then there's a couple a couple
more statements that give you the
objective-c version now that's string
constant for those of you who haven't
seen Objective C a string constant
preceded by an @ sign is a constant
string object the compiler is
responsible for creating it and you can
see it's initialized there and then
there's the combination of them which is
pretty seamless so you have standard out
taking as output the C string coming
from the ejecta C string object and then
outputting the plus plus for the last
version so you could see that that
that's fairly easy to program so here's
just how you compile it just to show you
that the file the suffix is dot mm we
don't have to get into the details of
why it's called mm but it contains the
mix languages and it's linking against
the standard C++ library which is a
static library not a shared library and
it's linking against the frameworks
other foundation framework so pretty
easy stuff now again one detail right
now we're shipping the standard C++
library as what we call an archive
library a non-shared library so if you
look at that executable it's actually
fairly big it contains the whole
standard C++ library contained within
the
the hello world in a future release
we're going to be releasing a shared
version of that now I want to go through
some some you know just syntactic idioms
and I also want to go through some
terminology here's what a class looks
like at interface so let's get the @
stuff out of the way why do we use that
the reason we prefix our keywords with
AD is we didn't want to break existing
code it's that simple you know some
people get freaked out by the @ sign but
that is the reason it's we don't want to
break code because code contains
interface code contains end and code
contains other keywords that we wanted
to publish so that's why we use at and
it's a single inheritance model so right
there the supercut the class is my class
the super class is nsobject okay for
purposes of this discussion objective-c
is single rooted it turns out that you
can provide your own root class but
that's something for an advanced session
that that is a topic for another day so
oh just just briefly instance variables
the term instance variable is a small
talk jargon or terminology in C++ if in
fact some of you have just programmed in
C++ you would know that as data members
right so members data members instance
variables map into the same concept so
here we have a c type and int named x we
have an NS view name Y and we have an io
stream named s so you can see we have 3
different declarations here that all
contain different types here are some
methods their instance methods and again
the term method comes from small talk
instance method class method in C++ this
would be member functions and well
non-static member functions and member
functions and here we have a set target
method and a set action method now
notice the colons the Collinswood
separate the key what's called the
keyword argument from the from the
actual type and the name of the argument
if you leave out the type and Objective
C it means it's an ID
we'll get into what I deem Eanes in a
little while
so here we have a set cell class that's
actually a class object we'll get into
that as well later and selectors
selectors are a unique name for a method
okay so they're like point they're like
pointers to functions except they
represent the name and they're unique
per process and we'll talk a little bit
later about that so so far we have a
class interface we have instance
variables we have methods here's an
abstract type declaration objective-c
decided to formalize the node in the
notion of abstract types years ago and
it's been something that's worked really
well for us so an abstract type is a
type where you don't specify the
instance variables you don't specify the
superclass you just specify what the
operations that are expected of the type
are so here's the NS dragging info
protocol this is a set of methods which
will all can will be given to the app
kit and they will delegate to your
object here's an abstract type
implementation so you could see NS
string it inherits from NS object and it
conforms to three protocols so here's an
example where objective-c has single
inheritance of implementation but
multiple inheritance of interface okay
which is a very common metaphor that we
use in cocoa and that works very well
for us so here again we have three
different interfaces or protocols and a
couple methods there so here is three
different object their declarations in
C++ you've probably never seen anything
like ID it's it's an object-oriented
void star pretty much and it says here
is any object now the difference is that
object has metadata associated with it
so in fact it's not as bad as a void
star and that a void star you know
nothing about it except by looking at
the source code at runtime you could
actually infer what the type of object
is now the second statement declaration
there is
in NS browser star in objective-c when
you type an object that's there just for
documentation okay it's it tells the
reader that that any browser is an NS
browser it doesn't affect how the
compiler will do binding so dynamic
dispatch all the dynamic properties
still apply even though it's been typed
and the third declaration there says I
have any object that conforms to the NS
dragging info protocol which is what I
just showed in the previous slide so
that means any class that can conform to
that protocol will be accepted by the
compiler what's really neat about this
again is you don't have to know what
type of object it is now you can even
provide a list there it's fairly
uncommon but just as you had a list
within the class declaration context you
could have a list here as well another
point as contrast to Java is Java
integrates the abstract type namespace
in with the class namespace in
objective-c they're separate so you
could have an NS object class and an NS
object protocol and so on and so forth
so they're in separate namespaces here
we're going to go through message
expressions this is what you see the
most of when you look at an objective-c
program here's the most simple one we
have my view which is an object and it's
sending the timer update message there's
no arguments there okay
the second its message expression there
well is is any browser sent the set
delegate object message that takes one
argument notice the colon separates the
name from the actual argument in this
case odd and the third one a common
idiom is where the receiver is derived
from a message here self is I think the
first time we've seen self self is
equivalent to this in C++ and it's
sending the flush window message so now
let's look at some hybrid message
expressions this first one is out of web
core it's sending the message keyboard
UI and you can see that it's accessing a
static member function bridge for widget
and in this case this is active so this
is just a message expression I pulled
out of web core to show you how easy it
is to mix the two two languages and
message expressions the second one is a
bit more complicated there we have the
adapter sending the set cookies for URL
policy base URL message and you can see
it's interspersed with arguments that
are in fact member function calls okay
so fairly easy stuff again a message
expression is an expression so just as
you call in a function and you could
provide expressions to each argument of
the function the same things true here
that's why the nesting works so nicely
there's nothing special about it okay
there we go so here are some more hybrid
message expressions front celestia here
we have we're sending the star message
to self we're then dereference saying it
calling the set luminosity member
function and we're passing it the float
value from an objective-c message
expression again you could see how
natural the given play is there's
nothing real really magic going on and
you could really see the two languages
collaborating and and working well
together here so the second one we have
NS number and you can see the self star
and it's sending the get temperature on
member function call and the third one
we have simply a namespace named Astro
and there's just a standard C++ function
that's embedded within the namespace a
stroke called light-years two parsecs
and it's being passed the float value
okay next thing I'd like to talk about
is some dynamic idioms okay method
categories are something we use pretty
extensively in the application kit it
allows us to augment existing classes
it's something you don't see very
commonly and other object-oriented
languages if you look at Common Lisp or
you look at some other more dynamic
languages they're not called categories
but they allow you to do the same thing
what they allow you to do is add
operations to an existing class so
here's an example
we're on the app kit is adding some
string drawing methods to the foundation
string object likewise
here's an objective C++ category that
Celestia adds to convert NS strings to
and from the standard strings so I want
to show you briefly how it works because
I think many people who are new to some
of the dynamic properties that
objective-c has they get confused so
here are three bodies of code we have
the foundation where NS string lives we
have a pit with a category that you just
saw we have Celestia with that on that
category with the two methods what
happens is at runtime the runtime links
things up and looks actually when it
loads the shared library it says Oh a
category who are you associated with and
then it goes and looks up the class
dynamically and it sets the method
tables accordingly so that you can
basically extend the class methods in a
fairly seamless way here you see the NS
string method table points to the string
drawing method table which points to so
anything in the app kit all your
applications get for free if you want to
have a private category as Celestia does
that's a category that would be embodied
with the actual executable for the
application that would obviously not be
shared with other executables and what
what this allows you to associate
methods with other objects that work on
their behalf so for instance these
method tables aren't a part of NS view
they're not a part of the Celestia
galaxy but there are methods
the galaxy and the view would like to
call on behalf of the string object so
so why is all this interesting it's
because you don't have control of who
instantiates objects all the time right
one of the things that frameworks are
really good at is doing work on your
behalf where you actually don't know
what class is going to be it is going to
be sent the message so we think this
works really well and in fact people
have used it in very interesting ways in
various applications so another dynamic
idiom we have the set cell class method
basically classes are first-class
objects in objective-c you can reason
about them if you dynamically load code
you can find out what classes are a part
of that code and and invoke methods on
them set cell class you could reason
about the superclass these are all small
talk idioms that we carried over into
objective-c and these kind of predicate
to basically ask is this class a kind of
another class now notice the function
there the function allows you to take a
string and convert it into an object
okay that's another metaphor we use
quite heavily because the compiler can't
always know or be told what class often
it's reading those things from external
files like your nib file so here our
methods are first-class objects as well
and here's a selector the unique code so
if you want to compare selectors you
need to convert them if you want to get
a method signature you need a selector
so in this case it's already been
converted we send that message
signatures contain the type so if you're
writing a tool you're writing a
framework and you want to know what
types the the method takes the signature
is really handy and here's a net
selector directive a selector is the
equivalent of the function in this slide
the only difference is you're telling
the compiler to do it so it's a little
more optimal because you know the name
in this case it's a lock so the compiler
will get the unique code for the a lock
method
delegation okay this is something that
we use in notifications we use it in the
target action paradigm and the
application kit we we do things like oh
if your object responds to this elector
wall
send the window didn't move message the
window didn't move message as part of a
protocol that we publish for tracking
window operations and this is this is a
perfect example of code that you don't
often write but is written all the time
in the framework to collaborate with
your objects so again it's it's an
interesting case where until you see
some of these idioms and metaphors and
patterns you don't appreciate them and
again this is this is one of the reasons
when you write cocoa programs you don't
find you're overwhelmed with
sub-classing writing lots of different
classes and in fact ending up with some
very highly structured or overly
structured class hierarchy it's fairly
freeform it's it's it's more
free-flowing so here set target set
action this is code from the interface
builder paradigm and this is you know
and all of our controls and then later
on once you have the target in the
action you can send the set action
method accordingly so this is this is
the dynamic code that we find all over
our frameworks that again simplifies
your life reflection this is this is on
the hooks that support outlets bindings
key value coding again cocoa bindings
which have been featured in many of the
presentations this is the low-level code
that in fact supports those those
metaphors so in this case we have
selector from string it gets gets the
selector and then it asks response to if
it does respond to it it performs a
selector if no setter method has been
found a lower-level hook is provided to
in fact lookup the instance variable and
set it directly in the object so the
simplification for the programmer is you
don't have to write setter methods the
introspection reflection that's provided
with the runtime and
Abel's the tools to basically poke at
your object and set up the connection
set up the binding without your
intervention it's nice to have the
opportunity to write the setter but
that's not required so let's see how are
we doing on time here so here are some
examples from OpenGL this is on the
developer disk here's an example of a
more complete set of code where we have
a value object that's a cue matrix there
that's highlighted and it's surrounded
by an outlet right there from interface
builder mode alpha again this is on your
disk now just because you're writing an
objective c++ don't assume that all the
classes have to be mixed right here's an
example where even though we saw some
hybrid code in the previous slide this
class is pure C++ there's not any
Objective C in it so a very very common
thing we see out there is people keeping
a lot of their C++ let's say portable
and standard and not mixing the models
everywhere but in fact just doing it in
very special control points right it's
very common to want to do a native
interface in cocoa and bring over your
your C++ engine so to speak and in fact
I chats a good example i chat is a
wonderful cocoa interface that the chat
engine is actually in C++ and they work
together via objective C++ so here is
just in the example rotating the cube
you can see the the one statement there
that does the multiplication and then
the extra Objective C statements there
to do the graphics and update the the
scene fairly straightforward stuff now
here's an interesting one there was a
class in in this example that was
largely C++ but there's a couple pure
member functions there that we're taking
objective-c objects selectors and in
fact events so I've highlighted them for
you and you could see that these these
arguments
are passed around as naturally as other
arguments would be and so here's the
handle event method so you can see that
it checks the event type checks if it's
a scroll wheel and does the appropriate
operations again very very
straightforward okay so let's go to the
next example which is Core Audio this is
a little bit more complicated this this
example what's in orange are the C++
objects and what's in blue are the
objective-c objects so here we have a
few vectors and a map that are C++
vectors and map from the standard C++
library that point off to Objective C
objects
so there's C++ containers that point off
to Objective C objects here's the
allocation method so you can see that
there's a couple objective-c objects
being allocated and initialized with the
application delegate and then there are
several news which are the vectors being
instantiated this is a good time to note
that in Objective C all objects are
dynamically allocated okay or by
reference the only special object is in
a string which the compiler knows about
so it knows how to create static string
constants but all other objective-c
objects that you create are dynamically
allocated in C++ it's very common to use
value objects and we're going to talk a
little bit more about that in a bit but
here it so happens that the new is being
used and their dynamic as well so all
the objects on this in this method are
dynamic so here's a simple little method
that basically sends the push back call
we're and gives it the window controller
so here's a very simple example the
obviously plus plus vector you're
pushing an objective-c object into the
vector now this method has something
tricky about it that we're going to talk
about later I don't want to get into it
now we'll get back to it here is the
destroy
method and there's an iterator so just
like we have vectors we have C++
iterators being used fairly naturally
it's iterating over the vector and it's
checking for the controller and when it
finds it it erases it from the vector
and then it sends the release message
okay and that sort of gives you a hint
on where the the trickiness is that
Objective C at least in the context of
of cocoa uses a retain release metaphor
currently so because all objects are
dynamically allocated cocoa gives you
some relief in trying to understand the
lifetime by providing a reference
counting metaphor that it it in fact
implements and encourages you to
implement and this is an example so
let's get into the gotchas now so we
just looked at c++ containers of cocoa
objects there i was alluding to the
Gotcha which is it's a little bit sticky
right now mixing the retain release
metaphor with with c++ when the vector
classes were developed they obviously
didn't know about objective-c right so
it's hard to expect them to know how to
do this and again I as I said before
both runtimes both libraries don't know
about each other
fortunately c++ provides some
interesting hooks to be able to solve
this problem I don't know if you're able
to read the comments but basically
what's happening here is it's considered
a no-no in cocoa to transfer ownership
across calls okay so what I expected to
when I was reading this this method I
was expecting to see a release at the
end okay but it doesn't do a release it
passes passes the object on and for
purposes of this talk if you're not
familiar with retain release this is
probably more than you need to know but
here there's a manual release so you saw
that
and and it's just confusing okay and and
I've talked to people who use the
language and they want to see this fixed
so one of the things that we're going to
be doing is adding a smart pointer class
to automate the retain release okay
so for any of you who've tried to do
this and have been confused by it
fortunately C++ provides templates which
allow you to customize the behavior of
the vector so for instance by providing
an ID pointer template it allows it
allows us to solve this problem and
write that code much more naturally and
in a much less error-prone fashion so
this is a feature that we expect to
provide for Tiger if not it's actually
fairly easy for you to implement this
yourself if you need to do so you know
in the short term as I say in the slide
boost shared pointer might even work for
you off the shelf if it doesn't then you
could adapt it to your needs and so on
so the next gotcha is exception handling
exception handling is supported in both
languages in in in C++ it's try catch
and objective-c it's a triac catch but
one of the confusing things here is if
you look at these two calls here one is
the sending the process message and the
other is timer update you don't know
whether these two calls are truly like
the first one you don't know if is it
C++ pure or is it hybrid right the
second one you don't know is this pure
objective-c message sent that is the
method on the other end is it pure
Objective C or not right if you know
that then life's a little bit simpler
you can just wrap your C++ call with the
try catch and wrap your objective-c
message then with that try out catch
unfortunately in this case they're
hybrid which is why I used it as an
example so to solve this problem it's
it's straightforward maybe initially non
obvious but you you basically wrap the
first
calls in try-catch and that's the C++
catch right there and then you would rap
without trial catch okay now fortunately
the way exceptions are used in Cocoa and
C++ they're really used for exceptional
conditions as errors right so you don't
find yourself having to write this type
of code very often usually in Cocoa in
particular you write a you inherit an
exception handler from menace
application and even if you decide to
implement your own exception handling
you usually do it a very high level of
the application again it's not it's not
handled for things like file not found
so that what I just talked about was
sort of education it wasn't it isn't
really a big gotcha it's just something
did you have to think about more of a
speed bump this is a gotcha
this-this-this init method does
something very bad basically it has
there's a value stack object that I've
declared here and as the comment says
the destructor for stack object will not
be called automatically when that add
throw happens okay the reason for this
unfortunately is related to the fact
that we're trying very hard to be binary
compatible so that when we added at try
at catch last year we actually use set
jump and long jump which is what we have
been using in cocoa and such up and long
jump do not know about the C++ runtime
okay so in fact this is this is a gotcha
by design unfortunately so what's the
workaround the workaround fortunately is
pretty straightforward my clicker OOP
okay
the workaround is fairly simple all you
do is call the quality structure
destructor manually not the prettiest
thing but you know C++ allows you to do
that and it's possible again hopefully
you won't be dealing with this this is
more a matter of completeness and me
being entirely upfront on on some of the
little things that that exists again I
don't think this really will affect your
debt
day to day okay
errors and warnings this is this is
probably the biggest gotcha that I hear
complaints about and it's because in C++
value objects are extremely common and
if you want to have a value object or an
embedded object that's part of an
objective-c object you get some really
bad errors and warnings that basically
tell you crazy things like the V tape
the V table has virtual member functions
and all kinds of crazy stuff that it
just doesn't make sense and it's because
again the object runtimes the two object
runtimes don't collaborate when dealing
with this construct mainly because at
the time we couldn't figure out how do
we maintain the design point of keeping
the runtimes distinct and solve this
problem we had incorrectly assumed that
it was impossible fortunately we figured
out how to do it and we'll be providing
it in a future release for now there's
there's a workaround right now if you
declare them reference and you
instantiate them directly it's it won't
cause you any grief again because new
will do the correct thing and as I said
this limitation is is going to be
removed and it'll just work as as
expected so there are several several
people anxiously waiting for that for
this one I know and hopefully I'll make
their lives easier so I don't know if I
went too fast here we're going to
fortunately have some some nice about 20
25 minutes left for QA which I really
value and given the number of people
here I'm sure there's plenty of
questions to ask about this but here on
are some take-home points I think it's
fairly clear that doing this stuff is
fairly straightforward the learning
curve if you're already a C++ programmer
is very low now if you're not a C++
program
and you're not an objective-c programmer
this isn't the language for you right
this is this you know yeah
Apple is using this extensively in
almost every part of the company whether
it be RI apps pro apps i chat safari and
many third-party apps i've seen and many
that that aren't public they're using
this extensively and it it's proven
itself so I feel really confident in
advising you guys to use this because I
think it's going to save you time and I
think it's also going to expose people
from the C++ language culture to new
metaphors new ways of building systems
that I think will also benefit you and I
think both languages compliment one each
each other I am I'm constantly amazed at
how they really don't get in each
other's way this wasn't clear when we
did it many many years ago and in fact
you know we were concerned about
creating a monster and and I don't think
we've done so I think this is a very
expressive tool and I think if if C++
would have become the next C which is
what I thought
15 years ago when C++ was being
developed I was fairly convinced that it
was going to be the next iteration of C
then this would seem even more natural I
think the only reason that it even seems
to be a little controversial is because
C++ didn't become formally the next C
even though it's the de-facto next
iteration of C and I find most people
doing serious application development
are using it in some way so
documentation
and Matt Formica he's our tools
evangelist