[Pharo-project] Filesystem onDisk and inMemory are renamed in 1.4
Hi, Filesystem is part of the Pharo 1.4 image and the code resides in the Pharo 1.4 repository. Essentially, as Lukas pointed out, this is a fork. There is absolutely nothing wrong with that, especially if you want to base the core on it. However, the problem is what happens with the changes. Do they flow back to the original author, or do you want to fork completely? Of course, a collaboration requires at least two parties to work together :), but it would still be cool to get the position clear. Of course, some changes are internal and they have little impact on the end user, but sometimes the public interface changes, too, and that is more problematic. Case in point are the onDisk and inMemory methods which were renamed to disk and memory, respectively. This basically breaks any previous code that is using Filesystem. Is there a particular reason for doing this (the original names seem perfectly legitimate), or was it just a mistake? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
This is not the first rant about it. I guess the most constructive way to help would be to open an issue. Nicolas Le 6 mars 2012 14:22, Tudor Girba <tudor@tudorgirba.com> a écrit :
Hi,
Filesystem is part of the Pharo 1.4 image and the code resides in the Pharo 1.4 repository.
Essentially, as Lukas pointed out, this is a fork. There is absolutely nothing wrong with that, especially if you want to base the core on it.
However, the problem is what happens with the changes. Do they flow back to the original author, or do you want to fork completely? Of course, a collaboration requires at least two parties to work together :), but it would still be cool to get the position clear.
Of course, some changes are internal and they have little impact on the end user, but sometimes the public interface changes, too, and that is more problematic. Case in point are the onDisk and inMemory methods which were renamed to disk and memory, respectively. This basically breaks any previous code that is using Filesystem. Is there a particular reason for doing this (the original names seem perfectly legitimate), or was it just a mistake?
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
On 2012-03-06, at 14:22, Tudor Girba wrote:
Hi,
Filesystem is part of the Pharo 1.4 image and the code resides in the Pharo 1.4 repository.
Essentially, as Lukas pointed out, this is a fork. There is absolutely nothing wrong with that, especially if you want to base the core on it.
right, it's the fork of FileSystem for pharo :), maybe can name the project PhileSystem :D
However, the problem is what happens with the changes. Do they flow back to the original author, or do you want to fork completely? Of course, a collaboration requires at least two parties to work together :), but it would still be cool to get the position clear.
- changes don't flow in this case, although this would be preferable for fixes
Of course, some changes are internal and they have little impact on the end user, but sometimes the public interface changes, too, and that is more problematic. Case in point are the onDisk and inMemory methods which were renamed to disk and memory, respectively. This basically breaks any previous code that is using Filesystem. Is there a particular reason for doing this (the original names seem perfectly legitimate), or was it just a mistake?
that was done by me on purpose :) just because I don't care much about english grammar in this case (in vs on) plus it's shorter. and generally you don't prefix getters in smalltalk. But I should introduce the backwards compatible methods again, since I did these changes mainly for myself (since I was for quite some time the only developer on the project). It was not my intention to kill projects that depend on it :) best cami
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
Hi, On Tue, Mar 6, 2012 at 2:39 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2012-03-06, at 14:22, Tudor Girba wrote:
Hi,
Filesystem is part of the Pharo 1.4 image and the code resides in the Pharo 1.4 repository.
Essentially, as Lukas pointed out, this is a fork. There is absolutely nothing wrong with that, especially if you want to base the core on it.
right, it's the fork of FileSystem for pharo :), maybe can name the project PhileSystem :D
Perhaps this would be preferable to not create confusion in the future. Would this be doable?
However, the problem is what happens with the changes. Do they flow back to the original author, or do you want to fork completely? Of course, a collaboration requires at least two parties to work together :), but it would still be cool to get the position clear.
- changes don't flow in this case, although this would be preferable for fixes
Did you try to contact the original authors?
Of course, some changes are internal and they have little impact on the end user, but sometimes the public interface changes, too, and that is more problematic. Case in point are the onDisk and inMemory methods which were renamed to disk and memory, respectively. This basically breaks any previous code that is using Filesystem. Is there a particular reason for doing this (the original names seem perfectly legitimate), or was it just a mistake?
that was done by me on purpose :) just because I don't care much about english grammar in this case (in vs on) plus it's shorter. and generally you don't prefix getters in smalltalk.
But I should introduce the backwards compatible methods again, since I did these changes mainly for myself (since I was for quite some time the only developer on the project).
It was not my intention to kill projects that depend on it :)
No stress. My intention was not to criticize, but merely to understand. I can live with this, but I think this particular decision was taken a tiny bit too lightly :). For example, inZip: is still around in the original form. But, if you insist on having the short version of the selectors, the easy thing would be to provide compatibility methods. I opened an entry: http://code.google.com/p/pharo/issues/detail?id=5442 Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
participants (3)
-
Camillo Bruni -
Nicolas Cellier -
Tudor Girba