Ok so to clarify what I want with Spec: - move LayoutFrame outside of Morphic. Now I'm not sure that spec should depend on it, may be. - LayoutFrame is a bad name for a transformation specification. - I do not think that an Array is good but I do not think that using two rectangles is good either Do we think that (0@0 corner: 1@1). (0@22 corner: 0@0). is readable? No it looks quite bad and as bad as #(0 0 1 1 0 22 0 0) Probably we should have layout {LayoutFrame rightOffset: 22) instead of specifying everything when this is not needed especially since now LayoutFrame new is equivalent to (0@0 corner: 1@1). (0@00 corner: 0@0) - Finally we should not edit by hand such methods and esteban will work on that. - We should - rethink the contents of spec methods they should cover structural information such color, defaultExtent; minimalExtent:â¦and this should be modular (it is already). Each kind of spec should be responsible of declaring what it needs to create its visual component. - we should be able to mix structural specification with DSL driven ones. RIght now when you use the dsl you cannot specify structural information at the composite level (I may be wrong) - rethink if we use a class for each specific spec elements so that we can build nice visitors I do not remember how this is done in Spec. In VW this is like that (but visitors are not used or I missed them). - revisit the interpreter because it is not modular. right now this is difficult to extend it and it would be better that the interpreter delegates to each of the spec elements their interpretation. Have a look at the method interpretASpec: aPresenter - rethink the asArray methods. You will see that they implement some spec layout algorithms that are not independent of Morphic and quite complex (note that we simplified these methods). So we should understand and see because I have the impression that they are outside of Spec more on layout in general. - with igor we fixed fractions:offsets because it creates rectangles with negative height and width. => this brings some problems when we want to fix intersect: and this is really important because the intersection of disjoint rectangles is not a negative ones. Right now this works because the primitives are discarding call with negative arguments but this is doomed by construction. Now we could have ignored Spec and let benjamin do the dirty work and we would have waited to be able to go to the next step. So we took our energy and fixed Spec too which I think is normal because if this is part of the infrastructure then we should maintain it. But we are not expert on Spec and it would have been more fun to do it with Ben. Now we just did what we think is good and during holidays is one of the few moment of calm I can haveâ¦. so we did it at that time because of that. Stef
On 8 January 2013 18:12, Sean P. DeNigris <sean@clipperadams.com> wrote:
Benjamin Van Ryseghem-2 wrote
Why using a meaningless array when we could use object ?
+1. This seems hard to use/understand. If we don't want to depend on Morphic, let Spec define its own intention revealing messages.
Or pull LayoutFrame out into a separate package. That Morphic depends on that new package doesn't matter at all; what matters is that LayoutFrame doesn't depend on Morphic. LayoutFrame's a nice simple class.
frank