[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Framework Classes
Re: Framework Classes
Tue, 14 Oct 2003 13:07:38 +0200
On 2003-10-14 12:48:20 +0200 Nicola Pero <address@hidden> wrote:
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
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
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.
First they ignore you, then they laugh at you, then they fight you, then you
- Mahatma Gandhi
- Re: Framework Classes,
Stefan Urbanek <=