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 crap about operators already, we shouldn't be adding any
more, especially not one for something so widely used as Can.
--j
2008/12/21 Marius <[email protected]>
>
> 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" <[email protected]>
> wrote:
> > 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
> > Nice language (a old competitor to scala) ? was used to mark value to
> > be potentially null
> >
> > var myVar1 : ?String //myVar1 could be null
> > var myVar2 : String //myVar2 is never null
> >
> > With ?:
> > def doStuff(arg1 : ?[Foo], arg2 : Toto) : ?[Bar]
> >
> > On Sun, Dec 21, 2008 at 17:42, Mateusz Fiołka <[email protected]>
> wrote:
> > > 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 <
> [email protected]>
> > > wrote:
> >
> > >> I think that the previously mentioned "Box" would be the only other
> thing
> > >> that has
> >
> > >> The same semantic meaning of "container". Well, as Tim pointed out
> this is
> > >> a US thing for Can...
> > >> The same brevity. I agree with David that commonly used constructs
> should
> > >> be short
> >
> > >> If it was going to change at all, this would be it.
> >
> > >> Derek
> >
> > >> On Sat, Dec 20, 2008 at 11:13 PM, Josh Suereth <
> [email protected]>
> > >> wrote:
> >
> > >>> On Sat, Dec 20, 2008 at 2:37 PM, Oliver Lambert <[email protected]>
> 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 Option makes a lot
> of
> > >>> sense. Option is also slightly confusing, because I expected it to
> behave
> > >>> like Either. Either is a great name, as you can tell what it's
> doing.
> >
> > >>> Result seems ok, but I would vote for something more like Storage.
> Can
> > >>> is pretty succinct, and once you know how to use it, it's not hard to
> > >>> remember the convention.
> >
> > >>> So I'd swing on the side of sticking with Can unless a really good
> name
> > >>> is discovered.
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
