decision - prefix convention

[bencoman]

This issue is opened to record discussion of a decision point.

Pharo currently lacks namespaces (its a long term goal to add it in but in the meantime we get along without it due to Pharo's other advantages)

The conventional way around this is to prefix class names with a project identifier. Should exercises follow this convention? e.g. rather than class name HelloWorld, it might be EXHelloWorld.

On the one hand this might be mildly off-putting for newcomers who are yet to discover Pharo's advantages to balance against this.
On the other hand, this is the reality that Pharo developers need to get used to it. And anything else may leave students open to bumping into namespace conflicts between their solutions and system classes.

I've not fully formed my opinion on this yet, but like to open it for discussion (@samWson @macta)

[samWson]

Personally I've never done a project in Pharo big enough for the lack of name spacing to be a problem, but then I've never really pushed any of my Pharo work into the world either. I usually use a new image for every project. The Pharo Launcher tool is fantastic for this.

@bencoman I think you raise a valid point. I think for the custom tools we need to make for this language track it is a good idea. It's up to every user whether they use clean images every time or not. We should strive to make our tools fit effortlessly with other peoples workflow. Prefixing class names with an identifier has very little cost compared to the benefit it may bring.

In terms of people doing exercises, I'm erring on the side of introducing prefixing class names too. It could be introduced as a concept in one of the early exercises simply with a single paragraph in a README. It could subtly introduced as convention when a user fetches an exercise: they get back an exercise directory containing a class stub EXHelloWorld and a test class EXHelloWorldTest.

If we do choose to prefix class names, we should stick with community convention. EX for Exercism seems like a good fit. I'm leaning toward using class name prefixes. The cost of not having them is probably low, however the cost of including them is also very low especially if we include them at the very beginning of this project.

[macta]

Guys - if you look at the kinds of problems they are - which are either a few methods in a single class (plus a Test class) OR a few classes, I don't think we should worry about prefixes or any kinds of distractions. The idea is to try out a language without distraction?

I think its doubtful we would hit a collision (I could be wrong).

[bencoman]

On 2 July 2018 at 18:53, Tim Mackinnon notifications@github.com wrote:

Guys - if you look at the kinds of problems they are - which are either a few methods in a single class (plus a Test class) OR a few classes, I don't think we should worry about prefixes or any kinds of distractions. The idea is to try out a language without distraction?

I think its doubtful we would hit a collision (I could be wrong).

I haven't looked much at the problems yet, so I was being conservative, and I'm willing to follow your wisdom. Suck it & see, and deal with it only if it turns out to be a problem (which itself is a strong Smalltalk meme).

On 2 July 2018 at 16:11, Samuel notifications@github.com wrote:

Personally I've never done a project in Pharo big enough for the lack of name spacing to be a problem, but then I've never really pushed any of my Pharo work into the world either. I usually use a new image for every project. The Pharo Launcher tool is fantastic for this.

@bencoman https://github.com/bencoman I think you raise a valid point. I think for the custom tools we need to make for this language track it is a good idea. It's up to every user whether they use clean images every time or not. We should strive to make our tools fit effortlessly with other peoples workflow. Prefixing class names with an identifier has very little cost compared to the benefit it may bring.

In terms of people doing exercises, I'm erring on the side of introducing prefixing class names too. It could be introduced as a concept in one of the early exercises simply with a single paragraph in a README. It could subtly introduced as convention when a user fetches an exercise: they get back an exercise directory containing a class stub EXHelloWorld and a test class EXHelloWorldTest.

That was what I was thinking also. But I did have some concerns for newcomers having something extra to deal with. I'm willing to try it without per Tim's suggestion.

cheers -ben

[samWson]

I think that's a general agreement. No class prefixes. I think it's unlikely we will have great problems, but if we do I don't think the cost of changing it later will be high in terms of code changes. User experience might jar a wee bit.

Unless there is more on this I think we can close this issue of and consider it decided.