#milliseconds versus #milliSeconds
Using Finder, the majority representation in the image appears to be all-lowercase #milliseconds with only a few #milliSeconds. Googling indicates the former is usual. Is it worth logging a ticket for Pharo 5 to make the latter consistent? cheers -ben
I last added a couple of methods to Duration (#whole[Micro|Milli|Nano]seconds) and chose the lower case option, which is the normal one in the larger world, as far as I understand it. Yes, maybe this could be made more consistent in Pharo 5, but it is of course again a case of lots of pain for little gain ;-)
On 03 Mar 2015, at 14:31, Ben Coman <btc@openInWorld.com> wrote:
Using Finder, the majority representation in the image appears to be all-lowercase #milliseconds with only a few #milliSeconds. Googling indicates the former is usual. Is it worth logging a ticket for Pharo 5 to make the latter consistent?
cheers -ben
Sven Van Caekenberghe-2 wrote
Yes, maybe this could be made more consistent in Pharo 5, but it is of course again a case of lots of pain for little gain ;-)
I definitely recall feeling "lots of pain" with the subStringXyz -> substringXyz that we're still dealing with in recent updates (I think I started that push as a naive newbie), but I'm not sure about the "little gain" part. It's hard to quantify the negative effect of inconsistency in the system, or the empowering effect of uniformity. There's the practical "was /this/ case the milliS or the millis??", as well as the more subtle effect of a calm, happy feeling users may get from a system in which the little details have been cared for. IMNSHO: Fix all these little things now while so many changes are swirling around the system. The longer we wait, the more mature/widely-used Pharo gets, the less practical these changes will become ----- Cheers, Sean -- View this message in context: http://forum.world.st/milliseconds-versus-milliSeconds-tp4809142p4809151.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 03 Mar 2015, at 14:37, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
Yes, maybe this could be made more consistent in Pharo 5, but it is of course again a case of lots of pain for little gain ;-)
I definitely recall feeling "lots of pain" with the subStringXyz -> substringXyz that we're still dealing with in recent updates (I think I started that push as a naive newbie), but I'm not sure about the "little gain" part. It's hard to quantify the negative effect of inconsistency in the system, or the empowering effect of uniformity. There's the practical "was /this/ case the milliS or the millis??", as well as the more subtle effect of a calm, happy feeling users may get from a system in which the little details have been cared for.
IMNSHO: Fix all these little things now while so many changes are swirling around the system. The longer we wait, the more mature/widely-used Pharo gets, the less practical these changes will become
I agree, but the recent #subStrings: to #substrings: forced me to add another package with one method to make Zinc work in Pharo 2, 3 and 4 (after I managed to convince others to make a change to pharo 3 too). There *is* pain in those external codebases trying to target multiple versions.
On 03 Mar 2015, at 14:52, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Mar 2015, at 14:37, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
Yes, maybe this could be made more consistent in Pharo 5, but it is of course again a case of lots of pain for little gain ;-)
I definitely recall feeling "lots of pain" with the subStringXyz -> substringXyz that we're still dealing with in recent updates (I think I started that push as a naive newbie), but I'm not sure about the "little gain" part. It's hard to quantify the negative effect of inconsistency in the system, or the empowering effect of uniformity. There's the practical "was /this/ case the milliS or the millis??", as well as the more subtle effect of a calm, happy feeling users may get from a system in which the little details have been cared for.
IMNSHO: Fix all these little things now while so many changes are swirling around the system. The longer we wait, the more mature/widely-used Pharo gets, the less practical these changes will become
I agree, but the recent #subStrings: to #substrings: forced me to add another package with one method to make Zinc work in Pharo 2, 3 and 4 (after I managed to convince others to make a change to pharo 3 too).
There *is* pain in those external codebases trying to target multiple versions.
I said this already: we can not be backward compatible forever. There needs to be a cutoff. For me is is that we support one version back. We could do 2 versions. But there *has* to be a defined point in the past where we do not care anymore. Marcus
On Tue, Mar 3, 2015 at 9:37 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
Yes, maybe this could be made more consistent in Pharo 5, but it is of course again a case of lots of pain for little gain ;-)
#milliSeconds has caused me aLittleBitOfPain a dozen times today. Delay uses milliseconds and I've come to intrinsically expect to type it all lowercase. It only takes 5 seconds to correct, but in accumulation, its annoying. On Tue, Mar 3, 2015 at 9:52 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I agree, but the recent #subStrings: to #substrings: forced me to add another package with one method to make Zinc work in Pharo 2, 3 and 4 (after I managed to convince others to make a change to pharo 3 too).
There *is* pain in those external codebases trying to target multiple versions.
For a simple method rename like this we should be able to push the new names into the old releases. On Tue, Mar 3, 2015 at 9:54 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
I said this already: we can not be backward compatible forever. There needs to be a cutoff. For me is is that we support one version back. We could do 2 versions. But there *has* to be a defined point in the past where we do not care anymore.
You could do "staged" reduction in support. Back one version might get general bug fixes. Back two or more versions might only get cleanup method renames. Now the idea with pushing method renames back is that its not just about backward support, but about showing people the way forward, and also about reducing friction to make such cleanup changes. Would it be feasible to have a community maintained PharoForwardCompatability package available in the ConfigurationBrowser that is generally available for everyone to use, rather than everyone needing to roll their own? Maybe this is even something that Grease etc might reference?
I definitely recall feeling "lots of pain" with the subStringXyz -> substringXyz that we're still dealing with in recent updates (I think I started that push as a naive newbie), but I'm not sure about the "little gain" part. It's hard to quantify the negative effect of inconsistency in the system, or the empowering effect of uniformity. There's the practical "was /this/ case the milliS or the millis??", as well as the more subtle effect of a calm, happy feeling users may get from a system in which the little details have been cared for.
IMNSHO: Fix all these little things now while so many changes are swirling around the system. The longer we wait, the more mature/widely-used Pharo gets, the less practical these changes will become
I agree with Sean's sentiment - consistency cannot be underestimated, and its better to take the hit now while the community is smaller. cheers -ben
On 03 Mar 2015, at 15:25, Ben Coman <btc@openInWorld.com> wrote:
You could do "staged" reduction in support. Back one version might get general bug fixes. Back two or more versions might only get cleanup method renames. Now the idea with pushing method renames back is that its not just about backward support, but about showing people the way forward, and also about reducing friction to make such cleanup changes.
Would it be feasible to have a community maintained PharoForwardCompatability package available in the ConfigurationBrowser that is generally available for everyone to use, rather than everyone needing to roll their own? Maybe this is even something that Grease etc might reference?
Yes, yes, yes ! I am all for the renaming, but with some backward support like you describe. Like you say, it is very, very simple. It is a simple service to all external packages, instead of letting each of them solve it on their own. And no, for everything else this is *not* needed.
Ben Coman wrote
Would it be feasible to have a community maintained PharoForwardCompatability package available in the ConfigurationBrowser that is generally available for everyone to use
Great idea! If we're just talking about renames, it could just be pre-loaded, no? ----- Cheers, Sean -- View this message in context: http://forum.world.st/milliseconds-versus-milliSeconds-tp4809142p4809198.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Tue, Mar 3, 2015 at 10:40 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Ben Coman wrote
Would it be feasible to have a community maintained PharoForwardCompatability package available in the ConfigurationBrowser that is generally available for everyone to use
Great idea! If we're just talking about renames, it could just be pre-loaded, no?
Ideally these sort of renames would be pushed back to all previous Releases, but that seems not feasible resource-wise. Its a question of ALL actions required do a point-release of those older versions, and how often you are able to do that. There is also the temptation that with a point-Release, people will pressure to add "just one more" thing that might not be a "simple rename" . An additional benefit of it being a Configuration loaded external onto the older Releases is that people can see the changes, which is a big tip for which parts of their code the should update for it to work in a later version. Also because people using the package can see the "simple" changes, there doesn't need to be as much rigor adding stuff to it - so it can be more community driven. Also its more dynamic - for example if this change is made early in Pharo 5, the Pharo 4 projects can already include it and be already adapting. Because you want to minimise the point releases of the older versions, you would otherwise need to wait a whole year for the Pharo 5 Release to lock down all required "renames" to back propagate. cheers -ben
2015-03-03 16:06 GMT+01:00 Ben Coman <btc@openinworld.com>:
On Tue, Mar 3, 2015 at 10:40 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Ben Coman wrote
Would it be feasible to have a community maintained PharoForwardCompatability package available in the ConfigurationBrowser that is generally available for everyone to use
Great idea! If we're just talking about renames, it could just be pre-loaded, no?
Ideally these sort of renames would be pushed back to all previous Releases, but that seems not feasible resource-wise. Its a question of ALL actions required do a point-release of those older versions, and how often you are able to do that. There is also the temptation that with a point-Release, people will pressure to add "just one more" thing that might not be a "simple rename" .
An additional benefit of it being a Configuration loaded external onto the older Releases is that people can see the changes, which is a big tip for which parts of their code the should update for it to work in a later version.
Ben, I like your idea. It would allow stable-based additional packages to include the . configuration as a pre-requisite (and as such make the manager of that package aware that it has a version working on the .1 or the .2 version). For example, I could have a SmaCC v2.0.3 for Pharo3.0, a SmaCC v2.0.3.1 requiring ConfigurationOfPharo3.1, and switch my #stable to v2.0.3.1 (for example) any time after ConfigurationOfPharo3.1 became available. The strong point is: if I don't see the need, then my SmaCC will stay at v2.0.3 for Pharo3, and will keep working even if ConfigurationOfPharo3.1 makes obsolete a key API I do use, since, by default, pharo users will download the 3.0 image. ConfigurationOfPharo3.1 should change the platform tag to #pharo3.1. To avoid that someone updates his image to 3.1, load my SmaCC planned for 3.0, and encounter errors that I don't want to handle (yet).
Also because people using the package can see the "simple" changes, there doesn't need to be as much rigor adding stuff to it - so it can be more community driven. Also its more dynamic - for example if this change is made early in Pharo 5, the Pharo 4 projects can already include it and be already adapting. Because you want to minimise the point releases of the older versions, you would otherwise need to wait a whole year for the Pharo 5 Release to lock down all required "renames" to back propagate.
Also, one of the points of that scheme is that those additional packages are entirely optionals: by default, there is no point release. Or, if we need the possibility to have a point release of Pharo in the stable cycle, we can call the point release .0.X (and have the platform naming follow suit). Example: Pharo3.0 released. (#pharo3.0.0) ConfigurationOfPharo3.1 released (#pharo3.1.0) ConfigurationOfPharo3.2 released (#pharo3.2.0) ConfigurationOfPharo3.3 released Pharo3.0.1 released with bugfixes (say it is judged necessary) but no API change. (#pharo3.0.1) ConfigurationOfPharo3.4 released etc... Approach being: 3.0.x is supposed to maintain a stable api (no change needed for external packages) 3.X is optional and mark/prepare changes for 4.0 How hard it would be to keep the Monkey checking on past versions of Pharo? Can I provide a SLICE for Pharo3 now and the monkey is able to say if it passes or not? I haven't tried. Thierry
On Tue, Mar 3, 2015 at 11:36 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-03-03 16:06 GMT+01:00 Ben Coman <btc@openinworld.com>:
On Tue, Mar 3, 2015 at 10:40 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Ben Coman wrote
Would it be feasible to have a community maintained PharoForwardCompatability package available in the ConfigurationBrowser that is generally available for everyone to use
Great idea! If we're just talking about renames, it could just be pre-loaded, no?
Ideally these sort of renames would be pushed back to all previous Releases, but that seems not feasible resource-wise. Its a question of ALL actions required do a point-release of those older versions, and how often you are able to do that. There is also the temptation that with a point-Release, people will pressure to add "just one more" thing that might not be a "simple rename" .
An additional benefit of it being a Configuration loaded external onto the older Releases is that people can see the changes, which is a big tip for which parts of their code the should update for it to work in a later version.
Ben, I like your idea.
It would allow stable-based additional packages to include the . configuration as a pre-requisite (and as such make the manager of that package aware that it has a version working on the .1 or the .2 version).
For example, I could have a SmaCC v2.0.3 for Pharo3.0, a SmaCC v2.0.3.1 requiring ConfigurationOfPharo3.1, and switch my #stable to v2.0.3.1 (for example) any time after ConfigurationOfPharo3.1 became available.
My idea might have merit to do point releases of PharoX.x, but I think the semantics of that are broader and likely a bigger effort than what I was considering, which was having a ConfigurationOfPharoForwardCompatability. cheers -ben
2015-03-03 17:00 GMT+01:00 Ben Coman <btc@openinworld.com>:
On Tue, Mar 3, 2015 at 11:36 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2015-03-03 16:06 GMT+01:00 Ben Coman <btc@openinworld.com>:
On Tue, Mar 3, 2015 at 10:40 PM, Sean P. DeNigris <sean@clipperadams.com
wrote:
Ben Coman wrote
Would it be feasible to have a community maintained PharoForwardCompatability package available in the ConfigurationBrowser that is generally available for everyone to use
Great idea! If we're just talking about renames, it could just be pre-loaded, no?
Ideally these sort of renames would be pushed back to all previous Releases, but that seems not feasible resource-wise. Its a question of ALL actions required do a point-release of those older versions, and how often you are able to do that. There is also the temptation that with a point-Release, people will pressure to add "just one more" thing that might not be a "simple rename" .
An additional benefit of it being a Configuration loaded external onto the older Releases is that people can see the changes, which is a big tip for which parts of their code the should update for it to work in a later version.
Ben, I like your idea.
It would allow stable-based additional packages to include the . configuration as a pre-requisite (and as such make the manager of that package aware that it has a version working on the .1 or the .2 version).
For example, I could have a SmaCC v2.0.3 for Pharo3.0, a SmaCC v2.0.3.1 requiring ConfigurationOfPharo3.1, and switch my #stable to v2.0.3.1 (for example) any time after ConfigurationOfPharo3.1 became available.
My idea might have merit to do point releases of PharoX.x, but I think the semantics of that are broader and likely a bigger effort than what I was considering, which was having a ConfigurationOfPharoForwardCompatability.
But my ConfigurationOfPharo3.X are your ConfigurationOfPharoForwardCompatability. They are just numbered so that they can be relied on for deployment of large packages (and they manipulate a bit the platform so that everything works properly, that's all). Point releases of Pharo are optional. Thierry
On 03/03/15 14:37, Sean P. DeNigris wrote:
I definitely recall feeling "lots of pain" with the subStringXyz -> substringXyz that we're still dealing with in recent updates (I think I started that push as a naive newbie), but I'm not sure about the "little gain" part. It's hard to quantify the negative effect of inconsistency in the system, or the empowering effect of uniformity.
These kind of changes should be accompanied by a rewrite script, b.t.w. Upgrading is much easier if you can just select the rewrites you want to apply. Stephan
Le 3/3/15 22:37, Stephan Eggermont a écrit :
On 03/03/15 14:37, Sean P. DeNigris wrote:
I definitely recall feeling "lots of pain" with the subStringXyz -> substringXyz that we're still dealing with in recent updates (I think I started that push as a naive newbie), but I'm not sure about the "little gain" part. It's hard to quantify the negative effect of inconsistency in the system, or the empowering effect of uniformity.
These kind of changes should be accompanied by a rewrite script, b.t.w. Upgrading is much easier if you can just select the rewrites you want to apply.
I do not know if you know but there is a support for automatically rewriting deprecated methods :) It is there but is not used.
Stephan
On 13/03/15 18:01, stepharo wrote:(in Re: #milliseconds versus #milliSeconds)
Le 3/3/15 22:37, Stephan Eggermont a écrit :
On 03/03/15 14:37, Sean P. DeNigris wrote:
I definitely recall feeling "lots of pain" with the subStringXyz -> substringXyz that we're still dealing with in recent updates (I think I started that push as a naive newbie), but I'm not sure about the "little gain" part. It's hard to quantify the negative effect of inconsistency in the system, or the empowering effect of uniformity.
These kind of changes should be accompanied by a rewrite script, b.t.w. Upgrading is much easier if you can just select the rewrites you want to apply.
I do not know if you know but there is a support for automatically rewriting deprecated methods :) It is there but is not used.
Nice. Looks like more deprecations should be done that way. What would be needed to make that fit in the CI workflow well? Stephan
I do not know if you know but there is a support for automatically rewriting deprecated methods :) It is there but is not used.
Nice. Looks like more deprecations should be done that way. What would be needed to make that fit in the CI workflow well? I do not know. Now what would be good is to use this mecanism and learn.
Stef
On 14 Mar 2015, at 14:12, stepharo <stepharo@free.fr> wrote:
I do not know if you know but there is a support for automatically rewriting deprecated methods :) It is there but is not used.
Nice. Looks like more deprecations should be done that way. What would be needed to make that fit in the CI workflow well? I do not know. Now what would be good is to use this mecanism and learn.
Itâs a small proof-of-concept I did last summer. It should work but it has never been used seriously so it needs some love. To try it: Gofer it smalltalkhubUser: 'CamilleTeruel' project: 'Deprecator'; package: 'Deprecator'; load Camille
Stef
On 14 Mar 2015, at 22:21, Camille <camille.teruel@gmail.com> wrote:
On 14 Mar 2015, at 14:12, stepharo <stepharo@free.fr> wrote:
I do not know if you know but there is a support for automatically rewriting deprecated methods :) It is there but is not used.
Nice. Looks like more deprecations should be done that way. What would be needed to make that fit in the CI workflow well? I do not know. Now what would be good is to use this mecanism and learn.
Itâs a small proof-of-concept I did last summer. It should work but it has never been used seriously so it needs some love. To try it:
Gofer it smalltalkhubUser: 'CamilleTeruel' project: 'Deprecator'; package: 'Deprecator'; load
We should add that to Pharo5 and start to use it then. Marcus
definitively and we should have deprecated methods. Le 3/3/15 14:31, Ben Coman a écrit :
Using Finder, the majority representation in the image appears to be all-lowercase #milliseconds with only a few #milliSeconds. Googling indicates the former is usual. Is it worth logging a ticket for Pharo 5 to make the latter consistent?
cheers -ben
participants (8)
-
Ben Coman -
Camille -
Marcus Denker -
Sean P. DeNigris -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier