Add implementation for `BirdCount#initialize`

[AriaXLi]

Hello! Please feel free to close this PR if I have misunderstood.

While doing the Bird Count exercise for the Ruby track, I noticed there was no task to implement the initialize method but initialize must be implemented in order to pass the tests & finish the exercise.

I'm unsure if it is preferred that the initialize method should already be implemented as a part of the starting code or if it should be one of the tasks that the user/student needs to do. So please let me know if another way is preferred. Thank you!

[iHiD]

Hey. Thanks for the PR!

I think it's probably not either actually. I don't think it should be a task (as that doesn't do anything that's really meaningful and we don't want to tell the student that they need to do this) but also I don't think we want to give the code away.

So I think the solution is maybe to remove the raise from the initializer altogether and just leave the method blank. What do you think?

[kotp]

Since it is a concept exercise and the instructions show the BirdCount.new(birds_per_day) code as an example to use this program, it may be well documented.

As far as raising an exception, it should be enough to draw the student to attend to that detail without a specific task. I would not give the code away, as there are decisions to be made there for naming.

The exception being raised is much less subtle than not having it there for the student to figure out, which is probably not the point of the concepts being taught here. (This also provides that "task" as it is very noisy, and you can not get past it without making a decision to do something with that raise.)

If we leave the initialize body blank, it may not be obvious to the learner that is required, rather than providing a 1 in the next tested method (yesterday).

Raising the exception brings, loudly, attention to the initialize method, and may be appropriate because of where this is in the concepts.

Summary:

1. Removing the raise is probably going to be confusing, being too subtle where it is in the concepts.
2. Giving the answer is going to remove naming responsibility for the student, while we already provide the argument name for the initialize method.

[AriaXLi]

Ah okay I see. I think my initial confusion mostly came from the assumption that the instructions would tell me to implement initialize as one of the tasks since that's how previous exercises did that. I was mostly worried that it may not be super obvious to other students that they need to implement it in order to complete the exercise.

I do agree though, the raise did bring attention to initialize and helped me realized I needed to implement it. Also, completely agree, the code shouldn't be given away to the student.

I'm unsure on what would be best, this is all quite new to me, but I'm open to closing this PR if that seems the most reasonable!

[kotp]

@AriaXLi ,

Did you think at this point in the exercises that not having the specific action of developing that initialize method being explicitly said is appropriate? At this point are we ready to take away the training wheel for this specific thing? Or was it too abrupt? Or just a "Hmm.. where did that walking stick go" before you realized you really do not need it any more?

[kytrinyx]

Sorry for asking potentially silly questions, as I'm not familiar with the Ruby syllabus.

• Is there an exercise that explicitly teaches initialize as a concept?
• Are there several exercises that have explicit tasks instructing students to implement initialize? Or just one? (Or none?)

[kotp]

I do in mentoring the practice exercises, but there is nothing for classes mentioned in the config.json that I saw, and not specifically for initialize.

[kytrinyx]

@AriaXLi said:

I think my initial confusion mostly came from the assumption that the instructions would tell me to implement initialize as one of the tasks since that's how previous exercises did that.

The thing that I'm trying to understand is that's how previous exercises did that.

Which exercises did we do that for?

Philosophically, from a Concept Exercise point of view we should have tasks that are related to the concept that the exercise is teaching. If we need to explain something that isn't directly related to the concept being taught, we should consider whether we should have a separate exercise that teaches it, or whether we explain it once and then assume that the student knows it.

I'm not familiar with the syllabus for this track, so I'm mostly just asking questions in an attempt to help uncover the information needed to be able to make a good decision on how to proceed here.

[kotp]

The answer to how the prior exercise did it was through the instructions.md file, apparently. Though the specific exercise was not mentioned, I believe it was Amusement Park that states to implement initialize in the introduction.md file. This exercise, instead of stating to do so in the introduction, specifically raises if you do not remove it.

So, earlier it was gentle, and potentially missed (since I know some students do not pay close attention to the instructions and introduction files, relying on the tests instead. But, now I see at least this student pays attention to the written directives, more than, perhaps, the exceptions, and exception messages, with the back trace can be confusing for sure.

So the change proposed is probably not the solution, perhaps, @AriaXLi can answer this better than I can, the introduction or instruction file could give the same direction as was given in that prior exercise?

I agree, though, that a concept exercise is probably in order regarding classes and the role of new and allocate and initialize and how they play together. I have had too many students tell me that initialize is the constructor, and not recognize that new is the constructor, and initialize is the initializer. (And that initialize is public, but that is a fault of omission, and another story…)

[kytrinyx]

@kotp Cool, that's helpful.

@AriaXLi I think the way forward is to remove the raise and add a gentle reminder in the introduction.md file, similar to the previous exercise.

In the future we could consider adding an explicit exercise around initialization and potentially simplify existing exercise introductions as a result.

[iHiD]

I took the approach that teaching OOP is outside of the remit of teaching Ruby as a language. So currently, I'd expect people to be familiar with constructors as a topic. (I don't see that as an absolute position, but as a pragmatic one to get some sort of syllabus of Ruby in place without teaching a huge amount of paradigm stuff)

[kytrinyx]

@iHiD Okay, cool. So the consensus seems to be: remove the raise and edit the introduction.md, and let's leave thinking about the Ruby syllabus curriculum for future consideration.

@AriaXLi If you'd like to change this PR to make that change, that's great. If not, please feel free to close the PR!

[kytrinyx]

As we've not heard anything further, I'm going to conclude that this PR is abandoned. Thank you for taking the time to discuss this, @AriaXLi.