[Pythonmac-SIG] Re: [pyobjc] portability and clean starts (was:NSAutorelease support)

[Bill Bumgarner]

It was dropped because of very little interest combined with fairly sweeping changes
to python that were sucking up everyone's time-- I remember when the decision was
made-- and none of us [Lele, Jeff, myself or others] had the time/motivation to step
up and maintain the stuff.   There has basically been zero effort aimed at this
codebase in the last 2.5 years-- and it was minimal for nearly 2 years before
that....

My point was that Objective-C doesn't exist in the Carbon libraries on MacOS.  The
lack of the Foundation level APIs [NSBundle, mostly] on that platform are moot when
considering the porting aspects.  If the goal is to bring a binding into *some
other* ObjC runtime on MacOS, then we need to seriously consider whether using any
of Carbon or Foundation makes *any* sense beyond simply providing a shim into the
existing object framework on that particular platform.   Instead, maybe we would
need to look at doing something like the os module in Python-- that is, provide a
generic ObjC module, but have it effectively be an abstract cover for ObjC.GnuStep,
ObjC.MacOS, ObjC.MacOSX, etc,etc,etc...

In terms of supporting OSX/OSXS/Darwin, the existing codebase is close to doing
that-- it just needs to be cleaned up a bit-- and could be relaitively easily
spruced up to again support GnuStep (if it doesn't already-- anyone checked??).

However, ultimately, I would rather not be distracted by such high level
considerations.  We have a codebase that mostly works [thanks to you, Steve!!] and
with a bit of iterative refactoring, it could be cleaned up and become a relatively
first class implementation across Darwin, GnuStep, and OSX[S].

b.bum

"Steven D. Majewski" wrote:

> On Wed, 8 Nov 2000, Bill Bumgarner wrote:
>
> > AFAIK, Carbon on MacOS does not include ObjC-- so, no point in going to the
> > relatively primitive CoreFoundation API because it won't gain portability to
> > that environment and it will greatly impede portability to GnuStep/OpenStep....
>
> My point is that portability w.r.t. GnuStep/OpenStep/NextStep/Cocoa/...
> is a different dimension than portability for
>         Darwin(including Darwin on Intel)/MacOSX/ClassicMac+CarbonLib.
>
> There *MAY* be portability advantages (in that second dimension) to
> using the lower level and common (among that family) interfaces:
> more code to initially write, but less total code to support all
> of those system.
>
> Supporting all the *Step flavors probably means more work, and it
> becomes prohibitive if there aren't enough users, testers and
> maintainers. ( Isn't this why PyObjC was dropped from the Python
> core distribution ? If there are a lot of Python + GnuStep users
> lurking out there, please speak up! )
>
> The main advantage of a clean start would seem to be to make a
> clean start and get rid of a lot of untested #ifdef's .
>
> ---|  Steven D. Majewski   (804-982-0831)  <sdm7g@Virginia.EDU>  |---
> ---|  Department of Molecular Physiology and Biological Physics  |---
> ---|  University of Virginia             Health Sciences Center  |---
> ---|  P.O. Box 10011            Charlottesville, VA  22906-0011  |---
>                 "All operating systems want to be unix,
>                  All programming languages want to be lisp."