[Pythonmac-SIG] Finding what a broken alias refers to.

[Ronald Oussoren]

On 24-jun-2005, at 15:27, Dethe Elza wrote:

> Ronald Oussoren wrote:
>
>
>> Someone with copious free time should build new Carbon wrappers, we
>> can than ask if the existing wrappers can be dropped in a future
>> version of Python. Sadly enough that probably is with python 2.6 at
>> the earliest, which is a long way away.
>>
>>
>
> Would there be any benefit to documenting bgen?  It seems like the  
> functionality it provides is useful, so that might be the first  
> step to building a worthy replacement. Or do you feel that the bgen  
> approach is fundamentally flawed?  And if so, what should be done  
> to replace it?  You're not suggesting manually wrapping Carbon, are  
> you?

Documenting bgen would surely help. But to do that you'd have to  
learn bgen first and that's not something I'd want to do unless I  
wanted to use it.

I'm not happy with the way that the Carbon wrappers work, adding  
Carbon functions as methods of seemingly related classes. This makes  
it harder to map documentation for Carbon to Python. It is also  
ugly.  But this might not be a problem with bgen itself.

I'd prefer to see the function wrapped as functions in the Carbon  
module. If needed one could add convenience methods to type wrappers  
as well, but with a more pythonic interface. That would require more  
work because you'd have to make up a nice interface and document it.

>
> Bob Ippolito wrote:
>
>
>> The problem with Carbon wrappers is that they have such diminishing
>> returns.  The longer you wait, the less reason there is to use Carbon
>> in the first place.
>>
>> If we just sit on our hands for another few years, all of the
>> functionality in Carbon will be available elsewhere anyway :)
>>
>>
>
> So in that scenario we don't need bgen at all, right?  But there is  
> still a significant chunck of functionality that is not exposed to  
> Cocoa.  Unfortunately, I don't know what the borders look like  
> until I stumble across them (and the new Quicktime framework  
> definitely shifted the borders pretty significantly).

bgen isn't really needed in the first place. You could use the  
scanframework script of PyObjC as well (whenever that is finished),  
possibly with some tweaking. In a way bgen is simular to swig, but  
with different issues.

>
>
>
>> I have no intention whatsoever to work on new Carbon wrappers because
>> all functionality I need is already available elsewhere. However, we
>> do need a plan to get rid of the current wrappers (especially the
>> Carbon.CF ones) to make room for better ones. I do want to add
>> wrappers for CoreFoundation (and frameworks based on CoreFoundation)
>> to PyObjC and would like to drop for Carbon.CF when that's done.
>>
>> There may be other frameworks that are useful (OSA stuff, QuickTime)
>> and could use wrappers with betters tests and documentation.
>>
>>
>
> Is there a hitlist of frameworks that would be good to support, but  
> are not supported yet? What are some of the best targets for  
> someone who wants to jump in and help out?

The best way to start is find some framework that you want to use and  
check if the wrappers for it exist and/or work.

Ronald