On 3 April 2016 at 20:51, Thierry Goubier <[email protected]> wrote:
> Le 03/04/2016 19:12, Igor Stasenko a écrit : > >> >> >> On 3 April 2016 at 19:48, Thierry Goubier <[email protected] >> <mailto:[email protected]>> wrote: >> >> Le 03/04/2016 17:33, stepharo a écrit : >> >> If you want to change clicking behaviour you need to override >> one single >> method. >> >> >> Everything you wrote with unreadable amount of >> characters is >> for nothing. >> >> I see clearly point of Igor. And for me it feels very >> logical. >> With such design you can lively change clipping area and >> interaction area for any morph (element) on screen. >> >> >> In short, i see only two cases where indeed, morph requires >> a nothing >> of shapes to define: >> - clipping region(s) >> - ui interaction region(s) >> >> but for drawing? nooooo... really? who cares what you draw >> there? >> draw anything, in any possible way you see fit.. compose, >> decompose, >> recombine, blend and mix.. that's the whole purpose of >> drawing and be >> artistic and be able to express yourself in any possible way >> you want :) >> Why nailing and formalizing things that are tend to be hardly >> formalizable and more than that, unnecessary. >> That's my main concern about current design. >> >> >> I agree. >> I do not see why people are forced to create a submorph just to >> change >> the rendering. >> If you want to change it dynamically you can for example pass a >> different shape. >> >> >> I don't see the problem with subclassing a morph. >> >> Me neither. But do you confusing subclassing and submorph compositing? >> > > Let me return you the question then: do you do a composition of submorphs > if you're trying to get a different drawOn:? > > Who, me? No. Maybe i was just misunderstood your reply. Because what i was tried to demonstrate in previous post(s) that there's simply no easy way to expose all possible drawing operations via composition of morphs (or composition of any other kind of elements), unless, of course you will lift full feature set of Athens to the level of composition.. As result you will get a full feature set that Athens provides, plus extra complexity. Sounds like thing to do, no? :) > Oh, ok, that's true FastTable does it for the selection... changing > background color by encapsulating a row in another Morph with the right > background color. > > Well, i don't know what is FastTable beast are.. so i cannot comment on this one. > > The reverse: I feel like current Morphs are huge monsters of >> configurability and parameter blocks and properties and intricated >> code and thousands of methods so that one doesn't has to subclass... >> >> Agree, the Morph protocol is bloated. And i don't like it too. >> That is a result of lifting features and properties up in inheritance >> chain. >> And i can imagine how it happens over time: >> - we have a morph.. >> - hurray! >> - can we have a morph with a border? >> - yes! Here BorderedMorph for you! >> - nice.. but can i use border in another subclass of Morph? >> - yes! Here borderStyle: property for you.. (and BorderedMorph is now >> useless) >> >> Or take a layout.. We could have , say, MorphWithLayout class. That >> introducing layouts. While other, simpler morph don't. Really, what >> layout you need in a morph that contains a plain rectangle fully >> covering its bounds? >> Or even 'having submorphs'. We could have MorphWithSubmorphs. Which >> could introduce submorphs concept. >> >> Separation of concerns. Good way to go. But if you need to have a morph >> that both has layout and border, then you are in trouble: you forced to >> do one of following: >> - make own Morph subclass, duplicating features of both.. or make a >> composition of submorphs that will represent both features, or... lift >> both features to the top of inheritance chain, getting bloat as result. >> Most of the times, most of things are achiveable through composition.. >> but some of them.. like drawing - apparently not. >> In any case i agree, that many features, that Morph proposing out of the >> box needs review and validation in terms, what if we isolate certain >> feature(s) in separate subclass and provide them via composition. >> > > Yes, I do think you're right. > > Simpler, "subclassable" morphs suits me a lot better. >> >> Bloc looks like its taking some of the bad aspects of Morphic. >> >> One step at a time. You cannot fix all the problems of parent at once. >> The way how Bloc born, i think (i may be mistaken), it is a 'clean and >> lean' port of Morphic. But of course Morphic is huge monster, and >> porting such monster while rewriting its complex logic at the same time >> could be daunting hard. >> In any case, i think it is better. Let us hope, it will be even better. >> > > I do hope. Certain points really require switching to Athens (sub-pixel > rendering of large fonts is extremely slow), and Bloc will be the toolkit > we'll have to live with. > > Regards, > > Thierry > > -- Best regards, Igor Stasenko.
