Re: Framework Classes

[Stefan Urbanek]

Hi,

On 2003-10-14 12:48:20 +0200 Nicola Pero <nicola@brainstorm.co.uk> wrote:

> > Hi Nicola,
> >
> > Would it be possible to create some property list in frameworks
> > with list of all framework classes? Something that can live in 
> > *.framework/Resources/FrameworkClasses.plist with array of all classes.
>
> Can you give me an example of how it would help/benefit you ?

Sure. I'm working on DevelopmentKit and AgentFarms. I want to create an 
integrated development environment (for AF Modes) where one will need as little 
as possible about building system underneath. All knowledge about the building 
process should be hidden in DevelopmentKit framework. That means, that users 
will be able to create projects just by defining classes and refering to other 
classes from foreign frameworks. The devel kit framework should help the user 
in the process of development by automaticaly finding/linking/header including 
a framework for a class that user needs.

So, in other words, user will just select classes required for his project and 
the develkit framework will do the rest:
- complete source codes with appropriate #includes
- add required framework paths
- add list of linked frameworks
and then Develkit can build users bundle/model/whatever.

Reason for this is, that the application i am developing is meant to be used by 
users that do not know much about all that building processes (and they do not 
need to know that!). So, I think, if we have the knowledge of the development 
environment, we should put it into a framework.

Moreover ProjectCenter can use this functionality for easier framework 
searching/linking.

> > I do not know how to implement it, but AFAIK, there is some code that 
> > generates similar list in a source file. Would it be possible to reuse that 
> > code to generate one .plist?
>
> If you can convince me that there is an advantage in having the .plist
> file, maybe we should always generate the .plist file instead of putting
> the list of classes in an automatically generated class.  Instead of
> reading the list of classes from the automatically generated class, 
> gnustep-base itself could read it from the .plist file.

Well, if we already have a funcitonality in gnustep-make tha generates such 
list, then i think that the list should be provided as public. At this time it 
is private to gnustep libs, by providing it as public anyone can reuse the 
information.

To be future compatible, the plist should be not just an array, but some 
dictionary. At this time with just one key: 'Classes = (array)'.

Developers of some kinds of projects, like
- simulation models, in my case
- application additions/modules/bundles
- application filters
- ...
do not need to know too much. All they need is a basic knowledge of programming 
language they are going to use and basic principles of their application. The 
rest can be done automatically - developer of an app will provide development 
environment for modules/buindles/filters/models that is easy to use.

Thing is, that such a simple development environment can be created very easily 
by the nature of GNUstep. What we need is just to provide enough metadata about 
all objects in the development process.

Convinced? :-)

Stefan Urbanek
--
First they ignore you, then they laugh at you, then they fight you, then you 
win.
- Mahatma Gandhi