Re: GNUstep on Mac OS X screenshots

[Pascal J . Bourguignon]

Stefan Urbanek writes:
> On 2004-02-06 23:11:37 +0100 phtamulonis@hotmail.com wrote:
> 
> > For those interested, I've put up some (lousy) screenshots of the
> > GNUstep dev  apps running under Apple's X11.
> > 
> > Here's one of PC with PB and Xcode for comparison:
> > 
> > http://mysite.verizon.net/mgp_corp/PCPBXCODE.jpg
> > 
> 
> Interesting, that both PC and PB/Xcode are still *file* oriented
> development environments even noone thinks of files when designs an
> application...
> 
> It can be done differently and better, could not it? (Hint: directly
> Framework,Class,Prototype or Object oriented)
> 
> Think,

It could. But it's better not.


There are problems with the notion of object (mixing data and programs):

      - portability problems,
      - security problems,
      - efficacity problems (how not to duplicate the code in all objects?)

When you have  stored objects, you're in a big  doodoo: try to recover
the NIB  files (that  ARE typedstreams, that  is stored  _objects_) on
another system  than NeXTSTEP.  Other  examples would be  Lisp images,
where the "objects" are stored in  whole, and that you lose as soon as
you change  of implementation  of even only  of version of  lisp.  But
that's not a  lisp problem. Smalltalk too save  its objects (and here,
true objects) in an image file,  and the same problems occur: the only
solution is to have fileOut: and fileIn:. FILE out and FILE in!

But you can see it the other way:

Actualy, you already have what you want! Indeed, file systems are just
big object  repositories. For example,  you have this object  of class
"Objective-C source" named: 
        /usr/local/src/gnustep/src/core/base/Source/NSDate.m
and this other object of class "object code" named:
        /usr/local/src/gnustep/src/core/base/Source/NSDate.o
and you've got a set of methods applying to them:
    mv, cp -r, ...   (on the generic class "file system item")
    cp, rm, ...      (on the class "not a dirctory item")
    gcc, ...         (on the class "C, Objective-C, C++ source")
    ld, ...          (on the class "object code")
etc.

What more would  you get in storing these  objects elsewise and having
to reimplement all this methods otherwise?


-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/