Once people get Can, I think it makes sense, so I think we can leave
it.
As a replacement, I can't think of a good real-life example of a thing
with a failure indicator that fits the bill. :)
What about OptionWithFailure, OptionWF, OptWithF?
It's more typing, but it's accurate.
FailureIndicatin
What about renaming it Glass? Then we could add:
case class HalfFull[T](data : T) extends Glass[T]
type HalfEmpty[T] = HalfFull[T]
;)
Derek
On Sat, Dec 20, 2008 at 8:13 AM, TylerWeir wrote:
>
> Once people get Can, I think it makes sense, so I think we can leave
> it.
>
> As a replacement, I
Funny boy. :-)
On Dec 20, 2008 7:39 AM, "Derek Chen-Becker" wrote:
What about renaming it Glass? Then we could add:
case class HalfFull[T](data : T) extends Glass[T]
type HalfEmpty[T] = HalfFull[T]
;)
Derek
On Sat, Dec 20, 2008 at 8:13 AM, TylerWeir wrote: > >
> Once people get Can...
--~
Speaking from personal experience, what I didn't realize to begin with
was that the can was what we in England call a tin, and the
connotation of "you can do something" is conceptually very different
to "a can (tin) contains x" if you follow my meaning...
I think the problem can be solved by
Between Can, Cup and Box ...Box makes most sense to me ... (I'm not
going to suggest Bottle :) ...)
Br's,
Marius
On 20 Dec, 18:19, Tim Perrett wrote:
> Speaking from personal experience, what I didn't realize to begin with
> was that the can was what we in England call a tin, and the
> conn
Can is more like Option but richer. Not much like Either.
On 20 Dec, 20:33, Oliver Lambert wrote:
> Is Can a little less like Option and more like scala.Either, where the
> left side is used to indicate failure?
>
> On 21/12/2008, at 1:43 AM, David Pollak wrote:
>
> > Folks,
>
> > Over the yea
Can has map, flatMap, filter etc. So it can be used in a for comphrension.
I don't believe Either has those methods. Further, Can has a bunch of
helpers to turn Empty into Failure
On Dec 20, 2008 10:33 AM, "Oliver Lambert" wrote:
Is Can a little less like Option and more like scala.Either, where
Ok so Can is not either an Either or an Option, its a Can. I kind of
wondered when I first used Can, and it was described as an enhanced
Option, why it wasn't called something like Option+ with None, Some
and Failure.
On 21/12/2008, at 5:47 AM, David Pollak wrote:
> Can has map, flatMap, f
Because Can is three letters and OptionPlus is 11 and a frequently used
construct should be easy on the fingers.
On Dec 20, 2008 11:15 AM, "Oliver Lambert" wrote:
Ok so Can is not either an Either or an Option, its a Can. I kind of
wondered when I first used Can, and it was described as an enhan
How about Result? e.g. something like,
sealed trait Result[+T]
case class Expected(t: T) extends Result[T]
case class Failure[T](msg: String) extends Result[T]
case object Empty extends Result[Nothing]
alex
--~--~-~--~~~---~--~~
You received this message because
Yup, when you chose the original name, you did a good job - why second
guess yourself now. Can we just leave it the way it is.
On 21/12/2008, at 6:25 AM, David Pollak wrote:
> Because Can is three letters and OptionPlus is 11 and a frequently
> used construct should be easy on the fingers.
>
Yes, but which is it: half empty or half full? You'd think at this stage
of development we could at least answer that old question.
Chas.
Derek Chen-Becker wrote:
> What about renaming it Glass? Then we could add:
>
> case class HalfFull[T](data : T) extends Glass[T]
> type HalfEmpty[T] = Half
I agree. I think Box is more cross-cultural and has no confusing
meanings (e.g. can = possible). But Tyler makes a good point. Really, it
should be called something like OptionWithFailure. And we should stop
trying to abbreviate everything (*maybe* OptionWFailure). After all, how
often do you
Generally, I agree, but not at the expense of understandability. And
about the only time I have to type it is as a result type when it can't
be inferred. The rest of the time I'm using Full() or Empty, which are
nice and short. Even Box, which I think is much better, requires
explaining. Optio
Perhaps we should rename Can to Option and get the Scala guys to
rename theirs, OptionWithoutFailure :)
On 21/12/2008, at 6:50 AM, Charles F. Munat wrote:
> OptionWithFailure
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goo
On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir wrote:
>
> Once people get Can, I think it makes sense, so I think we can leave
> it.
>
> As a replacement, I can't think of a good real-life example of a thing
> with a failure indicator that fits the bill. :)
>
> What about OptionWithFailure, OptionWF,
If I had it to do over, I'd call it Box... but the cost of change seems to
outweigh the benefit of change... Can it is.
Thanks for your input.
On Sat, Dec 20, 2008 at 12:49 PM, Matt Harrington wrote:
>
> On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir wrote:
> >
> > Once people get Can, I think it ma
If you want 3 letters "Opt" to show the relation with Option
If you want less "?" (question mark) but it's already used by
i18n/resourses bundles (but it could be changed from ?("my sentence
key") to $("my sentence key")). I'm haunted by Tony ;)
my 2 cents useless contribution
On Sat, Dec 20,
It took me a long time to understand what an Option what. Personally, Maybe
(Haskell) makes more sense to me. Perpetuating Option as a name is, IMHO,
less than optimal.
On Sat, Dec 20, 2008 at 1:08 PM, David Bernard
wrote:
>
> If you want 3 letters "Opt" to show the relation with Option
> If yo
On Sat, Dec 20, 2008 at 2:37 PM, Oliver Lambert wrote:
> Yup, when you chose the original name, you did a good job - why second
> guess yourself now. Can we just leave it the way it is.
>
Pun intended
As to my vote (if I'm allowed one)...
Can was slightly confusing, but looking at it vs O
I think that the previously mentioned "Box" would be the only other thing
that has
1. The same semantic meaning of "container". Well, as Tim pointed out
this is a US thing for Can...
2. The same brevity. I agree with David that commonly used constructs
should be short
If it was going
Result +1
Quite short, only one selfexplaining imo and describes the purpose it serves
well. The only downsides of this name is +3 characters and the fact that the
class could be used also as non result but for other purpose.
On Sun, Dec 21, 2008 at 3:32 PM, Derek Chen-Becker wrote:
> I think th
current signature :
def doStuff(arg1 : Can[Foo], arg2 : Toto) : Can[Bar]
With Result:
def doStuff(arg1 : Result[Foo], arg2 : Toto) : Result[Bar]
Result could be good but is not, when used for argument and not for "result"
more I think about it, more I thought ? was not so wrong/joke. In the
N
Personally I kind of like ? name ... although I feel many people will
not. Going further having Full and Empty extending ? may "lift"quite a
few eyebrows :)
BTW I totally agree that Result is not ok.
Br's,
Marius
On Dec 21, 7:45 pm, "David Bernard"
wrote:
> current signature :
> def doStuff(
If you want to use ? in your own code, you can always do:
type ?[T] = Can[T]
var s: ?[String] = Empty
s = Full("Hello, world!")
You can put it somewhere and import it anywhere you want to use it.
That said, I think it'd be a really bad idea to do this in Lift's source.
Scala gets enough c
I, too, like ?, but I agree that others may not. Could mean too many
things. But what about ??? instead? Or just two (??)? Or why not steal
Haskell's thunder and use Maybe?
Chas.
Marius wrote:
> Personally I kind of like ? name ... although I feel many people will
> not. Going further having F
IMO, and echo'ing jorge's comments, I *really* dont think using ? is a
good idea.
The rational of this being:
- Code that's littered with Can[MyType] is readable, compared with ?
[MyType] which would be confusing and non-obvious for new-commers.
- Using operands for such common operations / idi
In the spirit of LOLCode, I make the following proposal:
Can becomes Bukkit
Full becomes BukkitOf (or "Bukkit of" via some DSL like syntax)
Empty becomes Noob (or "Bukkit of Noob" via some DSL like syntax)
Failure becomes WTF?
val x : Bukkit[String] = WTF?(new RuntimeException("O NOES!"))
val
Josh Suereth wrote:
> In the spirit of LOLCode, I make the following proposal:
>
> Can becomes Bukkit
Just think though, a bit of pimping and...
object Can {
...
def has[T](t: T) = Full(t)
}
val gotz = Can has "cheezburger"
... which constitutes my vote for "keep Can" -- it's a comedic noun
Can isn't bad. On the one hand, it's a container, on the other hand
it's "can I do something", and in fact both work, barring the name of
Full and Empty.
It still feels weird. In my opinion it's trying to concretize
something abstract. Honestly, the best name for it might be something
like 'Maybe
David Pollak wrote:
> Folks,
>
> Over the year that Lift has had Can[T] as a replacement for Scala's
> Option[T], the name "Can" has required a lot of explaining.
I've never liked "Can" as a name; always thinking that the opposite of one
should be a "Can't". I'm sure it's my own issue to so
I know David has resigned to keeping 'Can', but wouldn't 'Jar' be an
alternative? That way Empty and Full still make sense...
Initially I thought 'Tin' sounded better but I recognise that term
wouldn't be as universal.
Marc
On 26/12/2008, at 4:14 AM, Michael Campbell wrote:
>
> David Polla
and "Pack" ?
On Fri, Dec 26, 2008 at 8:35 AM, Marc Boschma wrote:
>
> I know David has resigned to keeping 'Can', but wouldn't 'Jar' be an
> alternative? That way Empty and Full still make sense...
>
> Initially I thought 'Tin' sounded better but I recognise that term
> wouldn't be as universal.
"Bin"
"Slot"
"Ref"
Though, "Box" is short, self-explanatory and fills the other criterias
aswell.
Merry Christmas
/Viktor
On Fri, Dec 26, 2008 at 10:31 AM, Caoyuan wrote:
>
> and "Pack" ?
>
> On Fri, Dec 26, 2008 at 8:35 AM, Marc Boschma
> >
> wrote:
> >
> > I know David has resigned to keepin
If Maybe should be not used because of possible name clash in Scala library
then how about considering synonyms: Possible and Perhaps?
On Fri, Dec 26, 2008 at 10:31 AM, Caoyuan wrote:
>
> and "Pack" ?
>
> On Fri, Dec 26, 2008 at 8:35 AM, Marc Boschma
> >
> wrote:
> >
> > I know David has resig
Just brainstorming here... not sure if we're beating a dead horse... but
about Option3 to signify it has 3 states? (i.e. Some3, None3, Error3)
It's uglier but could be easier to explain and understand.
alex
On Fri, Dec 26, 2008 at 3:29 AM, Mateusz Fiołka wrote:
> If Maybe should be not used b
Funny thing is the first thought that came to mind here was a Cricket
Box :) (and not the KFC variety)
To close the season and thread with some humour:
I wanted to send some sort of Christmas (whoops I mean) holiday
greeting to my friends, but it is so difficult in today's world to
know ex
2008/12/26 Alex Boisvert
> Just brainstorming here... not sure if we're beating a dead horse... but
> about Option3 to signify it has 3 states? (i.e. Some3, None3, Error3)
>
> It's uglier but could be easier to explain and understand.
Personally, it took me a lot to get the concept of Option.
Summer solstice? SUMMER solstice? You hemisphere bigot! There you go
again, insulting half the planet...
(Back to the lawyers again... :-)
Chas.
Marc Boschma wrote:
> Funny thing is the first thought that came to mind here was a Cricket
> Box :) (and not the KFC variety)
>
> To close the se
Ha :), I really think you've let the Can out of the Box by raising
this thread. Don't we all get a vote?
After reading all the threads -
+1 Box
On 27/12/2008, at 10:06 AM, David Pollak wrote:
>
>
> 2008/12/26 Alex Boisvert
> Just brainstorming here... not sure if we're beating a dead
> hors
If we all get a say, I vote for "Trit" - after all, with Full, Empty and
Failure, aren't we talking about ternary logic?
Or does suggesting that make me a Twit?
Kris
On Sat, Dec 27, 2008 at 5:08 PM, Oliver Lambert wrote:
> Ha :), I really think you've let the Can out of the Box by raising this
I think this debate could go on for some time ;-)
Being pragmatic, we have to look at the impact on the lift code base
and its users. Would a change to Box[MyClass] really improve user
understanding and lower the learning curve to a point where making
such a fundamental change in the lift API wou
Good points. I'll make the changes today and check up the code. It'll be
massive code breakage... but for a good reason.
On Sun, Dec 28, 2008 at 6:41 AM, Tim Perrett wrote:
>
> I think this debate could go on for some time ;-)
>
> Being pragmatic, we have to look at the impact on the lift cod
Wonderful :)
On Sun, Dec 28, 2008 at 4:03 PM, David Pollak wrote:
> Good points. I'll make the changes today and check up the code. It'll be
> massive code breakage... but for a good reason.
>
>
> On Sun, Dec 28, 2008 at 6:41 AM, Tim Perrett wrote:
>
>>
>> I think this debate could go on for
And all my hopes for "Can has x" are gone...
Perhaps I'll make my own change in my lift app. :
import {Box => Bukkit}
On Sun, Dec 28, 2008 at 10:03 AM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:
> Good points. I'll make the changes today and check up the code. It'll be
> massive cod
lol - am I missing something josh? How does the "Box has x" semantic differ?
(if its a joke, my apologies! Its been a long day!!)
On 28/12/2008 15:46, "Josh Suereth" wrote:
> And all my hopes for "Can has x" are gone...
>
> Perhaps I'll make my own change in my lift app. :
>
> import {Box =>
First:
http://icanhascheezburger.com/2007/01/11/i-can-has-cheezburger-3/
Then:
http://lolcode.com/
Anyway, it's an internet meme that I found amusing. Every time I'm writing
"Can" in lift, I have to fight the urge to right "has" afterwords.
On Sun, Dec 28, 2008 at 1:26 PM, Tim Perrett wrote
One last suggestion... Promise with Fulfilled, Empty, and Broken (my
other suggestion of Blond, Brunette and Redhead didn't seem to make
it...).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post
On Sun, Dec 28, 2008 at 12:46 PM, stephen goldbaum <
stephen.goldb...@gmail.com> wrote:
>
> One last suggestion... Promise with Fulfilled, Empty, and Broken
It's Box and it's done.
> (my
> other suggestion of Blond, Brunette and Redhead didn't seem to make
> it...).
New members are moderate
"Promise" has a specific technical meaning in the context of concurrency.
See: http://en.wikipedia.org/wiki/Futures_and_promises
--j
On Sun, Dec 28, 2008 at 2:46 PM, stephen goldbaum <
stephen.goldb...@gmail.com> wrote:
>
> One last suggestion... Promise with Fulfilled, Empty, and Broken (my
>
Ah. Well, sorry I subjected you to that joke twice then (once was more
than enough)... I'm glad a decision's been made.
-Stephen
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group,
I know it's a fait accompli, but I just wanted to give a heads-up to
people who might eventually find themselves answering questions from
newcomers on whether or not Box deals with boxing/autoboxing/unboxing:
http://en.wikipedia.org/wiki/Object_type
I don't believe I saw this point mentioned in
Josh Suereth wrote:
> In the spirit of LOLCode, I make the following proposal:
It's ok to love LOLCode, etc just don't *LOVE* LOLCode.
--
Twitter: http://twitter.com/campbellmichael
--~--~-~--~~~---~--~~
You received this message because you are subscribed
Can is not an Option and to call it so in any way is an error of
misintegration. Indeed it would be an error to "replace Option with
Can" - they are completely different algebras. Either is kinded * -> *
-> * so cannot possible be isomorphic and cannot possibly have map,
flatMap etc (though it can
Tony,
Can (now Box) is not an Either.
David
On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris wrote:
>
> Can is not an Option and to call it so in any way is an error of
> misintegration. Indeed it would be an error to "replace Option with
> Can" - they are completely different algebras. Either is k
Right, that's what Oliver said and I was reinforcing it with deductive
reasoning. It is also not Option. It is something else altogether.
Nevertheless, an isomorphism can easily be written with Either alone
(ignoring bottoms). So in some loose sense "it is an Either".
--
Tony Morris
http://tmorr
It's an Option.
It contains a value or it doesn't. In the case that it does not contain a
value, it may contain out of band information. This is not any different
from None which contains information. It contains the information that it
lacks information.
Sure, you can write Option[T] as Eithe
No this is a mistake. Can is not an Option. Indeed it is (almost)
impossible to write Can using Option (if you are familiar with Peano
Arithmetic you will understand the need to qualify with almost). There
is an arrow from forall A. Can[A] to Option[A] but not from forall A.
Option[A] to Can[A] (e
It depends on what the meaning of "is" is.
If Option were not sealed, "Can" could be "implemented" as an Option... by
adding Failure and Empty as subclasses of None. In this (OO) sense, a Can is
an option.
In the algebraic sense, then you're probably right that a Can is not an
Option.
--j
On Tu
When talking about data types "is" means "is congruent to" or "is
isomorphic to". You are not free to use "is" arbitrarily, since if you
are then Can "is" anything I want it to be.
Since equivalence can be broken into an implication both ways e.g. A
-> B and B -> A then it is quite easy to test if
On Tue, Jan 6, 2009 at 11:23 PM, Tony Morris wrote:
> No this is a mistake. Can is not an Option. Indeed it is (almost)
> impossible to write Can using Option (if you are familiar with Peano
> Arithmetic you will understand the need to qualify with almost).
While you're right in a (very) narrowl
For most people, "is" does not always and exclusively mean "bi-implication".
You are free to think this way, if you choose, but please don't impose your
Language Police on us.
--j
On Tue, Jan 6, 2009 at 5:49 PM, Tony Morris wrote:
>
> When talking about data types "is" means "is congruent to" o
Do any conversions exist to treat a Box[_] as an
Either[Option[_],Exception] or as an Option[_]? Are there any helper
functions that lift could benefit from by having these?
Also, anytime I see the line "I leave this as an excercise to the
reader" I feel like I'm being lectured :)
On Jan 6
On Tue, Jan 6, 2009 at 5:27 PM, Josh Suereth wrote:
> Do any conversions exist to treat a Box[_] as an
> Either[Option[_],Exception] or as an Option[_]? Are there any helper
> functions that lift could benefit from by having these?
>
Box instances have a toOption method. Full -> Some, Empty/Fai
On Tue, Jan 6, 2009 at 3:49 PM, Tony Morris wrote:
> not an Option. It was not even close (lack of totality in this test is
> catastrophic).
Who cares?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
"related to a combination of Option and Either"
I'm not sure how I am missing that point since that is exactly the
code I provided earlier. There is no point, except to assist Oliver in
looking passed these fancy language tricks.
In a pragmatic and therefore, not very useful way, yes Can is like
Jorge Ortiz wrote:
> For most people, "is" does not always and exclusively mean
> "bi-implication". You are free to think this way, if you choose,
> but please don't impose your Language Police on us.
>
> --j
For most people, "is" means "is isomorphic to" when talking about data
types. Furthermor
Warren Henning wrote:
> On Tue, Jan 6, 2009 at 3:49 PM, Tony Morris
> wrote:
>> not an Option. It was not even close (lack of totality in this
>> test is catastrophic).
>
> Who cares?
>
> >
>
Oliver did when he asked me. I will be seeing him tomorrow in Sydney
where I can clarify any misunderstan
You're talking about algebraic data types.
The rest of us are discussing classes and inheritance.
When someone says that a Dog "is" an Animal, they clearly don't mean "is
isomorphic to".
--j
On Tue, Jan 6, 2009 at 6:46 PM, Tony Morris wrote:
>
> Jorge Ortiz wrote:
> > For most people, "is" do
And, by the way, squares and triangles are isomorphic (
http://en.wikipedia.org/wiki/Topological_isomorphism).
--j
On Tue, Jan 6, 2009 at 6:44 PM, Tony Morris wrote:
>
> "related to a combination of Option and Either"
> I'm not sure how I am missing that point since that is exactly the
> code I
Jorge Ortiz wrote:
> You're talking about algebraic data types.
>
> The rest of us are discussing classes and inheritance.
>
> When someone says that a Dog "is" an Animal, they clearly don't
> mean "is isomorphic to".
>
> --j
>
>
I will make one last ditch effort.
We are talking about Can and Opt
On Wed, Jan 7, 2009 at 1:22 AM, Tony Morris wrote:
>
> Jorge Ortiz wrote:
> > You're talking about algebraic data types.
> >
> > The rest of us are discussing classes and inheritance.
> >
> > When someone says that a Dog "is" an Animal, they clearly don't
> > mean "is isomorphic to".
> >
> > --j
72 matches
Mail list logo
