Re: creating classes on the fly ??
Re: creating classes on the fly ??
- Subject: Re: creating classes on the fly ??
- From: Bill Bumgarner <email@hidden>
- Date: Wed, 26 Sep 2007 11:27:49 -0700
On Sep 26, 2007, at 11:12 AM, Scott Thompson wrote:
On Sep 26, 2007, at 12:50 PM, Daniel Child wrote:
Sorry for basic questions, but I've never looked into using an
alternate language like Python. Would I be able to make C-language
Carbon calls as well, all from within the same project?
Just speculating here, never having done it myself, but tools like
PyObjc, in spite of having Objective-C in the name, allow you to
communicate with application frameworks on Mac OS X through Python.
Those same frameworks contain C routines as part of their interfaces
so it makes sense that (through some mechanism) you should be able
to call arbitrary C routines from Python.
If you can wait until Leopard ships, Leopard includes the
BridgeSupport stuff and a version of PyObjC that fully embraces
BridgeSupport. This will also be migrated back to the public
Subversion repository and should not be terribly hard to retarget to
Tiger. (Note also that Leopard includes Objective-C 2.0 which, as
its name implies, is a vast step forward over previous versions. As
the name implies, the underpinnings have changed, including the
runtime's API. It is much much better, but the details are still
covered under NDA.)
RubyCocoa for Tiger uses BridgeSupport now.
With BridgeSupport, it makes it quite easy for something like
RubyCocoa or PyObjC to call into most API on the system, not just
Objective-C and without requiring hand written wrapper functions.
HOWEVER, getting back to the original posters question, I don't think
that using either Ruby or Python to gain dynamic class generation is
really going to be that terribly useful. From my rather ignorant
position of only casually following this thread, I'm not sure that
dynamic class generation is an appropriate solution. It could be
done, but I don't see an advantage over creating a set of classes that
effectively model whatever it is you are trying to model. That can be
quite dynamic and creating generic, dynamic, containers can vastly
simplify lots of things (archival, for example). This is exactly
what CoreData does with NSManagedObject and entities -- you don't need
to subclass NSManagedObject to store a particular entity.
b.bum
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden