• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Dynamic Languages [was: Re: why Obj-C]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic Languages [was: Re: why Obj-C]


  • Subject: Re: Dynamic Languages [was: Re: why Obj-C]
  • From: Matthew Johnson <email@hidden>
  • Date: Sat, 06 Apr 2002 18:29:51 +1000

On 6/4/02 3:44 PM, "Dan Crevier" <email@hidden> wrote:

> On 4/5/2002 6:26 PM, "Matthew Johnson" <email@hidden> wrote:
>
>>> * It solves the fragile base class problem. If you try to ship a C++ shared
>>> library that others can use, as soon as you update it, all apps need to be
>>> relinked since everything is pointer driven. With the message dispatching
>>> in Objective-C, no such problem exists.
>>
>> That's not true. I think your are mistaking static libraries with dynamic
>> libraries. A good example of shared objects doing what you say they cannot
>> is plugins for programs like netscape or explorer.
>
> Netscape/Explorer plugins use a C API, not a C++ API. If you use C++ in a
> dynamic library, any application linking to it will break if you change the
> class's API.

Sorry your right if your using C++ and classes and mangled functions. But if
your using C++ to generate functions (unmangled with extern "C", in this
case you could as well used C). I use C++ to generate dynamic libraries
every day. I prefer writing C against the C++ compiler as it makes you write
neater code.

>>> * It makes a lot of the functionality in IB possible. For example, you can
>>> specify in IB to call a function basically by name when a button is clicked
>>> or whatever. Of course, you get a runtime error instead of a compile time
>>> error if you screw up. To do the same thing in with a C++ framework
>>> requires having the interface builder generate code instead of just
>>> resources, and that because a big mess when you also want to edit that code
>>> and then go back and make UI changes.
>>
>> Again this can be be done using shared objects in C.
>
> What are shared objects? Do you mean or C++? C doesn't have objects.

A shared object is a Dynamic library.

class Integer
{
int i

setValue(int n)
addValue(Integer j)
}

Typedef struct
{
int i;
void (*setValueFuncPtr)(int n);
void (*addValue)(int j);
} Integer;

I can create a object from both these guys.

A object being a instance of a class and a class being a data with
associated methods.

The one thing I have to do extra for the struct is associate methods with
the two function pointers. Kinda cool dynamic class really.

Matt
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Dynamic Languages [was: Re: why Obj-C]
      • From: Thomas Lachand-Robert <email@hidden>
References: 
 >Re: Dynamic Languages [was: Re: why Obj-C] (From: Dan Crevier <email@hidden>)

  • Prev by Date: Re: Dynamic Languages [was: Re: why Obj-C]
  • Next by Date: [OT](ish) - Short Job in London
  • Previous by thread: Re: Dynamic Languages [was: Re: why Obj-C]
  • Next by thread: Re: Dynamic Languages [was: Re: why Obj-C]
  • Index(es):
    • Date
    • Thread