> On 03 Mar 2015, at 14:52, Sven Van Caekenberghe <[email protected]> wrote:
>
>
>> On 03 Mar 2015, at 14:37, Sean P. DeNigris <[email protected]> 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
