discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep on Mac OS X screenshots


From: Raffael Herzog
Subject: Re: GNUstep on Mac OS X screenshots
Date: Tue, 10 Feb 2004 02:19:11 +0100
User-agent: Opera7.23/Linux M2 build 518

On Sun, 8 Feb 2004 20:20:43 +0100, Pascal J.Bourguignon <pjb@informatimago.com> wrote:


Stefan Urbanek writes:

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)

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. [...]

I agree that storing objects themselves isn't a good idea. But why does ProjectCenter show me any files? I'm not dealing with files, I'm dealing with classes and resources.

In Java, this isn't too much a problem as you normally use one file per class and put *all* of the class definition into that one file. But in ObjC you have these annoying file pairs (.m+.h) because interface and implementation are separated, so you have to write each method signature twice and keep the interface and the implementation in sync manually. The compiler helps by warning about nonimplemented, but declared, methods. But it doesn't warn about implemented, but not declared methods...

The structure of GNUstep projects is actually very straight-forward and therefore very well suited for a more abstract view on the project. There are resources (global or localized in an lproj), ObjC classes/categories/protocols, maybe some C modules and maybe some subprojects. Categories can be public (i.e. declared in the .h file) or "private" (declared in the .m file).

ProjectCenter could provide such a "logical" view on a project - for the "physical" (filsesystem) view, there's still GWorkspace/FileViewer. This would ease development a lot, e.g. one could use Code->New Class to create a new class, select it, choose Code->New Method, edit the method (and its signature), File->Save to save that stuff which would cause both the .h and the .m file to be updated. VisualAge for both Smalltalk and Java provide such a view (actually, with those tools, there isn't a filesystem at all, the code is stored in an OODBMS).

ProjectCenter could then furthermore provide utilities to manage localized/non-localized resources, localized strings etc. (e.g. in VisualAge: Select a string and use Tools->Externalize to move it into a resource file).

I'd love to see ProjectCenter being based on such an abstract, logical view on the code.

I'm not talking about storing memory images, as Smalltalk does, I'm talking about providing a view on the code that matches what the developer is actually dealing with and releasing him from annoying "languagisms".

cu,
   Raffi

--
The difference between theory and practice is that in theory, there is no difference, but in practice, there is.

Raffael Herzog - herzog@raffael.ch - www.raffael.ch - ICQ #67961355




reply via email to

[Prev in Thread] Current Thread [Next in Thread]