Gentlemen,
some NPE-related problems of today brought me to re-interate one of my older
suggestions.
We have the so-called “safe navigation”[*], which in some cases allows a null
to be propagated out of an expression instead of throwing a NPE. At the moment,
it can be triggered for a particula
thing :)
Thanks and all the best,
OC
> Den 2018-08-14 13:28, skrev ocs@ocs:
>> Gentlemen,
>> some NPE-related problems of today brought me to re-interate one of my
>> older suggestions.
>> We have the so-called “safe navigation”[*], which in some cases allows
>> a
Just a followup:
> On 14 Aug 2018, at 2:25 PM, ocs@ocs wrote:
>
> what I would like to see in Groovy would be a way to intentionally switch to
> the non-NPE null-propagating behaviour where needed by very explicit using of
> an appropriate annotation.
... considering tha
p://www.linkedin.com/in/aalmiray>
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
> On
rException npe) {
null
}
}
===
happens to be now.
Thanks and all the best,
OC
> On 14 Aug 2018, at 2:50 PM, h...@abula.org wrote:
>
> Den 2018-08-14 14:25, skrev ocs@ocs:
>> H2,
>>> On 14 Aug 2018, at 1:38 PM, h...@abula.org wrote:
>>> IMHO, there is an e
Jochen,
> On 14 Aug 2018, at 6:25 PM, Jochen Theodorou wrote:
> Am 14.08.2018 um 15:23 schrieb ocs@ocs:
>> H2,
>>> However, “a+b” should work as one would expect
>> Absolutely. Me, I very definitely expect that if a happens to be null, the
>> result is null to
Jochen,
> On 14 Aug 2018, at 6:34 PM, Jochen Theodorou wrote:
> [...]
>> For the moment, the best solution — far as I have been able to ascertain —
>> consists of [*]
>> (a) at launch, setting own DelegatingMetaClass subclass for a
>> Null.metaclass; it essentially would return null from invoke
)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
268 /tmp>
===
Thanks and all the best,
OC
> On 14 Aug 2018, at 7:10 PM, ocs@ocs wrote:
>
>
for some people it definitely is
better, and that Groovy should support those times and people just as well as
it supports the NPE-based approach of Java.
Thanks and all the best,
OC
> Ursprüngliche Nachricht
> Von: "ocs@ocs"
> Datum: 14.08.18 17:46 (GMT+00:
s and all the best,
OC
>
> On Tue, Aug 14, 2018 at 1:28 PM, ocs@ocs mailto:o...@ocs.cz>>
> wrote:
> Gentlemen,
>
> some NPE-related problems of today brought me to re-interate one of my older
> suggestions.
>
> We have the so-called “safe navigation”[*], which in
e quick, efficient
and convenient null-propagation instead) :)
Thanks and all the best,
OC
> Ursprüngliche Nachricht
> Von: "ocs@ocs"
> Datum: 14.08.18 23:14 (GMT+00:00)
> An: dev@groovy.apache.org
> Betreff: Re: suggestion: ImplicitSafeNavigation ann
all said, it definitely is an interesting idea worth checking; myself,
though, I do fear it would quickly lead to a real mess (unlike my suggestion,
which is considerably less flexible, but at the same moment, very simple and
highly intuitive).
Thanks and all the best,
OC
> Ursp
Jochen,
> On 15 Aug 2018, at 10:13 AM, Jochen Theodorou wrote:
> Am 14.08.2018 um 19:10 schrieb ocs@ocs:
>> Jochen,
>>> On 14 Aug 2018, at 6:34 PM, Jochen Theodorou >> <mailto:blackd...@gmx.org>> wrote:
> [...]
>>> are you saying x?.foo will NPE if
t; I also think any assumption about the semantics of null values are
> problematic. In particular, assuming that any null value in an expression
> should be propagated is not obvious to me.
To me, it seems very obvious, completely natural and quite intuitive —
especially in Groovy where (un
x27;?' gently and sport a weird results,
from an insane (though understandable) runtime behaviour like “null?.is(null)"
sports up through exceptions compile-time to (at least to me not
understandable) Verity Error caused by super?.anything.
Thanks and all the best,
OC
>
> From:
overlooking something
of importance.
All the best.,
OC
>
> Ursprüngliche Nachricht
> Von: "ocs@ocs"
> Datum: 15.08.18 19:53 (GMT+00:00)
> An: dev@groovy.apache.org
> Betreff: Re: suggestion: ImplicitSafeNavigation annotation
>
> Eric,
>
mp;& null == false // Groovy-truth-null
>
> ?
>
>
>
> Ursprüngliche Nachricht
> Von: "ocs@ocs"
> Datum
>
> Ursprüngliche Nachricht
> Von: mg
> Datum: 15.08.18 13:07 (GMT+00:00)
> An: dev@groovy.apache.org
> Betreff:
Jochen,
> On 15 Aug 2018, at 10:13 AM, Jochen Theodorou wrote:
> have to do the same treatment for get/setProperty
I have tried repeatedly, but the thing simply does not work :( Any idea why?
===
585 /tmp> /usr/local/groovy-2.4.15/bin/groovy q
WARNING: An illegal reflective access operation ha
Ladies and gentlemen,
I have bumped into another suspicious behaviour: is this all right? Happens
both with 2.4 and 3.0 same way.
Thanks and all the best,
OC
===
717 /tmp> /usr/local/groovy-3.0.0-alpha-3/bin/groovy q
WARNING: Using incubator modules: jdk.incubator.httpclient
Caught: gro
e of someone explicitely
> throwing an NPE in a method... ;-)
>
> @null.each { ... } : That would be my expectation also, but afaik null.each
> behavior in dynamic Groovy has been around long before Elvis entered the
> building...
>
> Cheers,
> mg
>
>
>
> Urspr
Ladies and gentlemen,
the debate of null-propagation led me to bumping into a wildly inconsistent
behaviour when one overrides Integer methods through the metaclass.
To me, this looks like a bug; even if this mess happens to be an intended
behaviour, it is pretty weird (in this case, is it docu
ding of Interger methods
>
> It appears to be most (all?) primitive/wrapper types not just Integer.
>
> On Sun, Aug 19, 2018 at 11:00 PM ocs@ocs mailto:o...@ocs.cz>>
> wrote:
> Ladies and gentlemen,
>
> the debate of null-propagation led me to bumping into a wildly inconsi
Ladies and gentlemen,
I've just bumped into the problem shown below.
Whilst it is arguable whether the situation should be valid or not (myself, I
strongly believe it should be valid and compiled without a glitch), even if
invalid, it should not cause an uncaught exception, but simply report a
row new RuntimeException('Boom!')}
> try {
> new Foo().baz()
> println 'ERROR: Should not get here!'
> } catch(RuntimeException ex) {
> println ex.message
> }
>
> So instead of the weird "runtime" error during parsing, we could throw
Hi there,
lately, I got bit in my tender parts by this catch, sorta similar to the debate
of the more-line-expression of late -- this time, though, a line which I
presumed to be compiled separately is considered a part of the previous command:
===
20 /tmp> }
}
}
foo.baz()
21 /tmp> /usr/local
Myself, I am not a huge fan of adding not-often-needed functionalities (and
actually would add almost none of those discussed lately); nevertheless...
> On 18 Oct 2018, at 6:48 PM, Paolo Di Tommaso
> wrote:
>
> -1, it can be easily done as:
> list.first() ?: defaultValue
... this won't work
P.S. Oh, and when I am writing anyway — please, do not abuse the “overloaded”
methods which differ just by their argument lists (myself, I consider them
always at best suspicious; mostly plain wrong). Instead of the suggestion
below, if something like that is accepted, it would be much better to
I suppose this is the equivalent now
> that I think about it:
>
> list ? list.first() : defaultValue
>
>
> From: ocs@ocs mailto:o...@ocs.cz>>
> Sent: Thursday, October 18, 2018 12:07 PM
> To: dev@groovy.apache.org <mailto:dev@groovy.apache.org>
> Subje
mailto:dev@groovy.apache.org>
> Subject: Re: DGM for first or default
>
> "list?.first() ?: defaultValue" is not the equivalent. If the collection is
> empty, first() throws an IndexOutOfBoundsException is thrown. That's why I'm
> asking if there is a s
29 matches
Mail list logo
