Use strict types

[codedge]

Hey @petemcfarlane, @djjohnsongeek, @arueckauer,

as discussed with @neenjaw in a new exercise an enhancement to the php tasks would be to enforce strict types by adding declare(strict_types=1); to every php file.

This should be already in the skeleton files offered by the exercise.io platform, so that a possible file could look like this:

<?php

declare(strict_types=1);

function xyz() {

}

What do you think?

[arueckauer]

Excellent! I'm in favor of this, since it helps the student understand language features and best practices.

Only question I have is, if the strict type declaration could be explained at some point in the track? Or at least reference the documentation? This might be helpful to understand what's happening here. I am not familiar with the latest changes and thus not sure where a good place would be.

[neenjaw]

So how it is going to work in v3 is that there are explanatory "concept" exercises that teach a particular concept. In the concepts branch here, @djjohnsongeek and I have started making these concepts (which can be used as reference in the meantime while there are no concept exercises), strict types can appear there as a "concept" to be taught.

[djjohnsongeek]

I think teaching strict typing as a best practice should be kept as a separate teaching concept. Instead of becoming the default for the entire PHP track.

Love it or hate it, loose typing is the default behavior for PHP (as far as I know). My personal preference would be to teach the "default" PHP, but including a concept exercise that explains the many benefits of enabling strict typing.

Thoughts?

[arueckauer]

Correct, strict typing is not declared per default and due to BC-reasons must be done on a per file basis. As this discussion shows, there is a choice of personal preference - which also reflects the PHP world, where both options are available even in the same code base.

Not requiring strict typing leaves the options of providing either a loose or strictly typed solution. This would leave the choice up to the student as it is in the ecosystem. So, on second thought: a conceptual exercise or other way of teaching strict typing in PHP is favorable over demanding strict typing.

[MichaelBunker]

Love it or hate it, loose typing is the default behavior for PHP (as far as I know). My personal preference would be to teach the "default" PHP, but including a concept exercise that explains the many benefits of enabling strict typing.

Can't the same argument be said about namespaces then? Why try and push the use of namespaces when that's not the "default" way of writing PHP code? There is an overwhelmingly amount of bad practices that can be done in PHP, those shouldn't be encouraged in the track. Learning to write PHP, should be about learning to write PHP well. This is essentially the argument that is being made for introducing namespaces.

The main value from adding namespaces is teaching a good practice, that will become most beneficial in a context outside of exercism. By introducing namespaces we give the students an opportunity to practice and understand the concept. If we use a one explicit exercism, the learning effect is much less. If there is one exercise introducing namespaces and following exercises building on that knowledge, it would be much better.

Namespaces are a good practice, strict typing is a good practice. Users can choose to not write code using strict type checks for BC reasons (legacy code bases for example), but given new code, what good arguments exist for not using strict type checks? Type hints make the code easier to read and reason about, and fully strict type checking prevents a plethora of bugs from coming out of type juggling. Bugs that can be confusing for even seasoned PHP developers, let alone newcomers to the language.

The RFC for scalar types even says that fully strict typing has a lot of support, and it's only because of a minority group of voters and for BC reasons that the default isn't fully strict typing (which for official language maintainers makes sense, but I don't think Exercism needs to take the same concerns into consideration).

A significant portion of the PHP community appears to favor fully-strict types. https://wiki.php.net/rfc/scalar_type_hints_v5

Can't we have both an exercise in Concepts about strict types where the behavior is broken down into detail and the benefits are listed so that users are exposed to that information and learn that it doesn't have to be done (which could include how bugs could be introduced), but also have students write code that is fully strictly typed as practice during the exercises?

Either way, the decision should be consistent. Either we want to push students into using best practices, or we want to keep the concepts the the bare minimum and the bar for entry as low as possible.

[djjohnsongeek]

I think @MichaelBunker makes some pretty great points.

I'll counter with a thought but I definitely see the merits of enabling strict typing.

Namespaces help one organize code, but they don't actually change the way PHP behaves. (Correct me if I am wrong here) Enabling strict types however does significantly change the way PHP behaves. Its almost like a different "flavor" of PHP, where as namespaces are just a feature. Since the default PHP behavior is not strict, It makes more sense to expect the default flavor from students while teaching and encouraging the merits of strict typing.

99% of PHP code that I have worked on (In a professional environment) has made very sparse use of namespaces and never used strict typing. Now this is a weak point that relies entirely on my personally experience, but it gives some back ground on why I've argued against adopting strict typing for the whole track.

To be honest, at this point I would be happy with either option as long as:

• Significant effort is made to explain the differences between the two modes
• It is made clear that PHP's default is to have strict typing disabled

[SleeplessByte]

Hi there! We've recently (read I recently decided) to make the JavaScript track semi-typed by adding directives that work in some IDEs (the most popular ones).

These directives are similar to:

declare(strict_types=1);

Above the directive, on the first few exercises, we have a large comment block that explains what it does.

I think doing a similar thing here is good enough. Explain why you've decided it's good practice and that it's not on by default and that you encourage people to do it in their own files as well.

I've not used PHP since version 5, so take my opinion with lesser gravitas, but reading through all your comments it sounds like using strict types ís the preferred way going forward and not just a stylistic choice.

As a non PHPer I would probably want to learn the new way and not the legacy way. Maybe this helps making a decision.

[MichaelBunker]

For reference, it looks like this is the message JavaScript has that SleeplessByte mentioned - https://github.com/exercism/javascript/blob/main/exercises/concept/lasagna/lasagna.js#L1-L7

// @ts-check
//
// ☝🏽 The line above enables type checking for this file. Various IDEs interpret
// the @ts-check directive. It will give you helpful autocompletion on the web
// and supported IDEs when implementing this exercise. You don't need to
// understand types, JSDoc, or TypeScript in order to complete this JavaScript
// exercise, and can completely ignore this comment block and directive.

What if we did something similar in exercises and have the message include something about commenting out the line if you don't want to use strict typing? It could also include a link to the Concept for strict type checking in the PHP track.

This is a rough draft, and a little verbose, but what about something like this? Reworded from a few different PHP RFCs and blogs. We could also mirror JavaScript and have it disabled by default if that makes the maintainers/contributors more comfortable with including it.

<?php

// By adding type hints and enabling strict type checking, code can become easier to read, self-documenting and reduce the number of potential bugs.
// By default, type declarations are non-strict, which means they will attempt to change the original type to match the type specified by the type-declaration.
// In other words, if you pass a string to a function requiring a float, it will attempt to convert the string value to a float.
// To enable strict mode, a single declare directive must be placed at the top of the file. This means that the strictness of typing is configured on a per-file basis.
// This directive not only affects the type declarations of parameters, but also a function's return type. 
// For more info review the Concept on strict type checking in the PHP track <link>.
// To enable strict typing, comment in the directive below.

// declare(strict_types = 1);

[arueckauer]

@MichaelBunker I really like the idea of having this introduction and option in the exercises. It unifies both the experience for students as well as the base for feedback mentors provide.

Previously, if I saw a student solve an exercise with ease, I would point him/her towards strict typing and leace the choice up to the student to make another iteration or move on. Of course, I am not sure, what the response of other mentors have been regarding strict typping.

[SleeplessByte]

That's great!

I would turn it on by default if it's to be expected for new developers, but the overal gist is great.

For completeness, this is the other part we only show in the first exercise. JSDoc is not idiomatic (defacto), but it, again, gives type hints to smart/modern IDEs.

https://github.com/exercism/javascript/blob/main/exercises/concept/lasagna/lasagna.js#L9-L31

// 👋🏽 Hi there!
//
// On the JavaScript track we provide you with stubs. These stubs provide a
// starting point to solving the exercise.
//
// In general, each variable/constant and each declared function will have a
// JSDoc comment block above it, explaining what the variable/constant holds or
// the function is supposed to accomplish.
//
// 💡 Often, the JSDoc comment blocks have annotations, such as @param and
// @returns which are usually highlighted with a different color if the IDE
// you're in recognizes them. It's these annotations that are used when
// referring to the constant, variable, or function from somewhere else that
// IDEs display.
//
// You don't need to write these yourself; it is not expected in idiomatic
// JavaScript, but some companies and style-guides do enforce them.
//
// 💡 You're allowed to completely clear a stub before you get started. Often
// we recommend using the stub, because they are already set-up correctly to
// work with the tests, which you can find in ./lasagna.spec.js
//
// Good luck preparing some lasagna!

[MichaelBunker]

My preference is also to enable by default.

<?php

// By adding type hints and enabling strict type checking, code can become easier to read, self-documenting and reduce the number of potential bugs.
// By default, type declarations are non-strict, which means they will attempt to change the original type to match the type specified by the type-declaration.
// In other words, if you pass a string to a function requiring a float, it will attempt to convert the string value to a float.
// To enable strict mode, a single declare directive must be placed at the top of the file. This means that the strictness of typing is configured on a per-file basis.
// This directive not only affects the type declarations of parameters, but also a function's return type. 
// For more info review the Concept on strict type checking in the PHP track <link>.
// To disable strict typing, comment out the directive below.

declare(strict_types = 1);

[neenjaw]

Sounds good, who will champion this issue and open PRs to bring it to exercises? (who can I assign this to?)

[codedge]

@neenjaw I can work on this.

As I understand it is adding the explanation text from @MichaelBunker and making sure all excersises stub methods and test return correct types, right?

I am fully pro strict typings 🤩

[neenjaw]

Yep and correcting any failing example solutions