|
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 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |