--- a/ProjectDefinition.st	Fri Feb 24 02:35:24 2017 +0100
+++ b/ProjectDefinition.st	Fri Feb 24 09:59:16 2017 +0100
@@ -84,20 +84,25 @@
     As ST/X is (still) very tightly bound with stc, we keep the package and project information
     in a class-object (instead of some project object) and all queries about package contents and 
     attributes are implemented as class methods. 
+    (after all: a class is an object, which can be asked by sending it messages...
+     ... so why would one want extra meta-descriptions with extra syntax?)
+    
     This has the advantage, that it can be compiled and included in a compiled class library just like any other class.
+
     Every package includes a subclass of me (an instance of my meta), which provides useful
     information about the versioning and packaging. 
     Me myself, I know how to generate dependency information and can generate makefiles and other build-support 
     files for compilation (see the browser's 'Checkin Build Support File' menu item. For more details, see
-    section 'Build Support Files' below.
+    section 'Build Support Files' below).
 
     When a package is loaded from a binary shared class lib (i.e. a compiled class library is loaded
     via 'Smalltalk loadPackage:'), the loading is done in multiple phases:
         1) the shared object is loaded, but not installed (registered) in Smalltalk
         2) the ProjectDefinition class is registered and initialized.
-        3) the ProjectDefinition class is asked to load its prerequisites. This may lead to other packages
-           to be loaded - either as binary class libraries or from source, whichever is found.
-        4) the remaining classes and extensions are registered
+        3) the ProjectDefinition class is asked to load its prerequisites. 
+           This may recursively lead to other packages to be loaded 
+           - either as binary class libraries, as bytecode or from source; whichever is found.
+        4) the remaining classes and extensions of the package are registered
 
     ## Some special notes about extension methods:
       if a package is loaded (Smalltalk loadPackage:'foo:bar/baz'), any already loaded package of which
@@ -109,21 +114,21 @@
 
       Also, the information about which other package was in charge when a method is overwritten is recorded in
       extensionOverwriteInfo. 
-      This is used to correctly reinstall an overwritten method, whenever a package is unloaded.
+      This is used to correctly reinstall any overwritten method, whenever a package is unloaded.
 
     ## Build Support Files
 
-    To support pre-compilation of a package, ProjectDefinition can generate a set of makefiles and other
+    To support compilation of a package, ProjectDefinition can generate a set of makefiles and other
     support files to allow that. To see the set of files that should be generated, see #fileNamesToGenerate.
     These files are usually generated and saved to the repository upon a commit - the source code management
     does (should) care for this.
 
-    Packages may add more files to this list by defining an (extension) mehtod in project definition class
+    Packages may add more files to this list by defining an (extension) method in project definition class
     and by annotating the method by <file:overwrite:> annotation:
 
         * the first parameter is the file name to generate as String, relative to the package root. As directory
           separator, use slash (as on UNIX), it will be automagically converted to platform's separator.
-        * The second paramterer (true or false) tells the SCM whether the file should be generated (and thus
+        * The second parametrer (true or false) tells the SCM whether the file should be generated (and thus
           overwritten) upon each commit (when true) or only the first time (when false). Important: see the 
           remark below.
         * The method itself should return file's contents a string. If it returns nil, then the file is *not*
@@ -2904,10 +2909,12 @@
      on which documents are handled by the application.
      This is used eg. for double-clicking on a document in OSX.
      If the deployed app can/should handle this, redefine this
-     to return a collection of instances of me."
+     to return a collection of instances of ApplicationDocumentTypeDescription."
 
 
     ^ nil
+
+    "Modified (comment): / 24-02-2017 / 09:36:42 / cg"
 !
 
 applicationIconFileName
@@ -5353,7 +5360,8 @@
     ] ifFalse:[
         plist at:'CFBundleName' put:(self applicationName).
         plist at:'CFBundlePackageType' put:'APPL'.
-    ].    
+    ].
+    
     (icnFilename := self applicationIconFileNameOSX) notNil ifTrue:[    
         plist at:'CFBundleIconFile' put:icnFilename.
     ].
@@ -5375,6 +5383,8 @@
     "
      exept_expecco_application info_dot_plist
     "
+
+    "Modified (format): / 24-02-2017 / 09:35:09 / cg"
 !
 
 packageName_dot_rc
@@ -8427,11 +8437,13 @@
     ^ typeName
 !
 
-typeName:something
-    "something like 'foo Document';
+typeName:aString
+    "aString like 'foo Document';
      eg. 'expecco test suite', 'expecco log file', etc."
 
-    typeName := something.
+    typeName := aString.
+
+    "Modified (comment): / 24-02-2017 / 09:37:26 / cg"
 ! !
 
 !ProjectDefinition class methodsFor:'documentation'!