Anonymous | Login | 04-12-2021 16:38 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | |||||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
0006593 | [Squeak] Morphic | major | N/A | 08-06-07 18:49 | 10-09-07 02:07 | |||||||
Reporter | wiz | View Status | public | |||||||||
Assigned To | ||||||||||||
Priority | normal | Resolution | open | |||||||||
Status | new | Product Version | ||||||||||
Summary | 0006593: Whitler's Mother (Morphic ) . A parent for reports aimed at whitling the morphic package down to size | |||||||||||
Description |
The Morphic package weighs in at over a megabyte Morphic Extras and Etoys packages are also unwieldly . The three packages interdependence on each other also points to a large design and coding debt. This is a Mother issue for reports that help solve portions of that problem. |
|||||||||||
Additional Information |
My proposed stratagy for tackling this problem is incremental. There need to be probes to 1) uncover the dependencies. 2) determine the true centers of pieces within morphic There need to be results of those probes to generate a list of needed repairs. And then the repairs need to be made one by one and tests generated to guide them. With an emphasis on chipping away at it, piece by piece. And an emphasis on eventual elegant packaging. With a high coherence amoung methods within a package and high decoupling amoung pieces in different packages. Morphic consists in my mind of highly composable tools that can be easily manipulated with a informative and responsive gui. And which requires of the user a minamal use of coding to achieve their purpose. The code for Morphic reflects its development. Many cooks. Little though given to refactoring what is already there. The start for fixing things is to whittle away at the edges. Identify leaves (classes that don't have subclasses) and package them sperately. Letting the core become smaller. Identify major dependencies. The Morphs behave differently depending on how they tilt. There are polygons el al Rectangles, ellipses and other flex morphs TTfonts and other that depend on ar's MatrixTransforms. And worlds and hands which don't really tilt at all. There are also major pieces that come from different branches and don't really integrate well. (smalland, squeakland, etc.) I am writing this at a beginning step the details will become clearer an more concrete as things proceed. Part of the process is learning more about the problem. So let us begin... Yours in curiosity and service, -Jerome Peace |
|||||||||||
Attached Files | ||||||||||||
|
![]() |
|||||||||||||||||||||||||||||||
SYSTEM WARNING: Creating default object from empty value SYSTEM WARNING: Creating default object from empty value SYSTEM WARNING: Creating default object from empty value SYSTEM WARNING: Creating default object from empty value SYSTEM WARNING: Creating default object from empty value
|
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
78 total queries executed. 42 unique queries executed. |