Re: [Pyobjc-dev] Separating functionality into modules

[Peter M. <zig...@po...>]

On Wednesday, November 20, 2002, at 02:39 AM, bb...@ma... wrote:
> On Tuesday, November 19, 2002, at 07:48 AM, Jack Jansen wrote:
>> On Monday, Nov 18, 2002, at 16:45 Europe/Amsterdam, bb...@ma... 
>> wrote:
>>
>>> It requires a compiled component to wrap a framework such that 
>>> enumerated types, #defines, and functions can be exported.  Ronald 
>>> has done an amazing job of automating the generating of the 
>>> wrappers, but it needs some work before it could automatically 
>>> generate a module project to wrap a specific framework.  That would 
>>> be very, very > cool...
>>
>> Oops, I missed that bit, I didn't realise there was an extension 
>> module too, I thought it was pure python.
>> [search.... search....]
>> No, I can't find it. Are you sure that this module isn't pure Python? 
>> Because if it is then my factory function idea should work (create a 
>> module, populate it with the classes returned by 
>> Foundation.load_bundle, return the module).
>> And, if there is C code for AddressBook: where is it?
>
> Hey, what do you know... you're right! I thought it had a compiled 
> component, as well!  I assumed it had a compiled component because of 
> the enumerated types and the global references used throughout the 
> module.
>
> Let me amend that:  It *needs* a compiled component if it is to be a 
> complete bridge of the AddressBook framework.  Sorry about the 
> confusion.

PyObjC seems to favour automatically generated code wherever possible. 
Could we do the same thing for wrapping frameworks? A tool could take a 
list of variable types and names and automatically generate and compile 
the needed wrapping code. This would help users (and developers) who 
want to completely wrap a framework but don't know the ins and outs of 
writing a Python C module or how to interface with the PyObjC module 
(if that's needed).

You could probably do the same thing for C APIs, C functions etc. 
Anything that isn't a simple global variable, a constant or a straight 
forward C function would need a custom wrapper but most of the APIs on 
Mac OS X are pretty clean in this respect. Most of Mac OS X's 
frameworks are C APIs. It would be nice if we could wrap those as well. 
Is it possible to dynamically load non-objc frameworks though?


>> At the moment there isn't much, indeed, but I can imagine it growing. 
>> With Python's multiple inheritance and operator overloading, for 
>> instance, there's all sorts of nifty things you could do, such as
>> class TableViewList(list, PyObjC.listTableDataSourceMixin):
>> 	pass
>> x = TableViewList()
>> and then use x both as a normal Python list and as an 
>> NSTableDataSource. Note that I haven't actually worked this example 
>> out (so it may be plain impossible), but you get the idea.
>
> Totally possible and a very cool idea!   I constantly use a couple of 
> hunks of code that I have developed over the years to map an array to 
> an NSTableView and map a set of collection classes to NSOutlineView.

Totally possible but is there a better way? 
PyObjC.listTableDataSourceMixin would have to be pretty dependant on it 
also being the subclass of a list so why make the user do it? You could 
make a class called PyObjC.listTableDataSource that inherited from list 
and implemented the data source methods and just let the user use that. 
Your method would be more flexible in that it would work with any 
sequence type. Maybe you could do both: have the mixin class and have a 
couple of convenience classes with the data source already mixed in. 
Hmm, convenience classes for convenience classes...

I realise that this was just an example. There are many possibilities 
for convenience stuff. It would be funny if PyObjC became more powerful 
than the ObjC version of Cocoa and had very useful features that the 
ObjC version didn't have.


>> Another example of a python-specific functionality is a mixin class 
>> for a dialog that would automatically keep the dialog items synced 
>> with another object (using Pythons introspection to obtain the names 
>> of the dialog items, looking them up in the other object. Combined 
>> with slots this could even happen completely automatic).
>
> Not sure I get this one...

I think he's talking about doing the standard "Controller" bit of the 
MVC paradigm automagically. There is a lot of stuff that a Controller 
class does that is done almost every time and is quite tedious to 
program. You're not going to be able to eliminate this repetitive 
application logic completely but this could help in making PyObjC a 
really easy RAD environment. Of course I probably misread his idea.

Peter