You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Was there a particular motivation for making Dataflow.cell a big ol' closure rather than a class with an evaluate method? Without knowing such a motivation, I feel like it would be easier to understand as a class.
(I'm interested in working on this.)
The text was updated successfully, but these errors were encountered:
I had made it a closure instead of a class because I thought this mechanism would be used more throughout the code, so I wanted a "DSL" way of dealing with it. But cells ended up only being used in a few places (Attribute and Element).
So the short answer is I'm fine with making it a class since that will be more understandable.
The long answer is I'm not sure if even this mechanism is the right thing. I am, for example, worried about the efficiency of depending on try-catch to find spreads. The nice thing about cells is that they decouple the spread logic from everywhere else. The idea of cells was to support this logic closer to the language level. I would love hearing other ways of doing it though if you think of anything.
Was there a particular motivation for making
Dataflow.cell
a big ol' closure rather than a class with anevaluate
method? Without knowing such a motivation, I feel like it would be easier to understand as a class.(I'm interested in working on this.)
The text was updated successfully, but these errors were encountered: