On 02 Jan 2014, at 14:40, Tudor Girba <[email protected]> wrote: > Hi Stef, > > Glamour does not overuse blocks any more than any caller to cull: does it. > And if you look closely now, you will see that the amount of arguments have > decreased significantly
good to know > (you do not have to repeat the objects that are passed in by the transmission > for every block). But, blocks are not essential in Glamour (and especially, > if it really is a problem, we can enforce the arguments). I just showed how > you can simply not use blocks at all for specifying widgets. So, my argument > is that this "blocks worry" isn't truly justified. And I also showed how Spec > takes a similar approach for scripting, but you do not see Spec as having the > same problem. I hope that we will remove the block from spec too. Because with a ui builder you do not want to generate script but plain data. > > I am a bit troubled by your remark that the component model is not plain > Smalltalk. The component model has nothing to do with the blocks and it is > formed by plain objects: > http://www.themoosebook.org/book/internals/glamour/architecture In Smalltalk I have objects and messages not ports/connectors and propagation. > Could you explain? > > (please note that I am not picking up a fight ok > - I would just want to understand how people see these things) > > Doru > > > > > On Thu, Jan 2, 2014 at 2:13 PM, Stéphane Ducasse <[email protected]> > wrote: > Doru > > You know well that Glamour has a component model that it not plain smalltalk > model. So why are you telling me I do not know what? > Now you also know that Glamour overuse blocks with multiple optional block > arguments where the order is important. > So I do not undersand why you are saying that. > > Stef > >> >> Interesting comparison. It sounds to me as if this "component model" is a >> bad thing and that VW is a gold standard when it comes to describing user >> interfaces. Also, when you say DSL you refer to the way the Smalltalk API >> was design to read like sentences, which might sound like it goes against >> the tradition of Smalltalk. As for blocks, some would go as far as >> considering them to be plain Smalltalk :). >> >> I think a more detailed comparison would be more useful for newcomers. So, >> here is one. >> >> First, the block issue. The funny thing is that if you want to build a >> dynamic browser with Spec you have to rely on blocks, too. Take a look at an >> example from Ben: >> >> --- >> m := DynamicComposableModel new. >> m instantiateModels: #( button ButtonModel list ListModel). >> m list items: #(1 2 3 4 5). >> m button >> label: 'Plip'; >> action: [ self halt ]. >> m openWithSpecLayout: (SpecLayout composed >> newColumn: [: c | c add: #list ; add: #button height: 26 ]; >> yourself). >> --- >> >> Glamour is actually written in plain Smalltalk, and you can simply use >> subclassing, too. >> >> For example, something like this: >> GLMCompositePresentation new >> with: [ :a | >> a list >> display: [ :input | 1 to: input ]; >> act: [ :list | self halt ] entitled: 'Plip' ]; >> openOn: 42 >> >> Could be done like this: >> >> >> >> "Define a list presentation with an action in distinct classes to make >> blocks disappear" >> GLMGenericAction subclass: #MyPlipAction >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'AAA'. >> GLMListPresentation subclass: #MyListPresentation >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'AAA'. >> MyListPresentation compile: >> 'displayValue >> ^ 1 to: self entity'. >> MyListPresentation compile: >> 'actions >> ^ {MyPlipAction new}'. >> MyPlipAction compile: >> 'actOn: aPresentation >> self halt'. >> MyPlipAction compile: >> 'title >> ^ ''Plip'''. >> >> "Use the list" >> composite := GLMCompositePresentation new. >> composite add: (MyListPresentation new). >> composite openOn: 42. >> >> >> I doubt the blocks are an actual issue. Using blocks has the advantage of >> more compact code, but it is true that it comes with a price: when you store >> the block you cannot edit its code live while debugging (you actually can do >> that, too if you take care). >> >> The main difference between Spec and Glamour is actually conceptual: the >> application space. Spec addresses widgets: with Spec you place widgets on a >> "canvas" and handle the interaction. So, in a sense, this places Spec at the >> same level as Morphic. Glamour is at a higher level and it is specifically >> dedicated to supporting browsing workflows. In its current state, it is not >> useful for laying out widgets, but it can be very concise for expressing >> browsers. >> >> The way this works is via this "component model". Essentially, a browser can >> be described as a set of components that can pass data to each other. >> Glamour lets you model that. >> >> It so happens that the inspector and the debugger are browsers and can be >> expressed at that level. It also so happens that most user interfaces that >> programmers use can be expressed as browsers, too. And Glamour was actually >> validated for hundreds of various browsers (literally), so it seems it can >> support a large set of use cases. >> >> If you want to learn more about Glamour you can read the chapters from: >> - http://deepintopharo.org, or >> - http://www.themoosebook.org/book/internals/glamour >> >> If you want to see where Glamour fits within Moose, you can read this post: >> http://www.humane-assessment.com/blog/moose-custom-analyses-made-easy >> >> Doru >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"
