Is there a ScalaPosse somewhere ? :-)
--
You received this message because you are subscribed to the Google Groups Java
Posse group.
To view this discussion on the web visit
https://groups.google.com/d/msg/javaposse/-/3OUQVLJJVXcJ.
To post to this group, send email to
On Monday, June 4, 2012 5:09:43 PM UTC+2, KWright wrote:
This now has alarm bells going off in my head. These (as described) would
only make sense if specified at both declaration AND use site, that's an
awful lot of boilerplate and ceremony to be added! We already tried the
same thing
On 5 June 2012 11:05, Reinier Zwitserloot reini...@gmail.com wrote:
On Monday, June 4, 2012 5:09:43 PM UTC+2, KWright wrote:
This now has alarm bells going off in my head. These (as described)
would only make sense if specified at both declaration AND use site, that's
an awful lot of
http://scalatypes.com/
Not as much fun as the Posse though. ;-)
On Tuesday, June 5, 2012 6:23:06 PM UTC+10, Jan Goyvaerts wrote:
Is there a ScalaPosse somewhere ? :-)
--
You received this message because you are subscribed to the Google Groups Java
Posse group.
To view this discussion on
But... that *is* ScalaTypes ! I meant anything *else* than ScalaTypes. :-)
On Tue, Jun 5, 2012 at 1:24 PM, Charles O'Farrell charl...@gmail.comwrote:
http://scalatypes.com/
Not as much fun as the Posse though. ;-)
On Tuesday, June 5, 2012 6:23:06 PM UTC+10, Jan Goyvaerts wrote:
Is there
What about Objective-C's treatment of nil (or NIL). In Objective-C,
messages cannot be overloaded; the argument types and return type are fixed
on first declaration. The same message can be sent to instances of any
class, of course. The system then ignores messages sent to nil: Assuming
That sounds terrible. How do you work out the original source of nil?
On Jun 5, 2012 9:44 AM, Eric Jablow erjab...@gmail.com wrote:
What about Objective-C's treatment of nil (or NIL). In Objective-C,
messages cannot be overloaded; the argument types and return type are fixed
on first
On 6/06/12 12:46 AM, Ricky Clarkson wrote:
That sounds terrible. How do you work out the original source of nil?
You don't. I've heard from several people that this is the worst thing
about writing iOS apps, or Objective-C in general. Silent, delayed,
untraceable null errors.
--
You
On Tue, Jun 5, 2012 at 5:51 AM, Mark Derricutt m...@talios.com wrote:
You don't. I've heard from several people that this is the worst thing
about writing iOS apps, or Objective-C in general. Silent, delayed,
untraceable null errors.
JQuery does the same thing: selectors return arrays of
On Tue, Jun 5, 2012 at 10:57 AM, Cédric Beust ♔ ced...@beust.com wrote:
JQuery does the same thing: selectors return arrays of matching elements,
but if no elements were found, you receive an empty array instead of null.
Anyone who thinks this is a better idea hasn't practically worked with the
There is value in being *able* to go from null to null (or nil to nil or
None to None). The problem is when it's unintentional and that's what
we're saying is bad in JQuery and Objective-C, that there's no visual cue
that you might be operating on a nil.
Instead you see a nil 5 miles away in
On Tue, Jun 5, 2012 at 8:13 AM, Ricky Clarkson ricky.clark...@gmail.comwrote:
There is value in being *able* to go from null to null (or nil to nil or
None to None). The problem is when it's unintentional and that's what
we're saying is bad in JQuery and Objective-C, that there's no visual
Curious if the the originally planned coin null-safe method invocation
feature **for Java 7 **comes in to play on this discussion?
Eric
Reference:
- http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/47.html**
- http://metoojava.wordpress.com/2010/11/15/java-7-awesome-features/
On
If you unbox the Option then you don't have an Option any longer and can't
really blame Option for what happens next. Option gives you the same
choices plus can be used in for-comprehensions like any other monad.
On Jun 5, 2012 12:29 PM, Cédric Beust ♔ ced...@beust.com wrote:
On Tue, Jun 5,
On Tue, Jun 5, 2012 at 9:18 AM, Ricky Clarkson ricky.clark...@gmail.com
wrote:
Option gives you the same choices
How do I get Option to blow up if I try to map on a None?
--
Cédric
--
You received this message because you are subscribed to the Google Groups Java
Posse group.
To post to
On Tue, Jun 5, 2012 at 11:29 AM, Cédric Beust ♔ ced...@beust.com wrote:
On Tue, Jun 5, 2012 at 8:13 AM, Ricky Clarkson ricky.clark...@gmail.com
wrote:
There is value in being *able* to go from null to null (or nil to nil or
None to None). The problem is when it's unintentional and that's
Just call .get on the thing, it'll go bang fast enough :)
Often though, that simply isn't what you want. If I'm running some form of
5 hour long big data / batch processing task and it goes bang on item
38,976 / 39,207 then I am *NOT* going to be happy.
Going bang really isn't your friend if
I'm pretty much with Rick and Cédric on this topic...
On Tue, 05 Jun 2012 18:42:57 +0200, Kevin Wright
kev.lee.wri...@gmail.com wrote:
Going bang really isn't your friend if processing large data sets.
Especially if you're processing them in parallel, even more especially
if
the
That's one reason why many batch processing systems have ways of rerunning
parts of a job.
If you design the system for it, of course it could continue processing and
then raise some alert pointing at the problem data.
If you haven't yet considered this failure mode though it's probably best
to
On Tue, Jun 5, 2012 at 9:42 AM, Kevin Wright kev.lee.wri...@gmail.comwrote:
Going bang really isn't your friend
This is like saying having bugs is not your friend.
Well, doh. The question is not about having bugs or not, it's about
detecting them as soon as possible.
--
Cédric
--
You
On Tue, Jun 5, 2012 at 3:12 PM, Cédric Beust ♔ ced...@beust.com wrote:
On Tue, Jun 5, 2012 at 9:42 AM, Kevin Wright kev.lee.wri...@gmail.com
wrote:
Going bang really isn't your friend
This is like saying having bugs is not your friend.
Well, doh. The question is not about having bugs or
On Tue, 05 Jun 2012 21:48:09 +0200, Josh Berry tae...@gmail.com wrote:
It is easy to contrive the situation where you don't want something to
just go bang on the first error, though. Does anyone like the
scenario where you get an error and fix it, only to be shown a new
error that could have
On Tue, Jun 5, 2012 at 3:55 PM, Fabrizio Giudici
fabrizio.giud...@tidalwave.it wrote:
It's easy to contrive that situation too, thinking of a consequentiality so
that the second error only happens in consequence of the previous one, or it
will happen only after you fix the previous one :-)
On 6/06/12 2:57 AM, Cédric Beust ? wrote:
JQuery does the same thing: selectors return arrays of matching
elements, but if no elements were found, you receive an empty array
instead of null. Anyone who thinks this is a better idea hasn't
practically worked with the concept.
Failing fast
My 0.02c, FWIW.
I have found using a variant of the Option notion quite satisfying in some
use cases. In my case we use Nat Price's Maybe for Java, but it's
essentially equivalent[1]. (I'll use the term Option here for consistency,
though the API of the two things are not the same)
What I have
On Tue, Jun 5, 2012 at 1:20 PM, Mark Derricutt m...@talios.com wrote:
On 6/06/12 2:57 AM, Cédric Beust ♔ wrote:
JQuery does the same thing: selectors return arrays of matching elements,
but if no elements were found, you receive an empty array instead of null.
Anyone who thinks this is a
This is the existing behaviour in scala:
val m = Map(1-a, 2-b)
m(1) // a
m.get(1) // Some(a)
m(3) // Exception!
m.get(3) // None
For indexed collections (anything subclassing Seq), you can achieve the
same by using the lift method.
val xs = Seq(a, b, c, d)
xs(1) // a
xs lift 1 // Some(a)
You can use *any* collection type if you want, just be careful to guard
against mutation and not allow it to grow beyond one element. That said,
Arrays offer the best performance if taking this approach (no boxing of
primitives!).
Nat Price's solution does offer some nice extra goodies though,
On Tue, 05 Jun 2012 22:28:41 +0200, Cédric Beust ♔ ced...@beust.com
wrote:
In an ideal world, the default case never crashes (empty collections) but
the language gives me a way to crash immediately if I receive
null/None/Nothing (without me having to explicitly test for it).
In my own
On Tue, Jun 5, 2012 at 2:11 PM, Kevin Wright kev.lee.wri...@gmail.comwrote:
Nat Price's solution does offer some nice extra goodies though,
`otherwise` is very handy for providing default values
Providing default values seems to be antithetical to Option, though. What's
the point of creating
On 5 June 2012 20:55, Fabrizio Giudici fabrizio.giud...@tidalwave.itwrote:
On Tue, 05 Jun 2012 21:48:09 +0200, Josh Berry tae...@gmail.com wrote:
It is easy to contrive the situation where you don't want something to
just go bang on the first error, though. Does anyone like the
scenario
I have a Seq[Option[String]], let's say the values are surnames to be used
in a mail merge. If we don't know the surname then we just want to print
an empty string in its place:
val surnames: Seq[Option[String]] = ...
val default =
val surnamesForMerge = surnames map {_ getOrElse default}
I
val surnames: Seq[String] = ...
val page1 = surnames filter {_.head.toLower == 'a'} take 50
val page1uc = page1 map {_.toUpperCase}
It doesn't matter if surnames is empty, or no entry starts with the letter
'a', or if less than 50 entries map. It all just works and flows
effortlessly with no
Kotlin looks nice. Best java replacement contender I've seen so far.
I do think it could benefit from a bit more syntactic sugar (like
array/map literals, null should evaluate to false) though….
On Sun, Jun 3, 2012 at 10:21 PM, Cédric Beust ♔ ced...@beust.com wrote:
On Sun, Jun 3, 2012 at 9:19
As I mentioned on Google+ the other day after listening to this
episode,one of the best things that Smalltalk offered with its optional
system was/is the ifNil:/ifNotNil: and isNil:/isNotNil messages ( Nil is
an Object in its own right, and offers negative variations of the four
messages) .
Well, It's late, and I'm tired, and I haven't read the rest of this post
yet, so I am sure some of this has been answered. In brief though.
Option is absolutely a static type solution to the problem. Option[String]
is not a String. You can't do o.charAt(1) on an Option[String], but you can
do
I'd say the only reason its not a static solution to the nullable types
issue is you're example can still easily fail:
a = null;
for (p - person, a - p.address, z - a.zipCode) yield zipCode
BLAMO - NPE :-)
On 6/06/12 4:49 PM, Dick Wall wrote:
Well, It's late, and I'm tired, and I
Hi Dick,
Thanks for taking the time to jump in.
A few thoughts:
Option is absolutely a static type solution to the problem. Option[String]
is not a String.
This was my point: if it's okay to change types, then it's hard to pretend
that Option is a revolutionary improvement over what we
38 matches
Mail list logo
