Smalltalk › Pharo › Pharo Smalltalk Developers

Need a decision on subString: vs substring:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

20 messages Options

stepharo

Need a decision on subString: vs substring:

*) It appears that Pharo is removing subString: in favor of
substring:. The ANSI standard defines subString:.

I was not aware of it. In fact ANSI is bad and totally incomplete
(for example we studies strings and this is a mess and totally
incomplete).
Now we should probably add it. I will send the mail to the
mailing-list and let people decide.

kilon.alios

Re: Need a decision on subString: vs substring:

why not both ?

On Thu, Sep 3, 2015 at 9:45 PM stepharo <[hidden email]> wrote:

*) It appears that Pharo is removing subString: in favor of
substring:. The ANSI standard defines subString:.

I was not aware of it. In fact ANSI is bad and totally incomplete
(for example we studies strings and this is a mess and totally
incomplete).
Now we should probably add it. I will send the mail to the
mailing-list and let people decide.

Sven Van Caekenberghe-2

Re: Need a decision on subString: vs substring:

We went through a lot of effort/pain to move to substring, I think for good reasons.

> On 03 Sep 2015, at 21:31, Dimitris Chloupis <[hidden email]> wrote:
>
> why not both ?

Because the proper English spelling is with lowercase

https://duckduckgo.com/?q=define%3A+substring&ia=definition

> On Thu, Sep 3, 2015 at 9:45 PM stepharo <[hidden email]> wrote:
> *) It appears that Pharo is removing subString: in favor of
> substring:. The ANSI standard defines subString:.
>
> I was not aware of it. In fact ANSI is bad and totally incomplete
> (for example we studies strings and this is a mess and totally
> incomplete).
> Now we should probably add it. I will send the mail to the
> mailing-list and let people decide.
>
>
>
>

gcotelli

Re: Need a decision on subString: vs substring:

I've second Sven here. In case anybody wants the old method put it in some ANSICompatibility package to ease porting packages from ANSI-compliant Smalltalks.

On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <[hidden email]> wrote:

We went through a lot of effort/pain to move to substring, I think for good reasons.

> On 03 Sep 2015, at 21:31, Dimitris Chloupis <[hidden email]> wrote:
>
> why not both ?

Because the proper English spelling is with lowercase

https://duckduckgo.com/?q=define%3A+substring&ia=definition

> On Thu, Sep 3, 2015 at 9:45 PM stepharo <[hidden email]> wrote:
> *) It appears that Pharo is removing subString: in favor of
> substring:. The ANSI standard defines subString:.
>
> I was not aware of it. In fact ANSI is bad and totally incomplete
> (for example we studies strings and this is a mess and totally
> incomplete).
> Now we should probably add it. I will send the mail to the
> mailing-list and let people decide.
>
>
>
>

Ben Coman

Re: Need a decision on subString: vs substring:

On Fri, Sep 4, 2015 at 4:44 AM, Gabriel Cotelli <[hidden email]> wrote:

> I've second Sven here. In case anybody wants the old method put it in some
> ANSICompatibility package to ease porting packages from ANSI-compliant
> Smalltalks.
>
> On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> We went through a lot of effort/pain to move to substring, I think for
>> good reasons.
>>
>> > On 03 Sep 2015, at 21:31, Dimitris Chloupis <[hidden email]>
>> > wrote:
>> >
>> > why not both ?
>>
>> Because the proper English spelling is with lowercase

+1. As a consequence, its the form that has won industry wide.
Aligning on this provides a small part of an accumulation of items
that lower the friction of adoption from the wider industry. On the
flip side, even though are potentially more non-Smalltalkers who may
adopt Pharo, others from existing Smalltalker dialects may be more
likely to transfer, so its good to not alienate them. So it may be
useful to have an ANSICompatibility package available in the Catalog
Browser that you can point people to - a box to tick on the checklist
to reduce the barriers to entry.

cheers -ben

>>
>> https://duckduckgo.com/?q=define%3A+substring&ia=definition
>>
>> > On Thu, Sep 3, 2015 at 9:45 PM stepharo <[hidden email]> wrote:
>> > *) It appears that Pharo is removing subString: in favor of
>> > substring:. The ANSI standard defines subString:.
>> >
>> > I was not aware of it. In fact ANSI is bad and totally incomplete
>> > (for example we studies strings and this is a mess and totally
>> > incomplete).
>> > Now we should probably add it. I will send the mail to the
>> > mailing-list and let people decide.
>> >
>> >
>> >
>> >
>>
>>
>

Dale Henrichs-3

Re: Need a decision on subString: vs substring:

+1 for an ANSICompatibility package ... ANSI shouldn't hold Pharo back,
and an ANSICompatibility package allows for cross-dialect code sharing
which was the aim of the ANSI standard in the first place.

Dale

On 9/3/15 5:51 PM, Ben Coman wrote:

> On Fri, Sep 4, 2015 at 4:44 AM, Gabriel Cotelli <[hidden email]> wrote:
>> I've second Sven here. In case anybody wants the old method put it in some
>> ANSICompatibility package to ease porting packages from ANSI-compliant
>> Smalltalks.
>>
>> On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>>> We went through a lot of effort/pain to move to substring, I think for
>>> good reasons.
>>>
>>>> On 03 Sep 2015, at 21:31, Dimitris Chloupis <[hidden email]>
>>>> wrote:
>>>>
>>>> why not both ?
>>> Because the proper English spelling is with lowercase
> +1. As a consequence, its the form that has won industry wide.
> Aligning on this provides a small part of an accumulation of items
> that lower the friction of adoption from the wider industry. On the
> flip side, even though are potentially more non-Smalltalkers who may
> adopt Pharo, others from existing Smalltalker dialects may be more
> likely to transfer, so its good to not alienate them. So it may be
> useful to have an ANSICompatibility package available in the Catalog
> Browser that you can point people to - a box to tick on the checklist
> to reduce the barriers to entry.
>
> cheers -ben
>
>>> https://duckduckgo.com/?q=define%3A+substring&ia=definition
>>>
>>>> On Thu, Sep 3, 2015 at 9:45 PM stepharo <[hidden email]> wrote:
>>>> *) It appears that Pharo is removing subString: in favor of
>>>> substring:. The ANSI standard defines subString:.
>>>>
>>>> I was not aware of it. In fact ANSI is bad and totally incomplete
>>>> (for example we studies strings and this is a mess and totally
>>>> incomplete).
>>>> Now we should probably add it. I will send the mail to the
>>>> mailing-list and let people decide.
>>>>
>>>>
>>>>
>>>>
>>>

demarey

Re: Need a decision on subString: vs substring:

In reply to this post by gcotelli

I don't like so much compatibility packages because people will not update their code and expect the compatibility package to always work.

Why not just use what Marcus did for deprecations? Create a rule to transform ANSI Smalltalk to Pharo "magicly'?

Le 3 sept. 2015 à 22:44, Gabriel Cotelli a écrit :

I've second Sven here. In case anybody wants the old method put it in some ANSICompatibility package to ease porting packages from ANSI-compliant Smalltalks.

On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <[hidden email]> wrote:
We went through a lot of effort/pain to move to substring, I think for good reasons.

> On 03 Sep 2015, at 21:31, Dimitris Chloupis <[hidden email]> wrote:
>
> why not both ?

Because the proper English spelling is with lowercase

https://duckduckgo.com/?q=define%3A+substring&ia=definition

> On Thu, Sep 3, 2015 at 9:45 PM stepharo <[hidden email]> wrote:
> *) It appears that Pharo is removing subString: in favor of
> substring:. The ANSI standard defines subString:.
>
> I was not aware of it. In fact ANSI is bad and totally incomplete
> (for example we studies strings and this is a mess and totally
> incomplete).
> Now we should probably add it. I will send the mail to the
> mailing-list and let people decide.
>
>
>
>

smime.p7s (5K) Download Attachment

Thierry Goubier

Re: Need a decision on subString: vs substring:

2015-09-04 9:39 GMT+02:00 Christophe Demarey <[hidden email]>:

I don't like so much compatibility packages because people will not update their code and expect the compatibility package to always work.
Why not just use what Marcus did for deprecations? Create a rule to transform ANSI Smalltalk to Pharo "magicly'?

An extension package with a set of rewrite rules that we can use to:

- port code for old Pharo versions to new Pharo versions

(in some areas of Pharo, many things disappear/are renamed without deprecation between versions)

- port non-Pharo code to Pharo.

It would be really great if those rules could be applied when loading the package via MC or FileIn, not when the package is already loaded, otherwise you need both a compatibility layer, and the rewriting rules.

Probably a lot easier to do by, say, replacing the MC code model by the RB code model. Or, when loading a package, loading it through a MC defintion, convert it to RB model, apply rules, convert to Ring, compile Ring...

I like simple things :)

Thierry

Le 3 sept. 2015 à 22:44, Gabriel Cotelli a écrit :

I've second Sven here. In case anybody wants the old method put it in some ANSICompatibility package to ease porting packages from ANSI-compliant Smalltalks.

On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <[hidden email]> wrote:
We went through a lot of effort/pain to move to substring, I think for good reasons.

> On 03 Sep 2015, at 21:31, Dimitris Chloupis <[hidden email]> wrote:
>
> why not both ?

Because the proper English spelling is with lowercase

https://duckduckgo.com/?q=define%3A+substring&ia=definition

> On Thu, Sep 3, 2015 at 9:45 PM stepharo <[hidden email]> wrote:
> *) It appears that Pharo is removing subString: in favor of
> substring:. The ANSI standard defines subString:.
>
> I was not aware of it. In fact ANSI is bad and totally incomplete
> (for example we studies strings and this is a mess and totally
> incomplete).
> Now we should probably add it. I will send the mail to the
> mailing-list and let people decide.
>
>
>
>

Ben Coman

Re: Need a decision on subString: vs substring:

In reply to this post by demarey

On Fri, Sep 4, 2015 at 3:39 PM, Christophe Demarey
<[hidden email]> wrote:
> I don't like so much compatibility packages because people will not update
> their code and expect the compatibility package to always work.
> Why not just use what Marcus did for deprecations? Create a rule to
> transform ANSI Smalltalk to Pharo "magically'?

People updating their code when porting is better than using a
compatibility package. But having code ported is better than
not-having code ported, if its perceived we are making it harder than
necessary. If someone wants to continue maintaining their software in
the original Smalltalk dialect, *forcing* their code from #subStrings
to #substrings is one more difference you've *imposed* on them to
maintain in their own compatibility layer. Its the sort of annoyance
that can taint people's emotional buy-in to a new system. This again
reminds me of a story about when Excel took over from Lotus (which
I've posted before) which I think applies to code being ported from
one system to another...

"Excel's tipping point [...] happened around the time of Excel 4.0.
And the biggest reason was that Excel 4.0 was the first version of
Excel that could *write* Lotus spreadsheets transparently. Yep, you
heard me. *Write*. Not read. It turns out that what was stopping
people from switching to Excel was that everybody else they worked
with was still using Lotus 123. [...] To take over a market, you have
to address every barrier to entry. If you forget just one barrier
which trips up 50% of your potential customers, then by definition,
you can't have more than 50% market share, and you will never displace
the dominant player, and you'll be stuck on the sad (omelet) side of
chicken and egg problems." [1]

[1] http://www.joelonsoftware.com/articles/fog0000000052.html

The corollary being, if you make it simple for people to continue
maintaining the old dialect, you are more likely to get code ported to
your dialect.

cheers -ben

>
> Le 3 sept. 2015 à 22:44, Gabriel Cotelli a écrit :
>
> I've second Sven here. In case anybody wants the old method put it in some
> ANSICompatibility package to ease porting packages from ANSI-compliant
> Smalltalks.
>
> On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> We went through a lot of effort/pain to move to substring, I think for
>> good reasons.
>>
>> > On 03 Sep 2015, at 21:31, Dimitris Chloupis <[hidden email]>
>> > wrote:
>> >
>> > why not both ?
>>
>> Because the proper English spelling is with lowercase
>>
>> https://duckduckgo.com/?q=define%3A+substring&ia=definition
>>
>> > On Thu, Sep 3, 2015 at 9:45 PM stepharo <[hidden email]> wrote:
>> > *) It appears that Pharo is removing subString: in favor of
>> > substring:. The ANSI standard defines subString:.
>> >
>> > I was not aware of it. In fact ANSI is bad and totally incomplete
>> > (for example we studies strings and this is a mess and totally
>> > incomplete).
>> > Now we should probably add it. I will send the mail to the
>> > mailing-list and let people decide.
>> >
>> >
>> >
>> >
>>
>>
>
>

demarey

Re: Need a decision on subString: vs substring:

Le 4 sept. 2015 à 12:20, Ben Coman a écrit :

> On Fri, Sep 4, 2015 at 3:39 PM, Christophe Demarey
> <[hidden email]> wrote:
>> I don't like so much compatibility packages because people will not update
>> their code and expect the compatibility package to always work.
>> Why not just use what Marcus did for deprecations? Create a rule to
>> transform ANSI Smalltalk to Pharo "magically'?
>
> People updating their code when porting is better than using a
> compatibility package. But having code ported is better than
> not-having code ported, if its perceived we are making it harder than
> necessary. If someone wants to continue maintaining their software in
> the original Smalltalk dialect, *forcing* their code from #subStrings
> to #substrings is one more difference you've *imposed* on them to
> maintain in their own compatibility layer. Its the sort of annoyance
> that can taint people's emotional buy-in to a new system. This again
> reminds me of a story about when Excel took over from Lotus (which
> I've posted before) which I think applies to code being ported from
> one system to another...
>
> "Excel's tipping point [...] happened around the time of Excel 4.0.
> And the biggest reason was that Excel 4.0 was the first version of
> Excel that could *write* Lotus spreadsheets transparently. Yep, you
> heard me. *Write*. Not read. It turns out that what was stopping
> people from switching to Excel was that everybody else they worked
> with was still using Lotus 123. [...] To take over a market, you have
> to address every barrier to entry. If you forget just one barrier
> which trips up 50% of your potential customers, then by definition,
> you can't have more than 50% market share, and you will never displace
> the dominant player, and you'll be stuck on the sad (omelet) side of
> chicken and egg problems." [1]
>
> [1] http://www.joelonsoftware.com/articles/fog0000000052.html
>
> The corollary being, if you make it simple for people to continue
> maintaining the old dialect, you are more likely to get code ported to
> your dialect.

I agree with that.
To be compatible with these goals, I think my proposition just needs to be updated a bit.
I'm still in favor of rules to transform ANSI code to Pharo code. The point is that we should not force the user to update their code base. The rule-cased approach is compatible with that if you transform ANSI code when it gets loaded in the image.

smime.p7s (5K) Download Attachment

Jan Vrany

Re: Need a decision on subString: vs substring:

...

> > The corollary being, if you make it simple for people to continue
> > maintaining the old dialect, you are more likely to get code ported
> > to
> > your dialect.
>
> I agree with that.
> To be compatible with these goals, I think my proposition just needs
> to be updated a bit.
> I'm still in favor of rules to transform ANSI code to Pharo code. The
> point is that we should not force the user to update their code base.
> The rule-cased approach is compatible with that if you transform ANSI
>
> code when it gets loaded in the image.

No, it's not! Rewriting the code in this case is actually a very bad
thing. The problem is that when you port changes done in, say,
Pharo back to, say, "The other cool Smalltalk" you have rewrite
everything back (or things will break). This is not what you want
to spend you time on.

So either don't enforce code rewriting in this case or be honest and
say openly "I do not care, not my problem" :-)

And no, I'm not theorizing, I'm talking out of my
every-two-weeks-or=-so-pain I'm suffering last year or so.

Best, Jan

cbc

Re: Need a decision on subString: vs substring:

In reply to this post by demarey

On Fri, Sep 4, 2015 at 6:18 AM, Christophe Demarey <[hidden email]> wrote:

<snip>

I agree with that.
To be compatible with these goals, I think my proposition just needs to be updated a bit.
I'm still in favor of rules to transform ANSI code to Pharo code. The point is that we should not force the user to update their code base. The rule-cased approach is compatible with that if you transform ANSI code when it gets loaded in the image.

True to a point. That point being folks who want to write code that could play in other ANSI Smalltalks - with your approach, you have locked those people out, since they CAN'T write ansi code - only Pharo code. any non-Pharo ANSI'ism would be auto-changed back to Pharo - and they'd leave to write and live in a different Smalltalk.

Now, if you had the ANSI compatibility layer that either allowed conversion to Pharo OR ignored conversion to Pharo, that wouldn't be a barrier.

On a different topic, what would be required to amend the ANSI standard? Maybe a Smalltalk Agreement 2016 that took the standard and amended some parts (like fixing the spelling) so that going forward, all Smalltalks could be standard with good English spellings?

Just curious,

cbc

Sean P. DeNigris

Re: Need a decision on subString: vs substring:

Administrator

In reply to this post by Ben Coman

Ben Coman wrote

>> Because the proper English spelling is with lowercase
+1.... So it may be useful to have an ANSICompatibility package

+1 to having the proper spelling (that we've fought so hard to have) as the only one in the image. And +1 for a compatibility package if there is a proven demand for such a thing.

Cheers,
Sean

kilon.alios

Re: Need a decision on subString: vs substring:

I am confused till now I have been reading that pharo does not care about the past or does not care about being another Smalltalk implementation and it cares only being Smalltalk inspired . What changed in the meant time ? Why so much talk about other Smalltalks and ANSI-Smalltalk ?

On Sat, Sep 5, 2015 at 6:28 AM Sean P. DeNigris <[hidden email]> wrote:

Ben Coman wrote
>>> Because the proper English spelling is with lowercase
> +1.... So it may be useful to have an ANSICompatibility package

+1 to having the proper spelling (that we've fought so hard to have) as the
only one in the image. And +1 for a compatibility package if there is a
proven demand for such a thing.

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Need-a-decision-on-subString-vs-substring-tp4847932p4848193.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

stepharo

Re: Need a decision on subString: vs substring:

In reply to this post by cbc

I agree with that.
To be compatible with these goals, I think my proposition just needs to be updated a bit.
I'm still in favor of rules to transform ANSI code to Pharo code. The point is that we should not force the user to update their code base. The rule-cased approach is compatible with that if you transform ANSI code when it gets loaded in the image.

True to a point. That point being folks who want to write code that could play in other ANSI Smalltalks - with your approach, you have locked those people out, since they CAN'T write ansi code - only Pharo code. any non-Pharo ANSI'ism would be auto-changed back to Pharo - and they'd leave to write and live in a different Smalltalk.

Now, if you had the ANSI compatibility layer that either allowed conversion to Pharo OR ignored conversion to Pharo, that wouldn't be a barrier.

On a different topic, what would be required to amend the ANSI standard? Maybe a Smalltalk Agreement 2016 that took the standard and amended some parts (like fixing the spelling) so that going forward, all Smalltalks could be standard with good English spellings?

Chris

ANSI is not really good. It is old. And the time investement would be enormous to improve and nobody would care.
I read it with attention about strings for example. Because the String API is not really nice in any Smalltalk but this is another story.
I do not expect anything from Ansi or any improvements.
Let us face it when VW change syntax, added namespaces or whatever they did not care about ANSI.
So adding a compatibility package is the way to go.

Stef

stepharo

Re: Need a decision on subString: vs substring:

In reply to this post by kilon.alios

I am confused till now I have been reading that pharo does not care about the past or does not care about being another Smalltalk implementation and it cares only being Smalltalk inspired . What changed in the meant time ? Why so much talk about other Smalltalks and ANSI-Smalltalk ?

Nothing we do not diverge for the fun in general. We diverge to improve (of course people can discuss it and think that we are idiots)
Now if adding a method in a package can help people porting to Pharo we should not be stupid :)

Stef

On Sat, Sep 5, 2015 at 6:28 AM Sean P. DeNigris <[hidden email]> wrote:

Ben Coman wrote
>>> Because the proper English spelling is with lowercase
> +1.... So it may be useful to have an ANSICompatibility package

+1 to having the proper spelling (that we've fought so hard to have) as the
only one in the image. And +1 for a compatibility package if there is a
proven demand for such a thing.

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Need-a-decision-on-subString-vs-substring-tp4847932p4848193.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Stephan Eggermont-3

Re: Need a decision on subString: vs substring:

In reply to this post by stepharo

We have quite a lot of instances of #subString: in Seaside.
The deprecation makes loading painful.
What is the decision?

Stephan

Jan Vrany

Re: Need a decision on subString: vs substring:

Hi,

I'm not sure what's the decision, however, as a pain-relief
I committed just couple days ago CompatibilityANSI to
http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility

For now it only defines subStrings: :-)

On Sun, 2015-09-20 at 16:08 +0200, Stephan Eggermont wrote:
> We have quite a lot of instances of #subString: in Seaside.
> The deprecation makes loading painful.
> What is the decision?
>
> Stephan
>
>

Sean P. DeNigris

Re: Need a decision on subString: vs substring:

Administrator

In reply to this post by Stephan Eggermont-3

> What is the decision?
The consensus seemed to be #substrings:, and a compatibility package if necessary.

Cheers,
Sean

EstebanLM

Re: Need a decision on subString: vs substring:

On 20 Sep 2015, at 19:14, Sean P. DeNigris <[hidden email]> wrote:

> What is the decision?
The consensus seemed to be #substrings:, and a compatibility package if necessary.

… because substring is real english while subString is not, AFAIK :)

Cheers,
Sean

View this message in context: Re: Need a decision on subString: vs substring:
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.