State of the Lambda #4 (
http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html) says you
can do:
ClassName::staticMethod
or
instanceName::instanceMethod
On Friday, November 2, 2012 5:50:37 PM UTC-5, Ricky Clarkson wrote:
I can't confirm right now but I'm pretty sure I've done
If you read the actual words in that document, a different story emerges:
For a reference to an instance method of an arbitrary object, the type to
which the method belongs precedes the delimiter, and the invocation's
receiver is the first parameter of the functional interface method:
On Friday, 2 November 2012 07:02:38 UTC+11, fabrizio.giudici wrote:
… I'm a little worried
about a possible proliferation of multiple, incompatible libraries. I'd be
interested in knowing why Google rejected the patches submitted by
Atlassian (I interpret their comment as the fact
On Tuesday, October 30, 2012 6:41:31 PM UTC-7, Cédric Beust ♔ wrote:
On a related note, I find it funny when people advocate Option because it
forces you to deal with null pointers instead of ignoring them and then
rant against checked exceptions because they force you to do exactly the
On Thu, 01 Nov 2012 22:30:43 +0100, Jed Wesley-Smith
jed.wesleysm...@gmail.com wrote:
We – and others – have tried to submit patches to Guava several times and
were basically met with a stone-wall, normally various excuses about some
internal thing or other, and then Kevin came out and
Dick, your person/address/zip example perfectly illustrates the benefit of
Option/Optional.
This is precisely the functionality that JDK8 is purposefully omitting and
that we are debating.
I wrote some optional flatMap adds-on for the latest JDK8 lambda build,
ported your person/address/zip
In hindsight, a simpler solution (with static import of custom toIterable
method) would be:
final ListString zips2 = new ArrayListString();
for (Person p : people) { for (Address a : toIterable(p.addressOption)) {
for (String z : toIterable(a.zipOption)) { zips2.add(z); } } }
--
You received
On Fri, 02 Nov 2012 21:12:07 +0100, clay claytonw...@gmail.com wrote:
In hindsight, a simpler solution (with static import of custom toIterable
method) would be:
final ListString zips2 = new ArrayListString();
for (Person p : people) { for (Address a : toIterable(p.addressOption)) {
for
With proper support it would be:
ListString zips2 =
people.flatMap(Person::addressOption).flatMap(Address:zipOption);
That might take a stubborn person a couple of minutes to understand
but after that even the most determined anti-flatmapper will be able
to curse, rewrite, fire the writer of but
On Fri, 02 Nov 2012 21:28:50 +0100, Ricky Clarkson
ricky.clark...@gmail.com wrote:
With proper support it would be:
ListString zips2 =
people.flatMap(Person::addressOption).flatMap(Address:zipOption);
This is better.
--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
We make Java
It's rare that you actually expose public fields in Java, so let's
assume addressOption and friends are methods, and then the method
reference syntax works fine.
Also, I said 'with proper support', regarding the returned collection
type. :) But sure, adding a .into wouldn't be too bad.
On Fri,
AFAIK,
You can't do ClassName::instanceMethod()
You have to do classInstance::instanceMethod()
So, even if getAddressOption() was an instance method, you would have to do
onePersonInstance::getAddressOption, and the method reference is bound to
that one instance which wouldn't fit with the
I can't confirm right now but I'm pretty sure I've done
ClassName::methodName in my experiments with FunctionalJava and Java 8.
Doesn't the State of the Lambda cover that too?
On Nov 2, 2012 6:54 PM, clay claytonw...@gmail.com wrote:
AFAIK,
You can't do ClassName::instanceMethod()
You have to
Dick, your person/address/zip example perfectly illustrates the benefit of
Option/Optional.
This is precisely the functionality that JDK8 is purposefully omitting and
that we are debating.
I've written some static function add-ons to support this optional flatMap
type use case and ported your
I found one interesting data point in the Optional-debate concerning
Optional's predecessor in Guava. It looks like Atlassian has built their
own Guava-addon/fork, adding pretty much all the things discussed in this
thread. The description https://bitbucket.org/atlassian/fugue/ reads:
Google's
Google's guava project is a solid utility library providing many useful
interfaces and utilities, and it is a very commonly added dependency for
most projects. Unfortunately, they have a strong NIH syndrome and are
somewhat half-pregnant when it comes to functional-programming. This
library
OK, I wrote Optionals for JDK8 which adds static functions map, flatMap,
and toIterable
http://pastebin.com/HZ1suSRt
(I would probably adjust the generics type boundaries if this was a serious
effort)
So that these work:
map(optObj, (o) - ...);
flatMap(optObj, (o) - ...);
for (T t :
It is unlikely that we will drop Option in favour of Optional in
Functional Java, as that would be a step backwards for the library if
Optional does not gain flatMap etc. There will almost certainly be a
compatibility layer.
As an aside, it's amazing how small an amount of code we're really
But you wouldn't lose any functionality at all, you would merely lose the
more convenient syntax
instead of class function syntax:
optObj.flatMap((a) - ...);
you would use external static function syntax:
flatMap(optObj, (a) - ...);
On Thursday, November 1, 2012 8:00:01 PM UTC-5, Ricky
That would be inconsistent with the other types in FJ. There's no
advantage to that over using Option other than compatibility with code
that uses Optional, for which a couple of conversions can be provided.
If they do it right then I would expect us to drop Option but FJ is
not the kind of
ok, the Brian Goetz responded to these concerns:
http://mail.openjdk.java.net/pipermail/lambda-dev/2012-October/006365.html
The JDK perspective makes sense now. These guys are definitely super smart
guys.
Probably I am missing something, but what I read is just: the goal is NOT
to
ok, the Brian Goetz responded to these concerns:
http://mail.openjdk.java.net/pipermail/lambda-dev/2012-October/006365.html
The JDK perspective makes sense now. These guys are definitely super smart
guys. Goetz's book on concurrency is great, and I apologize for suggesting
that the JDK authors
I agree on the ADT part, but I think it is only one of the three major
complaints brought up.
The other ones are:
- Is no collection/doesn't implement Iterable/Stream/...
- Is no monad/lacks map/filter/flatMap
It is certainly a bit confusing that he added ifPresent almost at the same
On second thought, I retract my last post.
If a there is a better design for a Java Optional that can be demonstrated
with pure reason, then the better design should be used.
This isn't about converting Java into another language, it's about making
optimal technical decisions and choosing
In hg changeset 6331:af4b2dd992d6 (build 62), Optional.map was removed
from the Lambda code. So they are moving in the opposite direction. Now
there are three important missing features: map, flatMap, and iteration.
Regarding Dick Wall's comments on episode #397
- Option's main advantage is
On Tue, Oct 30, 2012 at 12:09 PM, Simon Ochsenreither
simon.ochsenreit...@gmail.com wrote:
Not sure whether it helps people learning the language or the new APIs
when equivalent things are named differently throughout
implementations/interfaces...
Scala's choice of renaming Maybe to Option
On Tue, Oct 30, 2012 at 5:15 PM, clay claytonw...@gmail.com wrote:
- Option's main advantage is not avoiding NPE's, but factoring common
null-related conditional logic out of all your code and into a standard
library component.
Exactly. I expanded on this point
scala.xml is notoriously badly-designed and will likely be removed or
replaced (I could be out of date and it might already have been
rewritten). Daniel Spiewak's antixml appears to be the de facto
standard. Don't take it as typical Scala.
On Tue, Oct 30, 2012 at 9:15 PM, clay
On Tue, Oct 30, 2012 at 9:41 PM, Cédric Beust ♔ ced...@beust.com wrote:
On Tue, Oct 30, 2012 at 5:15 PM, clay claytonw...@gmail.com wrote:
- Option's main advantage is not avoiding NPE's, but factoring common
null-related conditional logic out of all your code and into a standard
library
I dislike exceptions because they're not referentially transparent
(they break f(x) == f(x)) like the gotos they are. That said, they're
handy sometimes.
As for pattern-matching, there's nothing inherently bad about it, but
usually or perhaps always with scala.Option, there's a better way of
On Tue, Oct 30, 2012 at 6:58 PM, Josh Berry tae...@gmail.com wrote:
What is wrong with pattern matching on the content of an option?
It's basically equivalent to testing against null: if there's an object, do
this, otherwise, do that.
It's sometimes (often?) unavoidable when you are dealing
On Tue, Oct 30, 2012 at 10:03 PM, Ricky Clarkson
ricky.clark...@gmail.com wrote:
As for pattern-matching, there's nothing inherently bad about it, but
usually or perhaps always with scala.Option, there's a better way of
writing code using HOFs.
So, in my example, what should I have done
On Tue, Oct 30, 2012 at 7:11 PM, Josh Berry tae...@gmail.com wrote:
On Tue, Oct 30, 2012 at 10:03 PM, Ricky Clarkson
ricky.clark...@gmail.com wrote:
As for pattern-matching, there's nothing inherently bad about it, but
usually or perhaps always with scala.Option, there's a better way of
On Tue, Oct 30, 2012 at 10:14 PM, Cédric Beust ♔ ced...@beust.com wrote:
It depends on the functions that you are calling in the Some and None cases:
if they belong to an external API, extracting the value is your only opt...
er... choice. However, if you are calling methods that you wrote,
You don't necessarily have to write methods that take Option, you can
write normal methods and lift them into Option with map. That's
generally better than writing methods that take Option but just return
None if the Option is None.
Josh's example needs fleshing out, it's not even clear whether
On Tue, Oct 30, 2012 at 10:28 PM, Ricky Clarkson
ricky.clark...@gmail.com wrote:
Josh's example needs fleshing out, it's not even clear whether he uses
the result of the pattern-matching or does it just for the
side-effects. That has a bearing on how I'd prefer to write it.
I'm converting to
Let's say this is the original with pattern-matching:
val s: String = option match {
case None = getValue
case Some(foo) = foo.asText
}
You could write this as:
val s: String = option.map(_.asText).orElse(getValue)
I might have misunderstood, it's just hit midnight and I've had a long
day.
On Tue, Oct 30, 2012 at 11:02 PM, Ricky Clarkson
ricky.clark...@gmail.com wrote:
Let's say this is the original with pattern-matching:
val s: String = option match {
case None = getValue
case Some(foo) = foo.asText
}
You could write this as:
val s: String =
On Tue, Oct 30, 2012 at 8:12 PM, Josh Berry tae...@gmail.com wrote:
Typing it, it occurs to me I could probably just skip the Option
entirely (Right? That just drops the Some from the two cases I
define.).
Yes, that was my reaction as well. There is little point in lifting a value
into
Scala's implicits clearly have some of the same drawback as C#'s extension
methods in that it can make code hard to understand and hard to read.
I haven't learned Scala's implicit feature well enough to comment on them
yet.
On Monday, October 29, 2012 12:01:59 PM UTC-5, Ricky Clarkson wrote:
On Tue, Oct 30, 2012 at 11:16 PM, Cédric Beust ♔ ced...@beust.com wrote:
On Tue, Oct 30, 2012 at 8:12 PM, Josh Berry tae...@gmail.com wrote:
Typing it, it occurs to me I could probably just skip the Option
entirely (Right? That just drops the Some from the two cases I
define.).
Yes, that
Personally, I think Java's approach is superior to extension methods,
because it ensures that dynamic dispatch looks like dynamic dispatch.
Allowing both static dispatch (via extension methods) and dynamic dispatch
(via standard method call) for the same syntactical representation is
confusing
C# Extension methods are mere syntactic sugar to convert this:
foo(o, args);
into this:
o.foo(args);
So what? I'm only interested in language/api features that have a basis in
serious logical reason and purpose.
Every Scala feature I listed earlier can be supported by reason and logic,
not
On Mon, Oct 29, 2012 at 7:35 AM, Simon Ochsenreither
simon.ochsenreit...@gmail.com wrote:
In my opinion, foo.bar(baz) should always invoke a method on type Foo,
not the compiler figures out whether Foo has such a method and if not
rewrites it to some static invocation of an extension method
Given that most programmers begin by doing theObject. and waiting for
their IDE to suggest methods, the C# approach is quite useful. The
Java 8 approach has some advantages, but it does lose the ability to
add methods to a third party/core type without being that third party
or Oracle, and in a
Java has always supported static dispatch looking like dynamic
dispatch.. instance.staticMethod(args), it's just deemed poor form. I
don't think erasure has any bearing on method resolution.
Are you a fan of Scala's implicit conversions? Those make it so that
foo.bar(baz) can really be
Hi Ricky,
Java has always supported static dispatch looking like dynamic
dispatch.. instance.staticMethod(args), it's just deemed poor form.
Of course. I just try to forget that as much as possible. :-) I don't think
there is any recent IDE which doesn't yell at you if you try to use this
This is the important question of this thread and it's not a technical
issue that a typical developer such as myself would have much utility with.
Ideally, this is where the more well connected and influential members of
the group, or even the Java Posse themselves, should comment.
This
We can only assume that they already considered it, looked at code-examples
and maybe decided that this is not the way they want people to write code
(similar to Guava).
This wouldn't be too bad in many languages, but even Java's planned
extension methods are designed in a way which prevents
Is there a legitimate complaint about the Java 8 virtual defender methods?
That seems like a great enhancement. I haven't heard any objections.
I understand that people will complain about everything. But with the
Option/flatMap/iteration issue, there is a very specific, technical,
articulate,
Sure, they don't let me add methods to types I don't control, i.e.,
they're not extension methods a la C#. I think they solve what
they're intended to solve reasonably well though.
On Sun, Oct 28, 2012 at 10:47 PM, clay claytonw...@gmail.com wrote:
Is there a legitimate complaint about the Java
On Friday, October 26, 2012 4:06:36 PM UTC-5, Roland Tepp wrote:
Instead of degenerating yet another thread into Java vs Scala debate
(which it starts getting dangerously close to), what would be the thoughts
on how we can actually influence Java 8 to have a proper Option type
instead of
On Fri, 26 Oct 2012 07:22:23 +0200, Cédric Beust ♔ ced...@beust.com
wrote:
What makes a great language designer is not the ability to implement
complicated pieces of the compiler but the simple ability to say No.
I mostly agree with this.
--
Fabrizio Giudici - Java Architect @ Tidalwave
It's worth mentioning some of what Scala says no to then.
Primitives
Static methods
Checked exceptions
Disjoint multiple constructors
null
Default mutable collections
Non-returning statements
Special-case syntax for string concatenation, catch blocks and Enums
It can't say no to null entirely,
Scala only really says 'not yet' to checked exceptions. If exceptions are
a good idea (debatable, they make you lose referential transparency) then
checked exceptions are a good idea, it's just that the syntax as in Java
causes problems and Scala wanted to wait until a better mechanism was found.
Using the latest lambda build, I just tried to write:
public class FixedOptionalT extends OptionalT implements Iterable
which may be arguably better than using one of the many existing excellent
independent implementations (Functional Java, Atlassian).
Unfortunately the none/empty constructor
Optional should really be a closed type, as it's basically an
algebraic datatype, something like:
abstract class OptionT {
private Option() { }
static final class NoneT extends OptionT { }
static final class SomeT extends OptionT { ... }
}
I would not expect it to be something you can
I prefer this algebraic data type design that is standard in every other
implementation of Option/Optional/Maybe (Scala, Haskell, F#, Functional
Java library, Atlassian's library, and even Guava)
However, as mentioned earlier, JDK 8's Optional is completely and
purposefully avoiding this, and
That can be abused to add a 2nd empty state, which can be tempting.
It's either here, not here or not here yet! I don't really mind
what the implementation is, but it should not be possible to add a
subtype as a third party.
https://github.com/JamesIry/jADT does quite well at generating
However, as mentioned earlier, JDK 8's Optional is completely and
purposefully avoiding this, and has Optional as more of a traditonal Java
class with a boolean flag.
Not wanting to have ADT doesn't mean the design has to be this poor. A
single static final, immutable NONE field + a some
Instead of degenerating yet another thread into Java vs Scala debate (which
it starts getting dangerously close to), what would be the thoughts on how
we can actually influence Java 8 to have a proper Option type instead of
this half-baked thing they have implemented atm.
BTW: I've actually
On Fri, 26 Oct 2012 22:53:55 +0200, Simon Ochsenreither
simon.ochsenreit...@gmail.com wrote:
Add to the list of Java language features not in Scala:
- Special cased arrays (e. g. in for loops) in the language spec
- Special syntax for defining, indexing and updating as well as fun
I'm sorry, but I feel I should point out that this contributes to the
academic/elite argument about Scala.
Isn't this argument getting boring after a while? I think it is sad that
academic is being used as a slander along the line of not being
practical.
Is there actual _any_ point
On Fri, 26 Oct 2012 23:41:35 +0200, Simon Ochsenreither
simon.ochsenreit...@gmail.com wrote:
I'm sorry, but I feel I should point out that this contributes to the
academic/elite argument about Scala.
Isn't this argument getting boring after a while? I think it is sad that
academic is
A better language design means fewer corner cases, fewer forward references
when learning and a higher signal to noise ratio in code.
Those are real things that real programmers benefit from. I don't get all
this nonsense about whether something is academic or not. Ask instead
whether it's
You spend a lot of text to tell me you have run out of arguments. :-)
--
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/-/6NaW4Q1rZlEJ.
To post to this group, send
On Fri, Oct 26, 2012 at 3:15 PM, Ricky Clarkson ricky.clark...@gmail.comwrote:
Those are real things that real programmers benefit from. I don't get all
this nonsense about whether something is academic or not. Ask instead
whether it's correct, whether it's useful, what it needs to be useful
Whenever you decide to add a complex feature to a language, you generate a
lot of material for papers that you can then submit to conferences. When
you don't have the inclination of publishing papers about your language,
you have much more freedom to refuse to add features (and one could
On Sat, 27 Oct 2012 00:45:42 +0200, Simon Ochsenreither
simon.ochsenreit...@gmail.com wrote:
It took me approximately 3 minutes to verify that this is non-sense. I
find
your assumption that the whole mailing list is too lazy or stupid to use
Google to get an overview of Scala-related papers
What on earth are you talking about? We discuss the quality of the
language, you say the quality is irrelevant, it's how it is in use. We
point out that those two things are linked, you say Scala doesn't sell.
Where will we go next on this tour of absurdities? Scala is slow?
Underscores are bad
You see, Scala doesn't have success because the world is so full of stupid
and lazy people. Gents, I declare myself the champion of stupidity and
laziness.
Sorry that I didn't reply to your other comment. I assumed that bringing up
the old but Java is more popular when debating
On Sat, 27 Oct 2012 01:20:40 +0200, Ricky Clarkson
ricky.clark...@gmail.com wrote:
What on earth are you talking about? We discuss the quality of the
language, you say the quality is irrelevant, it's how it is in use. We
point out that those two things are linked, you say Scala doesn't
On Sat, 27 Oct 2012 01:35:56 +0200, Simon Ochsenreither
simon.ochsenreit...@gmail.com wrote:
What's your point? I honestly don't see it. Should Java adopt more PHP
No - it shouldn't *add* things. It should *drop* things and get simpler.
Don't ask me which things to drop - I'm not a
On Fri, Oct 26, 2012 at 3:45 PM, Simon Ochsenreither
simon.ochsenreit...@gmail.com wrote:
Whenever you decide to add a complex feature to a language, you generate a
lot of material for papers that you can then submit to conferences. When
you don't have the inclination of publishing papers
I said *I* was, of course, but I think there's at least one more person in
the world who doesn't appreciate Scala; if I find even another one, and I
think I have some chances, well, three's a crowd, so we sounds
appropriate :-) After all, being the champion of a single-man team
Has anyone seen java.util.Optional in the new Lambda builds?
Yes.
Why is there no flatMap?
I asked it but received no meaningful answer.
Why does it not support iteration (can't do a for loop over an Optional)?
I asked it but received no meaningful answer. However I tried to do it
Some of the JDK developers have real talent, but this is completely
amateur.
I am sorry to say that I completely agree on that.
Maybe they just enjoy badly reinventing existing stuff so much, that they
want to repeat the glorious success of java.util.Logging?
--
You received this
Calling someone's efforts amateurish isn't always the best way of
persuading them to come round to your way of thinking.
--
You received this message because you are subscribed to the Google Groups Java
Posse group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe
On Thu, 25 Oct 2012 11:52:09 +0200, Mario Fusco mario.fu...@gmail.com
wrote:
... I received no meaningful answers.
Honestly, this is annoying. There's no meaning in having lambdas if the
library support lacks fundamental features - I don't know about the JDK
developers, but I trust a
Guava has no flatMap, and there it's deliberate so less likely to change
than in the core.
On Oct 25, 2012 7:26 AM, Fabrizio Giudici fabrizio.giud...@tidalwave.it
wrote:
On Thu, 25 Oct 2012 11:52:09 +0200, Mario Fusco mario.fu...@gmail.com
wrote:
... I received no meaningful answers.
On Thu, 25 Oct 2012 12:33:40 +0200, Ricky Clarkson
ricky.clark...@gmail.com wrote:
Guava has no flatMap, and there it's deliberate so less likely to change
than in the core.
As I said, there could be something else...
--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
We make Java
As I said, there could be something else...
Could be Guava or something else, but if Java 8 wants really do a step
toward the functional world, I honestly don't see why such a fundamental
(and let me say trivial) thing like an Option (and possibly an Either)
shouldn't be available in the
As I said, there could be something else...
Could be Guava or something else, but if Java 8 wants really do a step
toward the functional world, I honestly don't see why such a fundamental
(and let me say trivial) thing like an Option (and possibly an Either)
shouldn't be available in
On Thursday, October 25, 2012 5:48:30 AM UTC-5, Mario Fusco wrote:
... if Java 8 wants really do a step toward the functional world, I
honestly don't see why such a fundamental (and let me say trivial) thing
like an Option (and possibly an Either) shouldn't be available in the core
Java.
I don't see that as a reason that holds water at all. If the feature
is good and useful in Java code, there's no reason not to use it in
Java code. Whether it's in the core isn't interesting at all, but if
there's a crippled version in the core that's a shame, as users of a
better version might
If you take Option so seriously and are on the JVM, why not fully switch
over to Scala?
Let me reply to your question with another very simple question: how many
people in this mailing list, and more in general which percentage of the
developers in the world, are allowed to choose the
On Thu, 25 Oct 2012 16:33:40 +0200, Mario Fusco mario.fu...@gmail.com
wrote:
If you take Option so seriously and are on the JVM, why not fully switch
over to Scala?
Let me reply to your question with another very simple question: how many
people in this mailing list, and more in general
Not everyone [...] has a choice over what language gets used.
If people can't make ideal technical choices for political reasons, then
that is a political problem rather than a technical one.
I can't fault programmers who try to sneak useful or stimulating
technologies around the stifling
On Thu, Oct 25, 2012 at 9:21 AM, clay claytonw...@gmail.com wrote:
Today, JVM programmers are highly divided.
I'm not sure about that. Sure, if you read this mailing-list and you go to
conferences, it's very easy to get this impression because the community
you belong to is, by definition,
I have 'inflicted' Option on these people and not had any real problems.
On Thu, Oct 25, 2012 at 1:43 PM, Cédric Beust ♔ ced...@beust.com wrote:
On Thu, Oct 25, 2012 at 9:21 AM, clay claytonw...@gmail.com wrote:
Today, JVM programmers are highly divided.
I'm not sure about that. Sure, if
Sure, but that was not my point...
--
Cédric
On Thu, Oct 25, 2012 at 10:01 AM, Ricky Clarkson
ricky.clark...@gmail.comwrote:
I have 'inflicted' Option on these people and not had any real problems.
On Thu, Oct 25, 2012 at 1:43 PM, Cédric Beust ♔ ced...@beust.com wrote:
On Thu, Oct
That's ok, I wasn't making any counterpoint.
On Thu, Oct 25, 2012 at 2:27 PM, Cédric Beust ♔ ced...@beust.com wrote:
Sure, but that was not my point...
--
Cédric
On Thu, Oct 25, 2012 at 10:01 AM, Ricky Clarkson ricky.clark...@gmail.com
wrote:
I have 'inflicted' Option on these people
We need to stop not fighting, it's boring.
--
Cédric
On Thu, Oct 25, 2012 at 10:28 AM, Ricky Clarkson
ricky.clark...@gmail.comwrote:
That's ok, I wasn't making any counterpoint.
On Thu, Oct 25, 2012 at 2:27 PM, Cédric Beust ♔ ced...@beust.com wrote:
Sure, but that was not my point...
On Thu, 25 Oct 2012 18:21:50 +0200, clay claytonw...@gmail.com wrote:
Option is not a Scala thing, [it] is a micro-design pattern
Today, JVM programmers are highly divided. It's not a perfect summary,
but
I would broadly categorize into two groups: those that want all the Scala
features
On Thu, Oct 25, 2012 at 10:58 AM, Fabrizio Giudici
fabrizio.giud...@tidalwave.it wrote:
2. Option is not a Scala thing, is a micro-design pattern. I could like it
or not, but being a pattern I think I shouldn't see it at all, or see in all
the languages I like.
I think this is a key
On Thu, 25 Oct 2012 20:28:49 +0200, Josh Berry tae...@gmail.com wrote:
On Thu, Oct 25, 2012 at 10:58 AM, Fabrizio Giudici
fabrizio.giud...@tidalwave.it wrote:
2. Option is not a Scala thing, is a micro-design pattern. I could like
it
or not, but being a pattern I think I shouldn't see it at
Option is a type born to support some constructs,
such as avoiding null.
That's just as correct as saying that array is a type born to support
some constructs, such as avoiding declaring 10 variables. I.e., it's
not correct.
Both Option.none and null can be used to denote that an item is not
This is not an answer. It is avoiding an answer.
neljapäev, 25. oktoober 2012 17:00.49 UTC+3 kirjutas clay:
On Thursday, October 25, 2012 5:48:30 AM UTC-5, Mario Fusco wrote:
... if Java 8 wants really do a step toward the functional world, I
honestly don't see why such a fundamental (and
On Thu, 25 Oct 2012 20:59:21 +0200, Ricky Clarkson
ricky.clark...@gmail.com wrote:
Option is a type born to support some constructs,
such as avoiding null.
That's just as correct as saying that array is a type born to support
some constructs, such as avoiding declaring 10 variables. I.e.,
On Thursday, October 25, 2012 1:15:31 PM UTC-5, fabrizio.giudici wrote:
I think I'm not fully understanding this. For the record, I'm definitely
not a Scala fan, and I definitely don't want all the Scala features in
Java, but I'd like to be able to use Option with the least effort.
1 - 100 of 103 matches
Mail list logo
