Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Replace `NumCell` with `NumericCellExt` for `Cell` #1064
While I was reviewing #1046, I found myself confused at the mixture of
Thinking about it more, it seemed like the continuation of NumCell reasoning would be a continuing array of Cell types for any specialized type, so I wondered if there might be a more 'rustic' way to do this, and it turns out extension types are a thing.
The idea here is that we can add the desired
Currently we're only using
The Question: What are our thoughts on extending the
referenced this pull request
Jul 2, 2018
I'm kind of in favor of removing NumCell, since it's just another type that has a pretty narrow use.
But I don't think we should go down the path of extension types until we have many examples that we can generalize from and come up with a good, consistent approach to.
left a comment
I think we should use abstractions to make code easier to read, and I find
Side note: I have more commits that use numcell, they just are blocked on a chain of PRs at the moment.
Sure, I think that once you know what NumCell does and what is purpose is, it is simpler code than a regular Cell. But the tradeoff there is that you have to learn what NumCell does. So this is a tradeoff between making the code a little bit cleaner for an expert and a little bit less clear to a novice. I think self.val.add(5) is not a big cognitive cost, but I also think the gains are small. While understanding add() isn't hard, seeing a NumCell declared and understanding why means another type to understand.
That being said, it seems like if we want to have a Cell type for numbers, then we should think through exactly what its uses should be (I think we're pretty good on this one, so far), then based on that what its interface should be (we're only part-way there), then implement it and use it all places that we think match its intended use (not great, it's only used in one capsule). For example, why does NumCell support add and subtract but not shift or bitwise operations? Right now it seems like a narrowly designed abstraction that's useful now but will probably have to change as it sees more use, a class of abstractions I'm feeling pretty negative on right now.
It will probably have to expand, which is very different from changing. There is basically no cost, in terms of backward compatibility, to adding features to a type as needed.
As a user, you're not even going to have a field of type
The only way in which this might be a problem is if someone writes their own instance of