The Inbox: Kernel-ct.1320.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: Kernel-ct.1320.mcz

commits-2
A new version of Kernel was added to project The Inbox:
http://source.squeak.org/inbox/Kernel-ct.1320.mcz

==================== Summary ====================

Name: Kernel-ct.1320
Author: ct
Time: 22 March 2020, 8:25:11.31556 pm
UUID: d08c3179-cda9-2944-b692-9ef1b00d7742
Ancestors: Kernel-eem.1319

Proposal: Add convenience method #runSimulated to BlockClosure. While this should not be used in production, it can be helpful for exploring and testing the simulation machinery.

=============== Diff against Kernel-eem.1319 ===============

Item was added:
+ ----- Method: BlockClosure>>runSimulated (in category 'system simulation') -----
+ runSimulated
+
+ ^ Context runSimulated: self!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Kernel-ct.1320.mcz

marcel.taeumel
Hi Christoph,

you explanation would make a perfekt comment in the method you proposed. ;-) Maybe even add an example on how to use it.

Best,
Marcel

Am 22.03.2020 20:25:26 schrieb [hidden email] <[hidden email]>:

A new version of Kernel was added to project The Inbox:
http://source.squeak.org/inbox/Kernel-ct.1320.mcz

==================== Summary ====================

Name: Kernel-ct.1320
Author: ct
Time: 22 March 2020, 8:25:11.31556 pm
UUID: d08c3179-cda9-2944-b692-9ef1b00d7742
Ancestors: Kernel-eem.1319

Proposal: Add convenience method #runSimulated to BlockClosure. While this should not be used in production, it can be helpful for exploring and testing the simulation machinery.

=============== Diff against Kernel-eem.1319 ===============

Item was added:
+ ----- Method: BlockClosure>>runSimulated (in category 'system simulation') -----
+ runSimulated
+
+ ^ Context runSimulated: self!




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Kernel-ct.1320.mcz

fniephaus
In reply to this post by commits-2
Hi Christoph,

I don't want to keep you from contributing to Squeak, but I'm not sure
if adding convenience methods like this is a good idea. Why? I have
lots of such methods myself (some of them I even got from others). But
as long as they have no senders/purpose in the image, it pretty much
just means:

a) they are hard to discover and to keep up-to-date,
b) everyone has to maintain everyone's convenience methods (e.g in
case Context>>#runSimulated ever changes),
and c) at some point, we may have users relying on (the wrong) API
which should not be used in production.

I have a set of personal packages in which I keep things like this.
What do you think?

Fabio

On Sun, Mar 22, 2020 at 8:25 PM <[hidden email]> wrote:

>
> A new version of Kernel was added to project The Inbox:
> http://source.squeak.org/inbox/Kernel-ct.1320.mcz
>
> ==================== Summary ====================
>
> Name: Kernel-ct.1320
> Author: ct
> Time: 22 March 2020, 8:25:11.31556 pm
> UUID: d08c3179-cda9-2944-b692-9ef1b00d7742
> Ancestors: Kernel-eem.1319
>
> Proposal: Add convenience method #runSimulated to BlockClosure. While this should not be used in production, it can be helpful for exploring and testing the simulation machinery.
>
> =============== Diff against Kernel-eem.1319 ===============
>
> Item was added:
> + ----- Method: BlockClosure>>runSimulated (in category 'system simulation') -----
> + runSimulated
> +
> +       ^ Context runSimulated: self!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Kernel-ct.1320.mcz

Squeak - Dev mailing list
+1

/————————————————————/
For encrypted mail use [hidden email]
Get a free account at ProtonMail.com
Web: https://objectnets.net and https://objectnets.org
https://datascilv.com https://datascilv.org


On Mar 23, 2020, at 02:39, Fabio Niephaus <[hidden email]> wrote:

Hi Christoph,

I don't want to keep you from contributing to Squeak, but I'm not sure
if adding convenience methods like this is a good idea. Why? I have
lots of such methods myself (some of them I even got from others). But
as long as they have no senders/purpose in the image, it pretty much
just means:

a) they are hard to discover and to keep up-to-date,
b) everyone has to maintain everyone's convenience methods (e.g in
case Context>>#runSimulated ever changes),
and c) at some point, we may have users relying on (the wrong) API
which should not be used in production.

I have a set of personal packages in which I keep things like this.
What do you think?

Fabio

On Sun, Mar 22, 2020 at 8:25 PM <[hidden email]> wrote:

A new version of Kernel was added to project The Inbox:
http://source.squeak.org/inbox/Kernel-ct.1320.mcz

==================== Summary ====================

Name: Kernel-ct.1320
Author: ct
Time: 22 March 2020, 8:25:11.31556 pm
UUID: d08c3179-cda9-2944-b692-9ef1b00d7742
Ancestors: Kernel-eem.1319

Proposal: Add convenience method #runSimulated to BlockClosure. While this should not be used in production, it can be helpful for exploring and testing the simulation machinery.

=============== Diff against Kernel-eem.1319 ===============

Item was added:
+ ----- Method: BlockClosure>>runSimulated (in category 'system simulation') -----
+ runSimulated
+
+       ^ Context runSimulated: self!





Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Kernel-ct.1320.mcz

Christoph Thiede
In reply to this post by fniephaus

Hi Fabio,


thanks for your insights! I see your points of maintenance and understandability. But where do you draw the line between useful and abusive convenience methods? Does your opinion apply as well to #timeProfile, for example, which is also a convenience connector to a foreign domain and does not add logical value per se? I see an advantage in convenience methods like this, not only because it's literally more convenient to type them but also because they improve the explorability of the system. (I wouldn't have known the TimeProfileBrowser today if I hadn't stumbled upon #timeProfile.)


However, personal packages are a good idea. Their only disadvantage is that they make it harder to check dependencies ...


@Marcel: You're right. I should write more comments when I commit stuff :-)


Best,

Christoph



Von: Squeak-dev <[hidden email]> im Auftrag von Fabio Niephaus <[hidden email]>
Gesendet: Montag, 23. März 2020 10:39:03
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Kernel-ct.1320.mcz
 
Hi Christoph,

I don't want to keep you from contributing to Squeak, but I'm not sure
if adding convenience methods like this is a good idea. Why? I have
lots of such methods myself (some of them I even got from others). But
as long as they have no senders/purpose in the image, it pretty much
just means:

a) they are hard to discover and to keep up-to-date,
b) everyone has to maintain everyone's convenience methods (e.g in
case Context>>#runSimulated ever changes),
and c) at some point, we may have users relying on (the wrong) API
which should not be used in production.

I have a set of personal packages in which I keep things like this.
What do you think?

Fabio

On Sun, Mar 22, 2020 at 8:25 PM <[hidden email]> wrote:
>
> A new version of Kernel was added to project The Inbox:
> http://source.squeak.org/inbox/Kernel-ct.1320.mcz
>
> ==================== Summary ====================
>
> Name: Kernel-ct.1320
> Author: ct
> Time: 22 March 2020, 8:25:11.31556 pm
> UUID: d08c3179-cda9-2944-b692-9ef1b00d7742
> Ancestors: Kernel-eem.1319
>
> Proposal: Add convenience method #runSimulated to BlockClosure. While this should not be used in production, it can be helpful for exploring and testing the simulation machinery.
>
> =============== Diff against Kernel-eem.1319 ===============
>
> Item was added:
> + ----- Method: BlockClosure>>runSimulated (in category 'system simulation') -----
> + runSimulated
> +
> +       ^ Context runSimulated: self!
>
>



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Kernel-ct.1320.mcz

Stéphane Rollandin
> However, personal packages are a good idea. Their only disadvantage is
> that they make it harder to check dependencies ...

You can also think of this as an advantage: it forces you to reckon
that, as a core developer, you will never see all the code that exists,
and so that you can never be certain to have sorted out all dependencies...

I am writing this as someone who has updated its code base through each
Squeak release since 3.8 - it has been rocky at times, even with core
developers deeply caring about backward compatibility. Some of the
Morphic refactorings in trunk made me struggle quite a bit, although
they were well designed. Their authors just could not know all the
dependencies that exist in the outside world.

As of today, my own personal package has about 1000 convenience methods.
Overall in my working image I have about 300000 lines of code over
around 35000 methods, spread all over the system because I see Squeak as
the Dynabook and play with about everthing I like there (which is,
almost everything :).

Best,

Stef