ollowing macro I wrote, which is an upgraded version of
> spec/keys:
>
> (ns myns
> (:refer-clojure :exclude [keys])
> (:require
> [clojure.set :as set]
> [clojure.core :as core]
> [clojure.spec.alpha :as spec]))
>
> (defmacro keys
> "Same as `clo
version
> of *spec/keys*:
>
> (ns myns
> (:refer-clojure :exclude [keys])
> (:require
> [clojure.set :as set]
> [clojure.core :as core]
> [clojure.spec.alpha :as spec]))
>
> (defmacro keys
> "Same as `clojure.spec/keys`, but accepts additional bool
is an upgraded version
of *spec/keys*:
(ns myns
(:refer-clojure :exclude [keys])
(:require
[clojure.set :as set]
[clojure.core :as core]
[clojure.spec.alpha :as spec]))
(defmacro keys
"Same as `clojure.spec/keys`, but accepts additional boolean option
:additional-keys. U
How to write and validation Boolean (Yes/No) in clojure
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
http://blog.klipse.tech/lambda/2016/07/24/lambda-calculus-2.html
The purpose of this article is to show how we represent boolean values in
lambda calculus. And to show the code of the basic boolean operations:
negation, conjunction and disjunction a.k.a not,and and or.
--
You received
Having a bit of a problem implementing the IAtom interface in a record.
Specifically, this is the signature giving me grief:
boolean compareAndSet(Object oldv, Object newv);
This isn't the answer:
(^boolean compareAndSet [oldv newv] ... )
I get "Can't define method not in inter
Forgot the this parameter. Sorry. Please ignore. :-(
On Wednesday, February 3, 2016 at 3:18:34 PM UTC-5, William la Forge wrote:
>
> Having a bit of a problem implementing the IAtom interface in a record.
> Specifically, this is the signature giving me grief:
>
> boolean compa
(swap! data-atom
(fn [data]
(lset! lens data (f (lget lens data) arg)
(swap [this f arg1 arg2]
(swap! data-atom
(fn [data]
(lset! lens data (f (lget lens data) arg1 arg2)
(swap [this f x y args]
(swap! data-atom
(fn [dat
On Feb 3, 2016 2:18 PM, "William la Forge" <laforg...@gmail.com> wrote:
>
> Having a bit of a problem implementing the IAtom interface in a record.
Specifically, this is the signature giving me grief:
>
> boolean compareAndSet(Object oldv, Object newv);
>
> Th
m interface in a record.
> Specifically, this is the signature giving me grief:
> >
> > boolean compareAndSet(Object oldv, Object newv);
> >
> > This isn't the answer:
> >
> > (^boolean compareAndSet [oldv newv] ... )
> >
>
> ^Boolean?
>
&
you're missing the `this` argument in the argvec.
(compareAndSet [this oldv newv] ..)
the boolean type hint shoulnd't be necessary.
On Wed, Feb 3, 2016 at 8:18 PM, William la Forge <laforg...@gmail.com> wrote:
> Having a bit of a problem implementing the IAtom interface in
Hello,
IM working at the Iloveponies github tutorial and Im stuck here,
I have to check if x is a nil or false and then the output must be false,\
Otherwise I have to be true.
So I tried this :
(defn boolean [x]
(if (and (nil? x) (false? x))
)
But then I see a very long error message
Hello,
You miss one parentheses at the end of your expression
(defn boolean [x]
(if (and (nil? x) (false? x))
))
cheers,
stan.
On Thursday, April 17, 2014 9:11:13 AM UTC+2, Roelof Wobben wrote:
Hello,
IM working at the Iloveponies github tutorial and Im stuck here,
I have to check
this :
(defn boolean [x]
(if (and (nil? x) (false? x))
)
But then I see a very long error message:
xception in thread main java.lang.RuntimeException: EOF while reading,
starting at line 4,
compiling:(i_am_a_horse_in_the_land_of_booleans.clj:30:1)
at clojure.lang.Compiler.load
Stanislas Nanchen stanislas.nanc...@gmail.com writes:
You miss one parentheses at the end of your expression
(defn boolean [x]
(if (and (nil? x) (false? x))
))
And now you have an if without then which will give you another
exception. And the test expression is a contradiction, i.e
Op donderdag 17 april 2014 09:34:52 UTC+2 schreef Tassilo Horn:
Stanislas Nanchen stanisla...@gmail.com javascript: writes:
You miss one parentheses at the end of your expression
(defn boolean [x]
(if (and (nil? x) (false? x))
))
And now you have an if without then which
some real
boolean, then there's already clojure.core/boolean.
In this exercise you are not allowed to use boolean.
Ah, ok, then it makes sense. :-)
Bye,
Tassilo
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email
On Apr 17, 2014, at 02:34 , Tassilo Horn t...@gnu.org wrote:
And now you have an if without then which will give you another
exception.
Not true. It's more common to use 'when', but single-branch ifs are perfectly
fine.
--
You received this message because you are subscribed to the Google
Op donderdag 17 april 2014 13:26:35 UTC+2 schreef Michael Gardner:
On Apr 17, 2014, at 02:34 , Tassilo Horn ts...@gnu.org javascript:
wrote:
And now you have an if without then which will give you another
exception.
Yep, but that one I solved already.
Not true. It's more
Michael Gardner gardne...@gmail.com writes:
And now you have an if without then which will give you another
exception.
Not true. It's more common to use 'when', but single-branch ifs are
perfectly fine.
Yes, but that was a zero-branch if, and that's not ok.
Bye,
Tassilo
--
You received
On Apr 17, 2014, at 07:38 , Tassilo Horn t...@gnu.org wrote:
Michael Gardner gardne...@gmail.com writes:
And now you have an if without then which will give you another
exception.
Not true. It's more common to use 'when', but single-branch ifs are
perfectly fine.
Yes, but that was a
Awesome turnaround, Thanks.
I was kinda worried I was nuts or about to do some urandom debugging.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are
time and was working
through the examples on github. I noticed that all the values that use
gen/boolean are returning false. I never get a true.
At the extreme end, the following never returns when run in the repl:
(gen/sample (gen/such-that true? (gen/list gen/boolean)))
I'm using
I decided to play with simple-check for the first time and was working
through the examples on github. I noticed that all the values that use
gen/boolean are returning false. I never get a true.
At the extreme end, the following never returns when run in the repl:
(gen/sample (gen
On Saturday, January 25, 2014 10:03:13 PM UTC+1, Michael Daines wrote:
I decided to play with simple-check for the first time and was working
through the examples on github. I noticed that all the values that use
gen/boolean are returning false. I never get a true.
At the extreme end
(using Field.get()) a Boolean that for clojure
will be always false.
In order to solve this issue I created the follow fn:
(defn- get-val
[^java.lang.reflect.Field f instance]
(let [value (.get f instance)]
(if (instance? java.lang.Boolean value)
(boolean
Hey Devs,
I have fighting against an issue that can summarized in the following line:
user= (not (new java.lang.Boolean false))
false
Is that behavior correct?
Because if I run:
user= (type false)
java.lang.Boolean
Can someone help me to understand it?
Thanks,
--
Bauna
--
--
You received
Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for speed
reasons (I think) anything that checks for truthiness uses java's ==, which
will fail on any new Boolean object. Usually, this isn't a problem, but
sometimes it is. You can see that this assumption is pervasive by looking
Gary Trakhman gary.trakh...@gmail.com writes:
Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for speed
reasons (I think) anything that checks for truthiness uses java's ==, which
will fail on any new Boolean object. Usually, this isn't a problem, but
sometimes it is. You
are Boolean/FALSE and Boolean/TRUE, and for
speed
reasons (I think) anything that checks for truthiness uses java's ==,
which
will fail on any new Boolean object. Usually, this isn't a problem, but
sometimes it is. You can see that this assumption is pervasive by
looking
at the implementations
!
On Thu, May 23, 2013 at 9:00 PM, Michał Marczyk
michal.marc...@gmail.comwrote:
On 23 May 2013 18:30, atkaaz atk...@gmail.com wrote:
when you say the word false I'm assuming you're referring to false?
the
function (not false the boolean value), otherwise I don't understand
I mean false
Thank you, I see it now. Based on your comment I actually took at look at
the source code for every? (haven't checked it before, oddly enough)
= (source every?)
(defn every?
Returns true if (pred x) is logical true for every x in coll, else
false.
{:tag Boolean
:added 1.0
:static true
?
Returns true if (pred x) is logical true for every x in coll, else
false.
{:tag Boolean
:added 1.0
:static true}
[pred coll]
(cond
(nil? (seq coll)) true
(pred (first coll)) (recur pred (next coll))
:else false))
nil
I thought that by coll in the doc they meant coll
On Fri, May 24, 2013 at 1:25 PM, atkaaz atk...@gmail.com wrote:
It kinda makes sense except I wouldn't have expected that on the map it
would return a vector (but then how else could it return both key and value
right? ) so everyone expects the input to the pred would be a vector
when passed
Whether (false 1) or (false true) is truthy is irrelevant. What
matters is that false returns truthy values when called with any
members of [], which is of course the case, as [] has no members. (For
it not to be the case, there would have to exist an x in [] for which
(false x) were not truthy --
when you say the word false I'm assuming you're referring to false? the
function (not false the boolean value), otherwise I don't understand
so like: What matters is that *false?* returns truthy values when called
with any members of []
makes sense to me.
So all I was saying above
On Thu, May 23, 2013 at 11:30 AM, atkaaz atk...@gmail.com wrote:
So all I was saying above is that it should throw when [] is empty just as
it does when [] is not empty, but it doesn't throw when empty because it's
never called (by it i mean false not false?)
This sort of behavior is handy
A while back I saw some java slides that elude me now, they mentioned
approaches to safety like defensive copying, immutability, etc.. their
conclusion at the end, that I seem to remember, was it only really made
sense to validate user input, a sort of wall, where anything past the wall
is
On 23 May 2013 18:30, atkaaz atk...@gmail.com wrote:
when you say the word false I'm assuming you're referring to false? the
function (not false the boolean value), otherwise I don't understand
I mean false-the-Boolean-value.
To rephrase the point I was making previously, (false x) is a truthy
(not false the boolean value), otherwise I don't understand
I mean false-the-Boolean-value.
To rephrase the point I was making previously, (false x) is a truthy
value for any x in [] is a true sentence, indeed trivially so because
[] is empty. Thus (every? false []) returning true totally makes
?
the
function (not false the boolean value), otherwise I don't understand
I mean false-the-Boolean-value.
To rephrase the point I was making previously, (false x) is a truthy
value for any x in [] is a true sentence, indeed trivially so because
[] is empty. Thus (every? false []) returning true totally
OK long time lurker here. I've been growing in my Clojure strength for a
while now. For the most part I think I get it and I have no problem getting
programs to do what I want. However, sometimes I get stumped.
I have one function that produces a list of booleans like '(false false
true). It
Using a lambda seems to be a sane approach -
(reduce #(and %1 %2) '(false false true))
;= false
On Wed, May 22, 2013 at 5:36 AM, Peter Mancini pe...@cicayda.com wrote:
OK long time lurker here. I've been growing in my Clojure strength for a
while now. For the most part I think I get it and I
Using eval should be a rarity.
I'd use (every? identity [false false true]) to do a reduce-and, and I'd
use (some identity [false false true]) to do a reduce-or (keeping in mind
the latter actually returns nil rather than false).
--
--
You received this message because you are subscribed to
The reason and is a macro is that it's designed to short-circuit - ie if
the first result is false the rest shouldn't even be evaluated.
Using it on raw booleans works, because booleans evaluate to themselves,
but it's really designed to be given forms.
The absence of a pure function for
On Wed, May 22, 2013 at 3:06 AM, Peter Mancini pe...@cicayda.com wrote:
I noticed that '(nil nil true) will cause and to produce false, so I am
aware of that edge case. Anything else I should be aware of?
What about the other edge?
user= (reduce #(and %1 %2) '(1 true 2))
2
user= (eval (conj
I find the wording of this confusing otherwise it returns the value
of the last
expr. (and) returns true.
I mean, I know it returns the last true value, but that's because I've
tested it not because the doc is trying(failing) to tell me so with that
phrase.
On Wed, May 22, 2013 at 1:28 PM,
On May 22, 2013 5:35 AM, atkaaz atk...@gmail.com wrote:
I find the wording of this confusing otherwise it returns the value of
the last expr. (and) returns true.
I mean, I know it returns the last true value, but that's because I've
tested it not because the doc is trying(failing) to tell me so
Oh i see now, thank you!
so it's like this:
otherwise it returns the value of the last expression.
(and) returns true.
i though expr. is the short for of the word expression which requires a
dot, but the dot was in fact an end of sentence.
On Wed, May 22, 2013 at 2:40 PM, John D. Hume
On 22 May 2013 08:09, Baishampayan Ghose b.gh...@gmail.com wrote:
Using a lambda seems to be a sane approach -
(reduce #(and %1 %2) '(false false true))
;= false
Note that this will always traverse the entire input collection,
whereas every? stops at the first false value.
Same thing goes
Thanks everyone for the help. The nil behavior of the 'or' version breaks
what I wanted, but I may create functions that return just true or false
though the odd edge case where and will return a value will mean I'll
have to handle that. My preference would be to throw an exception but thats
On 22/05/13 15:54, Peter Mancini wrote:
The nil behavior of the 'or' version breaks what I wanted, but I may
create functions that return just true or false though the odd edge
case where and will return a value will mean I'll have to handle that.
wrap that call in a 'boolean' call (e.g
wanted, but I may
create functions that return just true or false though the odd edge
case where and will return a value will mean I'll have to handle that.
wrap that call in a 'boolean' call (e.g. (boolean (or ...))) and you got
your true/false result :)
Jim
--
--
You received
On Wed, May 22, 2013 at 12:14 AM, Chris Ford christophertf...@gmail.comwrote:
The reason and is a macro is that it's designed to short-circuit - ie if
the first result is false the rest shouldn't even be evaluated.
Using it on raw booleans works, because booleans evaluate to themselves,
but
So I did some coding and came up with this but it is broken;
(= java.lang.Boolean (type false)) ;;evaluates to true
(defn all-true?
[coll]
(every? (cond (= java.lang.Boolean (type identity)) identity :else false)
coll)) ;;compiles
(all-true? '(true true true)) ;; throws
= (type identity)
clojure.core$identity
On Wed, May 22, 2013 at 7:17 PM, Peter Mancini peter.manc...@gmail.comwrote:
So I did some coding and came up with this but it is broken;
(= java.lang.Boolean (type false)) ;;evaluates to true
(defn all-true?
[coll]
(every? (cond (=
Try:
user= (every? #(= Boolean (type %)) [true false false])
true
user= (every? #(= Boolean (type %)) [true false false 1])
false
On 22 May 2013 18:20, atkaaz atk...@gmail.com wrote:
= (type identity)
clojure.core$identity
On Wed, May 22, 2013 at 7:17 PM, Peter Mancini peter.manc
Duh never mind - simplified it and it works like a charm now.
(defn all-true?
[coll]
(every? (fn [x] (= x true)) coll))
(all-true? '(true true true))
(all-true? '(true true false))
(all-true? '(true true 3))
(all-true? '(3 \# !))
No exception on bad input data but if I really need to do
I think the exception is thrown because you basically called (every? false
coll) however on my clojure version I cannot reproduce it oh wait there we
go, some bug here with empty collection (maybe someone can pick it up):
= (every? false [1 2 3])
ClassCastException java.lang.Boolean cannot be
there's another edge case when using and/or :
getting passed an unbound var where for example `nil?` and `str` applied
to it don't throw, and of course also `or` and `and`, ie.:
= (def a)
#'cgws.notcore/a
= a
#Unbound Unbound: #'cgws.notcore/a
= (nil? a)
false
= (str a)
Unbound:
On Wed, May 22, 2013 at 9:32 AM, Peter Mancini peter.manc...@gmail.com wrote:
(defn all-true?
[coll]
(every? (fn [x] (= x true)) coll))
(defn all-true?
[coll]
(every? true? coll))
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. --
On 22 May 2013 18:34, atkaaz atk...@gmail.com wrote:
I think the exception is thrown because you basically called (every? false
coll) however on my clojure version I cannot reproduce it oh wait there we
go, some bug here with empty collection (maybe someone can pick it up):
= (every? false [1
Well, seems to me more like this:
if [] is empty then return true
otherwise check (pred everyx in coll)
however this allows for any pred especially(in this case) invalid preds:
`false` is not a function/pred
= (false 1)
ClassCastException java.lang.Boolean cannot be cast to clojure.lang.IFn
This seems to be a question on whether clojure supports java auto-boxing.
What java is doing here:
if (new Boolean(false)) {
// true
}
is calling .booleanValue on the Boolean object (as mentioned above).
And here:
int x = new Integer(6) + 4;
intValue is being called on the Integer object
So 'false?' doesn't help you here.
It does, actually (see earlier responses for details)
So if anyone runs into this problem _in real world code_ it's because
they are calling a Java API that somehow returns a Java Boolean object
embedded in the result. If you are working with a Java
What is the situation in ClojureCLR?
And, seeing the if code cited, I just run this code:
public class BoolTest {
public static void main(String[] args)
{
Boolean f = new Boolean(false);
System.out.println(f.equals(false)); // true
System.out.println(f == false); // true
System.out.println(f
the JVM and CLR (and JS).
The JVM and CLR (and JS) in this context are engines running language
implementations, not language implementations by themselves.
Clojure is not Java and vice-versa. Java objects are values to Clojure.
So is a Boolean object. What you have shown here is a Java specific
) then else)
then
How can some-thing evaluate to true but be equal (in whatever sense =
defines equality) to false?
IMHO it looks like some inconsistency in the contract between truthiness
and equality.
(And yes, I understand the argument that (Boolean. false) is an object and
thus true; it's just
According to e.g.
http://nathanmarz.com/blog/fun-with-equality-in-clojure.html
it's a speed trade-off. Something one can live with, but a wart
nevertheless.
Best,
Stefan
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send
Stefan Kamphausen ska2...@googlemail.com writes:
According to e.g.
http://nathanmarz.com/blog/fun-with-equality-in-clojure.html
it's a speed trade-off.
Partly. See Daniel's post where he fixed my contrieved micro-benchmark
and showed that testing on Boolean-equality in `if` slows
is the only false value, and there's no way to create
a new nil value that's not identical to nil. Scheme is similar in
having only #t and #f as boolean values with no possibility of creating
new instances of #t and #f.
user= (if some-thing then else)
then
user= (if (= some-thing false
Again, (Boolean. false) is an object. Objects returned from Java are values
from Clojure's perspective like numbers,
Clojure is a Lisp but allows you to access Java's object world.
It's not because the object wraps a property containing a boolean primitive
value that it
should behave
fix that would save a lot of time and
OMGWTFs for the new clojure users. Just like Boolean's javadoc puts a
strong emphasis on the fact that public *Boolean*(boolean value)
constructor usually shouldn't be used, clojure's docstring should say that
(= x false) may give you a result which
You are reporting this to the wrong language group.
The fact that Java:
A) has a public constructor for Boolean (a type with only 2 possible instances)
B) whose doc string says Note: It is rarely appropriate to use this
constructor.
and then
C) goes on to use it in some library functions
On Fri, Apr 13, 2012 at 3:33 AM, Vinzent ru.vinz...@gmail.com wrote:
Just like Boolean's javadoc puts a strong
emphasis on the fact that public Boolean(boolean value) constructor usually
shouldn't be used, clojure's docstring should say that (= x false) may give
you a result which will confuse
One little nit that confuses me.
Boolean/FALSE is documented as being of type Boolean in Java documentation,
yet it is treated by Clojure the same as primitive boolean false:
user= (clojure-version)
1.3.0
user= (if Boolean/FALSE logical true logical false)
logical false
user= (identical? Boolean
Hi,
Am 13.04.2012 um 21:45 schrieb Andy Fingerhut:
One little nit that confuses me.
Boolean/FALSE is documented as being of type Boolean in Java documentation,
yet it is treated by Clojure the same as primitive boolean false:
user= (clojure-version)
1.3.0
user= (if Boolean/FALSE
Andy Fingerhut andy.finger...@gmail.com writes:
Boolean/FALSE is documented as being of type Boolean in Java
documentation, yet it is treated by Clojure the same as primitive
boolean false:
user= (clojure-version)
1.3.0
user= (if Boolean/FALSE logical true logical false)
logical false
It's the other way around: false is boxed into Boolean/FALSE. Here's the if
stmt:
public Object eval() {
Object t = testExpr.eval();
if(t != null t != Boolean.FALSE)
return thenExpr.eval();
return elseExpr.eval();
}
On Friday, April 13, 2012 12:45:02 PM UTC-7, Andy Fingerhut wrote:
One
wow!!! i wasn't expecting that one...
Jim
On 13/04/12 21:17, Armando Blancas wrote:
It's the other way around: false is boxed into Boolean/FALSE. Here's
the if stmt:
public Object eval() {
Object t = testExpr.eval();
if(t != null t != Boolean.FALSE)
return thenExpr.eval();
return
Armando Blancas abm221...@gmail.com writes:
It's the other way around: false is boxed into Boolean/FALSE.
That's exactly what I've said, no?
TH That [Boolean.FALSE] is the canonical false Boolean object you get
TH when auto-boxing the primitive boolean false, or when calling
TH (Boolean
Well, changing the behaviour of 'if' is not the only way to fix the problem
(and it's impossible because of backward compatibility anyway). In my mind,
more realistic solution would be:
1. Clearly state in the section on interop that clojure, unlike java,
doesn't treat 'false' and (Boolean
Vinzent ru.vinz...@gmail.com writes:
1. Clearly state in the section on interop that clojure, unlike java,
doesn't treat 'false' and (Boolean. false) as equal objects.
Of course, it does! But `if` doesn't check equality, it checks if the
test expression's result is *identical* to nil or false
' is equal to (Boolean. false); it implies that they
represents the same value. Thus, the same value can be considered as both
truthy and falsey by clojure, which is like blowing my mind.
Of course it's possible to say that one of ='s arguments is a java class,
so you can't rely
' is a clojure built-in,
false and true are JVM built-ins.
so I'd expect that its behaviour is similar. 'false' is equal to
(Boolean. false); it implies that they represents the same
value. Thus, the same value can be considered as both truthy and
falsey by clojure, which is like blowing my mind
to do an identity-check instead of an equality check for
java.lang.Booleans? E.g., are you demanding that (= false
(Boolean. false)) should be false? That would be horrible.
It's not that I'm complaining about =, it's more about documentation and
such kind of stuff. On the other hand, if we
=, do you mean that = should be
special-cased to do an identity-check instead of an equality check for
java.lang.Booleans? E.g., are you demanding that (= false
(Boolean. false)) should be false? That would be horrible.
It's not that I'm complaining about =, it's more about documentation
The cheatsheet at http://clojure.org/cheatsheet (and the tooltip variants
available at http://jafingerhut.github.com) link to the clojuredocs pages,
so they have visibility to people who use the cheatsheet, or
clojuredocs.orgdirectly.
Or anyone else who uses this awesome feature of leinigen
The cheatsheet at http://clojure.org/cheatsheet (and the tooltip variants
available at http://jafingerhut.github.com) link to the clojuredocs
pages, so they have visibility to people who use the cheatsheet, or
clojuredocs.org directly.
or anyone else who uses this awesome feature of
'false' is a clojure built-in,
false and true are JVM built-ins.
LOL. Don't let him get away with anything!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new
So I agree: you cannot make it work for each and every JVM language, so
the current simplistic behavior is just fine.
Yeah, but my question about 'if' and equality remains open.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this
. It's strange for me that equal objects representing
the *same* value are treated in different ways by clojure. It's the same as
if (= (map identity [1 2 3]) (map identity (into-array [1 2 3]))) would
return false.
The Boolean class is not used by Clojure to represent boolean values. It
happens
(boolean, char, int, ...) and
complex like classes, interfaces and arrays. The Boolean class is not a JVM
data type, it's a Java creation. The JVM is not aware that this class is
special,
it's like any other class.
C) Your reference about same values does not stand, you are comparing
On 08/04/12 21:05, Stefan Kamphausen wrote:
Hi,
(= (Boolean. false) false) ;= true
now, that is really weird. By all means (at least those, I can come
up with ;-) it looks like false and (Boolean. false) are the same:
I think when you use the = operator in Clojure it calls
On Sat, Apr 07, 2012 at 07:53:17AM -0700, Steven Obua wrote:
[...] Nevertheless, somehow Boolean objects seem to creep into live,
and I have code like that:
(if (:leaf m-node)
...
)
that breaks because of it. I am using from the github repository
is the less troublesome -
just ask the topic starter. Also, suggested way to solve the problem was
just wrap every java call which could return Boolean in (boolean ...). If
it's the less troublesome path, I can't even imagine what would be the
more troublesome one.
But, once again, that's
Jim - FooBar(); jimpil1...@gmail.com writes:
(= (Boolean. false) false) ;= true
now, that is really weird. By all means (at least those, I can come
up with ;-) it looks like false and (Boolean. false) are the same:
I think when you use the = operator in Clojure it calls to the
.equals
That's interesting, thanks for your investigation! Then such decision was
clearly made because Java is not the only JVM language, just as Luc said.
For example, JRuby has its own class which wraps false:
http://jruby.org/apidocs/org/jruby/RubyBoolean.False.html
Obviously, it's impossible to
Vinzent ru.vinz...@gmail.com writes:
That's interesting, thanks for your investigation! Then such decision
was clearly made because Java is not the only JVM language, just as
Luc said. For example, JRuby has its own class which wraps false:
, Strings, and nulls.
To my amazement, the variant that explicitly checks for Boolean wrapper
objects is not at all slower. On my machine with IcedTea7-2.1, the 10
million checks with either the current null/false-check or the
null/false/Boolean-check take about 155 milliseconds.
So at least
1 - 100 of 144 matches
Mail list logo
