I think that one example Stef has in mind, is the following:
GLMCompositePresentation new
with: [ :a |
a list
display: [ :input | 1 to: input ];
act: [ :list | self halt ] entitled: 'Plip' ];
openOn: 42
what is “a” ? How one should know that “a” answer to #list ? And that the
result understand #display: and #act:
Removing block, could be something like:
GLMCompositePresentation new
add: (ListPresenter new
display: [ :input | 1 to: input ] … )
Alexandre
On Jan 2, 2014, at 10:40 AM, 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 (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 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
>
> Could you explain?
>
> (please note that I am not picking up a fight - 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"
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
