Hi,

On Tue, Mar 6, 2012 at 2:39 PM, Camillo Bruni <[email protected]> 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"

Reply via email to