> did you read the class comments? > or Morph and Views Yes. I see that the Morph is delegating it's drawing to a View, but what I'm interested in is the rationale. I believe that documenting the design at a higher level, so everyone can understand the rationale and features, is the only way to keep Bloc clean and lean and prevent another "Morphic is so cool but impossible to understand".
Let's take the current example of the introduction of View classes Scenario #1: Design choice because of higher-level vision for Bloc? Right now views are hot-swappable: 1. Make a clock with "clock :=BlPolygonViewExamples exampleSimpleClock." 2. Now turn it into a vintage Bulova with "clock withRectangleView" That is awesome! But is it on-purpose? a documented feature? Those are important so a well-meaning refactorer doesn't come in and smash the design by bloating or removing important capabilities Scenario #2: Views extracted simply because Morphic Morphs were so bloated Morph methodDict size "962" BlMorph methodDict size "473" If #1 is the case, it may be important to preserve the feature, but if it's #2 we may not be as attached to that particular choice. > Decorators are not modularly extensible Bloc use a chain of command. I'm not sure what you mean. Right now, borders are an intrinsic part of BlEnclosedView. If Decorators were used (and I'm not saying they're appropriate, just asking), one could e.g. add multiple borders, or a border and scroll bars, etc. How are Decorators not modularly extensible when used that way? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Roadmap-tp4816171p4816747.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
