Re: import vs include Re: Porting autogsdoc to OSX

[Pascal Bourguignon]

> From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
> 
> On Wednesday, February 27, 2002, at 09:21 AM, Helge Hess wrote:
> > BTW: it is not required by the API of Foundation that HTTP URLs are 
> > supported ! This capability can easily be added by another library.
> 
> It's true that the API doesn't actually specify that any particular URL 
> schemes be implemented,
> but in fact MacOS-X *does* implement this stuff, and the class is rather 
> useless otherwise.
> 
> >> So ... far from breaking portability, inclusion of this functionality 
> >> is critical for ensuring
> >> portability with MacOS-X (and we're looking at making this stuff 
> >> readily usable from MacOS-X
> >> apps as well as just usable internally by the base lbrary).  Ok, it's 
> >> not portable with the
> >> (effectively dead) OpenStep spec.
> >
> > No, MacOSX compatibility is absolutely required, I agree. What I fear 
> > (and this already has happened) is that internal API besides Foundation 
> > (as specified by MacOSX API) is exported.
> > I see a huge potential in gstep-base for becoming bloated. In my 
> > opinion it should be Foundation, nothing more.
> 
> Well, bloat is a danger ... we are tracking MacOS-X and I think their 
> Foundation is perhaps becoming bloated.
> I don't see any reason for all the apple scripting code being in 
> Foundation, and we haven't added that yet
> (though I guess we might).

AppleScriptKit is not included in Foundation. There are separate frameworks.

AGL.framework/
AppKit.framework/
AppKitScripting.framework/
AppleScriptKit.framework/
AppleShareClient.framework/
AppleShareClientCore.framework/
AppleTalk.framework/
ApplicationServices.framework/
AudioToolbox.framework/
AudioUnit.framework/
Carbon.framework/
Cocoa.framework/
CoreAudio.framework/
CoreFoundation.framework/
CoreMIDI.framework/
CoreMIDIServer.framework/
CoreServices.framework/
DVComponentGlue.framework/
DirectoryService.framework/
DrawSprocket.framework/
ExceptionHandling.framework/
Foundation.framework/
GLUT.framework/
IOKit.framework/
InterfaceBuilder.framework/
JavaEmbedding.framework/
JavaVM.framework/
Kerberos.framework/
Kernel.framework/
LDAP.framework/
Message.framework/
OpenGL.framework/
PCSC.framework/
PreferencePanes.framework/
QuickTime.framework/
ScreenSaver.framework/
Scripting.framework/
Security.framework/
System.framework/
SystemConfiguration.framework/
vecLib.framework/

 
> I know you have been told this before ... but the GNUstep API is clearly 
> marked as such and readily disabled
> with a simple compile time flag, so there is no portability problem 
> there (for people who want to write
> portable code).  I think I got tyhe impression in the past that this is 
> not enough for you, and you wish to
> force people to write portable code whether they want to or not.
> 
> We are also moving towards making some stuff (like XML parsing) 
> available as a separate library, to make
> it easier to take advantage of GNUstep specific stuff on MacOS-X where 
> people want to - but I don't see
> that as high priority.
> 
> >> Sure, these are features that the old OPENSTEP and libFoundation 
> >> Foundations lack, but I think
> >> ensuring portability to/from MacOS-X is the first portability priority.
> >
> > Well, you are wrong here. libFoundation currently lacks non of the 
> > features you are talking about !
> 
> OK. I haven't looked at it for a while, but in that case, not having 
> them would break compatibility
> with libFoundation too.
> 
> > But it has a minimalistic approach in supporting the MacOSX Foundation, 
> > eg XML plists and HTTP URLs are added in user-level libraries, not in 
> > the core itself, since this is *NOT* required at all by the MacOSX 
> > Foundation API.
> 
> Ah ... but we are trying to be compatible, not just use the same API.  
> As much as possible we want
> to avoid having to locate and link additional frameworks to do what on 
> MacOS is all in one.
> Not that there is anything particularly hard about linking in extra 
> libraries, but why confuse
> developers by providing frameworks which have the same API but different 
> functionality?
> 
> >> To the best of my knowledge there has never been portability between 
> >> foundations -
> >
> > gstep-gui has run on NeXTstep Foundation, libFoundation and gstep-base.
> 
> Please!!! That does not support your assertion about portability, and 
> does not answer my objections.
> To say that gstep-gui has run on NeXTstep and libFoundation is 
> misleading in the extreme, since you
> must be talking about either a very old version or a very cut down 
> version.
> 
> Yes, there is a core of functionality which is portable between all 
> foundations, but no addition of
> extra features is likely to effect that.  So in the sense in which you 
> used the term originally
> (ie wanting to avoid extra features so that all features would be 
> available in all foundations),
> I repeat that there has never been any such thing.
> 
> Actually, I'm beginning to get a sense of deja-vu ... hasn't this been 
> said on this list before?


-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------