Please look at the article on medium
Please share your thought and feed back.
Please look at the article on medium
Please share your thought and feed back.
For further actions, you may consider blocking this person and/or reporting abuse
Ankit Rattan -
Weam Adel -
Sani Joshua -
Ivelin Yanev -
Top comments (2)
I think your article needs a lot of cleaning up.
Your first paragraph doesn't say much, and it confusing. I don't think your use of "axioms" or "semantics" are appropriate there, because they have precise meaning in CS and you don't actually give enough detail to justify the use of the technical terms here.
Constructors create an instance -- crucially, you are able to make multiple instances of a data structure, and the defining characteristic of a constructor is that you did not have one before, which isn't explicitly named.
Integers are a confusing example of a data structure. You left out a mutating example (because most integers are treated immutably), which is correct but detracts from the clarification you just laid out!
More importantly, you left out the constructors of integers! This*is* a significant omission, because a structure with no ability to be constructed can't be used! The integers are also a bad example here because defining their constructor is not straightforward (the "pure" way night be to just define the constructor of
1
, but this is not intuitive).I think laying out a more familiar, less formal example would be better:
Consider a shopping cart.
Drawing a static picture with two arrows and saying it is "easily understood" what is meant is fairly low effort. If you want to show how it operates, you need to show the structure changing over time. Try showing different "versions" as things are placed and removed from the stack.
"We can say the top of the stack is pointing to -1" -- no you can't, and you shouldn't. It's empty. It's invalid to ask a stack what's at the top if it's empty; if anything it should have a special return value necessarily distinct from all of the objects that your allowed to put in it, like epsilon.
"Not possible to remove it" -- that's not true; it's not possible to remove it without first removing the other values. Precision is important in these kinds of subjects, otherwise you could confuse your reader who is trying to learn something new and doesn't already know what you mean.
"Creates a new stack" if imprecise. What it does is creates an empty stack.
Unclear why use the term "support methods" but didn't use this term when you classified the types of members of data structure at the beginning of the article. Neither
size
norisEmpty
can be implemented (without a lot of extra space and computation time) in terms of the other operations, so they really should be defined as part of the main interface of the stack. In particular, in a language like C you could easily implement a stack that doesn't track them, leaving programmers at the peril of misusing it but squeezing a bit of extra performance out.Your exceptions should not be checked exceptions, because they are the result of programmer errors rather than valid uses of the class. They should extend from
RuntimeException
so that correct callers are not required to handle them.It's also a little strange to implement a stack with a fixed capacity, but does fit the specification you outlined at the beginning.
Thanks for the wonderful feedback , gave me a kickstart to re write the article. this feedback provides wonderful insights where i can learn more.