The Inbox: Kernel-ct.1320.mcz
Locked
 
|
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! |
Re: The Inbox: Kernel-ct.1320.mcz
|
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
|
|
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! > > |
Re: The Inbox: Kernel-ct.1320.mcz
|
|
+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:
|
Re: The Inbox: Kernel-ct.1320.mcz
|
|
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! > >
Carpe Squeak!
|
Re: The Inbox: Kernel-ct.1320.mcz
|
|
> 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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |