----- Original Message ----- | From: "Camillo Bruni" <[email protected]> | To: [email protected] | Sent: Wednesday, May 22, 2013 8:53:31 AM | Subject: [Pharo-dev] Messy Configurations | | I recently spent some time to revise how to write Metacello | Configurations. | | Observation: | ============ | - many configurations are quite a mess | - many configurations duplicate code internally | - many configurations have archived development versions | | | For Pharo 3.0 I made a new Configuration template which improves and | documents | these observed points in quite some detail. Simply load a new 3.0 | image and | create a new configuration from the monticello working copy browser. | | Solution: | ========= | - specify external projects in separate, reusable methods | - only have ONE development version you regularly update | - do not use version numbers for the development version | - only make a version number when you release something stable AKA | not #development | - name the baseline after the first version that introduces it | | | | What do you think?
Cami, I don't want to discount your frustration with the complexity of Metacello configurations and looking at your sample configurations you have definitely come up with a cleaner structure for the code ... But, (there always is a _but_) ... Metacello configurations are not really code ... they are specifications ... Metacello configurations are closer to XML files than they are to Smalltalk classes ... XML files are "read" by tools and "written" by tools ... You can hand edit an XML file to produce a pleasing structure for human readability, but when a tool gets ahold of the file and rewrites the XML file, all of the fancy hand editing disappears ... The same thing will happen with configurations ... you can restructure the code in your configuration using nicely structured methods, etc, however, if you use a tool to add/manipulate your configuration, all of the fancy "formatting" will be lost and the tool will write out a monolithic single method representation of your specification (leaving the rest of the configuration methods untouched) ... With that said, it is conceivable that a crop of tools can be written to produce "better structured configurations" ... meaningful pragmas could be invented so that tools and humans could both be aware of the "project methods" and other components that you've added ... but that is up to the tool builders ... Dale
