Dope!

Hmmm...interesting, interesting.

From my understanding, in that particular case, Object.freeze() was invoked with frozenObj being passed in as the argument. This means that invoking isFrozen(frozenObj) would result in a return value of the boolean true. It is up to here where we are on the same page, it seems.

Now, we're at the point where we have to determine if a frozen object should, in fact, be sealed. At the moment, the tests are written in a way where a frozen object cannot and should not also be considered sealed.

Part of the reason for this is because, taking that same frozen object scenario, we cannot do this:

  let targetObj = {a: 1, b: 2, c: 3};
  Object.freeze(targetObj);
  targetObj["a"] = 77;
  targetObj; // {a: 1, b: 2, c: 3};
  // The overwriting of key "a" DOES NOT go through successfully;

However, if the object was sealed instead, something different happens:

  let targetObj = {a: 1, b: 2, c: 3};
  Object.seal(targetObj);
  targetObj["a"] = 77;
  targetObj; // {a: 77, b: 2, c: 3};
  // The overwriting of key "a" DOES go through successfully;

In both cases, when an object is frozen or when an object is sealed:

• we cannot create/add a property;
• we can read from the object;
• we cannot delete a property from the object;

Where they differ, as seen in the code blocks above, is the fact that a property on a frozen object cannot be updated/overwritten whereas a property on a sealed object can be updated/overwritten.

For this distinct reason, it seemed to make more sense (to me) to consider a frozen object as solely frozen. In other words, the fact that we could essentially edit a sealed object but we are unable to edit a frozen object was enough grounds for me to separate the two conditions (frozen/sealed) instead of allowing the object to exist in multiple states/conditions.

If this is bad practice, or if I'm completely off-the-mark and I am misunderstanding, please let me know! I want to make sure this is as on-point as possible.

Thank you!

I like the way you think ^.^

Awesome kata(s)! I completed the "Retrieve My Ether" kata that you also authored, which definitely helped me dig into the Web3 documentation.

In addition, I wanted to bring to your attention that there might be a flaw in the test specs. For example, my solution should not have passed.

Please feel free to check that out ^.^

Keep these types of katas coming, though! They're very appreciated.

This was really fun to productively struggle through :s

That's an awesome thing to set out to do. I learned a lot just from reading your solution ^.^

Whoa!

Sure thing. Much appreciated!

Whoa!

Dope kata!

Also, the idea behind reminding the user to return an array where length === input.length + 1 was another way of aligning the zero-indexed arrays with the nature of the kata. Basically, the test was trying to make sure the user didn't forget to include the first null/nil of the array.

Sorry. Are we referring to the second describe block in the Sample Test Cases? Just want to make sure it's somewhere!

Your solution looks good, especially the comments! Stick with it ^.^

I appreciate it! I approved your C++ translation. Thank you for what you are doing :)

Much appreciated!

I hear you. The test cases in the example test case might've helped, too! There were ten sample test cases in that section, as well as a describe block explaining: "Your solution should return an array with a length of input.length + 1"!

I'll keep that in mind for next time, though :)