Daniel,
Thanks for asking the question and I hope the discussion will go better than
the last time we had an in depth discussion on the topic. I'm going to
respond in a Prologue, History, Reactions, Code Examples and Conclusion.
*Prologue*
I'm not a classically trained CS guy. I've never taken
On 26 February 2010 08:09, Naftoli Gugenheim wrote:
> Either -- but it's more verbose.
> I'm not so sure David will want to rewrite the entire lift anyway...
>
Right now, I only would like to listen to Daniel, OK?
Heiko
Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.co
Either -- but it's more verbose.
I'm not so sure David will want to rewrite the entire lift anyway...
-
Heiko Seeberger wrote:
Daniel,
I would like to look at this question from a solution oriented
perspective: Certainly you already noticed the third Box subty
Daniel,
I would like to look at this question from a solution oriented
perspective: Certainly you already noticed the third Box subtype Failure and
are aware of its usage. I agree with you, that Option vs Box is confusing
for Lift (and nowadays Goat Rodeo) adopters. As Scala and Lift are still
ver
I'm assuming you know that it has a third, Failure state, and you're asking
about the names.
I guess open_! is in keeping with the metaphor of a box (or originally, a can).
The _! is Lift's way of saying, Danger! And I guess 'or' is just shorter. (Lift
tends to put practicality before academic f
I'm sure this has been discussed before, but I'm curious as to the
rationale for the Box ADT. I'm most distressed by the fact that it
seems to be masquerading as a drop-in Option replacement, and yet the
mathematical properties of the ADT are widely divergent. What's more,
the API is very, very d
