Smalltalk › Pharo › Pharo Smalltalk Developers

call for cleaning ideas around Spec

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

52 messages Options

123

Denis Kudriashov

Re: call for cleaning ideas around Spec

Hi.

I have maybe stupid question. Why Spec needs SpecInterpreter? If I understand correctly it purpose is to parse literal array and create morphs from it. Is it true?

If yes then why Spec not uses general literal array parser? (there is one which was born from old discussion about external formats http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals)

2016-05-04 8:19 GMT+02:00 stepharo <[hidden email]>:

Hi guys

this afternoon we will have a meeting with Peter and others to talk about cleaning Spec API.

If you want/can join let us know

else we can organise another skype.

if you have ideas let us know too.

Stef

Peter Uhnak

Re: call for cleaning ideas around Spec

On Mon, May 9, 2016 at 11:02 AM, Denis Kudriashov <[hidden email]> wrote:

Hi.

I have maybe stupid question. Why Spec needs SpecInterpreter? If I understand correctly it purpose is to parse literal array and create morphs from it. Is it true?
If yes then why Spec not uses general literal array parser? (there is one which was born from old discussion about external formats http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals)

No. Morphs are created by Adapters, Spec interpreter instantiates glues everything together.

Regardless, there's no parsing involved… what is there to parse? There are no literal arrays anywhere.

The SpecLayout (that we called array last week), is not an array, it's a composition of real objects

defaultSpec

^ SpecLayout composed

newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] ]

height: self toolbarHeight;

newRow: [ :row |

row

newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ 1;

addSplitter;

newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ 1;

addSplitter;

newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ]

top: self toolbarHeight;

yourself

Peter

2016-05-04 8:19 GMT+02:00 stepharo <[hidden email]>:
Hi guys

this afternoon we will have a meeting with Peter and others to talk about cleaning Spec API.

If you want/can join let us know

else we can organise another skype.

if you have ideas let us know too.

Stef

Denis Kudriashov

Re: call for cleaning ideas around Spec

2016-05-09 11:38 GMT+02:00 Peter Uhnák <[hidden email]>:

No. Morphs are created by Adapters, Spec interpreter instantiates glues everything together.
Regardless, there's no parsing involved… what is there to parse? There are no literal arrays anywhere.
The SpecLayout (that we called array last week), is not an array, it's a composition of real objects

defaultSpec
^ SpecLayout composed
newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] ]
height: self toolbarHeight;
newRow: [ :row |
row
newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ 1;
addSplitter;
newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ 1;
addSplitter;
newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ]
top: self toolbarHeight;
yourself

Maybe array approach deprecated? But in first demos of Spec it was like this:

CheckBoxExample class>>defaultSpec

^ { #ContainerModel.

#add:. { self topSpec. #layout:. #(#SpecLayoutFrame

bottomFraction: 0

bottomOffset: 20) }.

#add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) }

}

(Actually it is from Pharo 5 image).

Peter Uhnak

Re: call for cleaning ideas around Spec

On Mon, May 9, 2016 at 1:22 PM, Denis Kudriashov <[hidden email]> wrote:

2016-05-09 11:38 GMT+02:00 Peter Uhnák <[hidden email]>:
No. Morphs are created by Adapters, Spec interpreter instantiates glues everything together.
Regardless, there's no parsing involved… what is there to parse? There are no literal arrays anywhere.
The SpecLayout (that we called array last week), is not an array, it's a composition of real objects

defaultSpec
^ SpecLayout composed
newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] ]
height: self toolbarHeight;
newRow: [ :row |
row
newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ 1;
addSplitter;
newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ 1;
addSplitter;
newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ]
top: self toolbarHeight;
yourself

Maybe array approach deprecated? But in first demos of Spec it was like this:

CheckBoxExample class>>defaultSpec

^ { #ContainerModel.
#add:. { self topSpec. #layout:. #(#SpecLayoutFrame
bottomFraction: 0
bottomOffset: 20) }.
#add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) }
}

(Actually it is from Pharo 5 image).

Wow, this is ugly. I like the real "self topSpec" call in the middle of it. :)

But even then, this is still a regular Pharo (dynamic) array, so no need to parse it… but don't use it like this. :)

Peter

Denis Kudriashov

Re: call for cleaning ideas around Spec

2016-05-09 13:37 GMT+02:00 Peter Uhnák <[hidden email]>:

Wow, this is ugly. I like the real "self topSpec" call in the middle of it. :)

But even then, this is still a regular Pharo (dynamic) array, so no need to parse it… but don't use it like this. :)

By parsing array I mean converting array into underlying object.

Henrik Sperre Johansen

Re: call for cleaning ideas around Spec

In reply to this post by Denis Kudriashov

Yes, IIRC, the whole idea behind Spec was to have a literal syntax for specifying UI's. (Which is a neat storage format for, say, a UIBuilder)

The focus seems to have changed over time to directly using what was initially the intermediate object model the builder generated when parsing the spec.

Cheers,

Henry

On 09 May 2016, at 1:22 , Denis Kudriashov <[hidden email]> wrote:

2016-05-09 11:38 GMT+02:00 Peter Uhnák <[hidden email]>:
No. Morphs are created by Adapters, Spec interpreter instantiates glues everything together.
Regardless, there's no parsing involved… what is there to parse? There are no literal arrays anywhere.
The SpecLayout (that we called array last week), is not an array, it's a composition of real objects

defaultSpec
^ SpecLayout composed
newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] ]
height: self toolbarHeight;
newRow: [ :row |
row
newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ 1;
addSplitter;
newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ 1;
addSplitter;
newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ]
top: self toolbarHeight;
yourself

Maybe array approach deprecated? But in first demos of Spec it was like this:

CheckBoxExample class>>defaultSpec

^ { #ContainerModel.
#add:. { self topSpec. #layout:. #(#SpecLayoutFrame
bottomFraction: 0
bottomOffset: 20) }.
#add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) }
}

(Actually it is from Pharo 5 image).

signature.asc (859 bytes) Download Attachment

Peter Uhnak

Re: call for cleaning ideas around Spec

(Which is a neat storage format for, say, a UIBuilder)

When you don't touch it, you don't care about it.

The focus seems to have changed over time to directly using what was initially the intermediate object model the builder generated when parsing the spec.

I guess because it's written by hand… I mean the array looks like bad attempt at STON.

In any case, we can always introduce a proper DSL for layout later (or even better, have a UI builder!). Right now it's written with the spec layout.

Peter

EstebanLM

Re: call for cleaning ideas around Spec

In reply to this post by Henrik Sperre Johansen

On 09 May 2016, at 13:45, Henrik Johansen <[hidden email]> wrote:

Yes, IIRC, the whole idea behind Spec was to have a literal syntax for specifying UI's. (Which is a neat storage format for, say, a UIBuilder)
The focus seems to have changed over time to directly using what was initially the intermediate object model the builder generated when parsing the spec.

btw, I’ve never been happy with that change :)

and I agree, the original idea was to have some s-strings based description so an UI builder (to be done) could do a better job.

Esteban

Cheers,
Henry

On 09 May 2016, at 1:22 , Denis Kudriashov <[hidden email]> wrote:

2016-05-09 11:38 GMT+02:00 Peter Uhnák <[hidden email]>:
No. Morphs are created by Adapters, Spec interpreter instantiates glues everything together.
Regardless, there's no parsing involved… what is there to parse? There are no literal arrays anywhere.
The SpecLayout (that we called array last week), is not an array, it's a composition of real objects

defaultSpec
^ SpecLayout composed
newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] ]
height: self toolbarHeight;
newRow: [ :row |
row
newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ 1;
addSplitter;
newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ 1;
addSplitter;
newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ]
top: self toolbarHeight;
yourself

Maybe array approach deprecated? But in first demos of Spec it was like this:

CheckBoxExample class>>defaultSpec

^ { #ContainerModel.
#add:. { self topSpec. #layout:. #(#SpecLayoutFrame
bottomFraction: 0
bottomOffset: 20) }.
#add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) }
}

(Actually it is from Pharo 5 image).

Henrik Sperre Johansen

Re: call for cleaning ideas around Spec

In reply to this post by Peter Uhnak

On 09 May 2016, at 1:53 , Peter Uhnák <[hidden email]> wrote:

(Which is a neat storage format for, say, a UIBuilder)

When you don't touch it, you don't care about it.

The focus seems to have changed over time to directly using what was initially the intermediate object model the builder generated when parsing the spec.

I guess because it's written by hand… I mean the array looks like bad attempt at STON.

In any case, we can always introduce a proper DSL for layout later (or even better, have a UI builder!). Right now it's written with the spec layout.

Peter

Uhuh, in my mind, it seemed to get off to a kind of shaky start, and never improved.

Rather than take the opportunity to design a more generic object model for widgets with a clear strategy in mind for mapping to a literal syntax, it seemed to me to have started by copy-pasting the entire API used by Morphic widgets, adding Spec in front of some of the class names, and call it a day.

Slap some {}'s around where appropriate, and you have a literal syntax!

The good news is, no-one in their right mind would willingly use the literal format as is, so changing it probably wouldn't cause too much of an uproar,

the bad new is, all the hard work involved in creating a sensical format, still remains.

It's also rather hard to make a good object model that you then later graft a literal format on top of...

For instance, with the use of blocks for everything, and the weird mix of symbols and method calls:

row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ]

I'd have no idea how to represent as a literal in an intuitive way.

Cheers,

Henry

signature.asc (859 bytes) Download Attachment

stepharo

Re: call for cleaning ideas around Spec

In reply to this post by EstebanLM

Yes :)

On 09 May 2016, at 13:45, Henrik Johansen <[hidden email]> wrote:

Yes, IIRC, the whole idea behind Spec was to have a literal syntax for specifying UI's. (Which is a neat storage format for, say, a UIBuilder)

The focus seems to have changed over time to directly using what was initially the intermediate object model the builder generated when parsing the spec.

btw, I’ve never been happy with that change :)
and I agree, the original idea was to have some s-strings based description so an UI builder (to be done) could do a better job.

Esteban

Cheers,

Henry

On 09 May 2016, at 1:22 , Denis Kudriashov <[hidden email]> wrote:

2016-05-09 11:38 GMT+02:00 Peter Uhnák <[hidden email]>:

No. Morphs are created by Adapters, Spec interpreter instantiates glues everything together.

Regardless, there's no parsing involved… what is there to parse? There are no literal arrays anywhere.

The SpecLayout (that we called array last week), is not an array, it's a composition of real objects

defaultSpec

^ SpecLayout composed

newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] ]

height: self toolbarHeight;

newRow: [ :row |

row

newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ 1;

addSplitter;

newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ 1;

addSplitter;

newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ]

top: self toolbarHeight;

yourself

Maybe array approach deprecated? But in first demos of Spec it was like this:

CheckBoxExample class>>defaultSpec

^ { #ContainerModel.

#add:. { self topSpec. #layout:. #(#SpecLayoutFrame

bottomFraction: 0

bottomOffset: 20) }.

#add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) }

}

(Actually it is from Pharo 5 image).

stepharo

Re: call for cleaning ideas around Spec

In reply to this post by Denis Kudriashov

Denis this is the same.

at the end we get an array and from this array we should get widgets.

Stef

Le 9/5/16 à 13:22, Denis Kudriashov a écrit :

2016-05-09 11:38 GMT+02:00 Peter Uhnák <[hidden email]>:

No. Morphs are created by Adapters, Spec interpreter instantiates glues everything together.

Regardless, there's no parsing involved… what is there to parse? There are no literal arrays anywhere.

The SpecLayout (that we called array last week), is not an array, it's a composition of real objects

defaultSpec

^ SpecLayout composed

newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] ]

height: self toolbarHeight;

newRow: [ :row |

row

newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ 1;

addSplitter;

newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ 1;

addSplitter;

newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ]

top: self toolbarHeight;

yourself

Maybe array approach deprecated? But in first demos of Spec it was like this:

CheckBoxExample class>>defaultSpec

^ { #ContainerModel.

#add:. { self topSpec. #layout:. #(#SpecLayoutFrame

bottomFraction: 0

bottomOffset: 20) }.

#add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) }

}

(Actually it is from Pharo 5 image).

stepharo

Re: call for cleaning ideas around Spec

In reply to this post by Henrik Sperre Johansen

Since the array is recursively performing its nested elements the
expression

row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ]

was probably to get

#columSpec

addHeight: #(itemSpec topToolBar #toolbarheight)

which would lead to

aColumn perform: addHeight

withArguments: (anItemSpec perform: topToolBar
with: (model/presenter toolbarheight)

The trick is to see who should be the receiver

In visualWorks a windowSpec contains only literals like in Spec and I do
not know how they can make such difference.
Stef

123