Guys, am a bit busy now to dive into the particular debate (later will gladly, if still runs), just one important point — don't please add new keywords, for that would break the compatibility with the current codebase. E.g., my projects are full of “nil”s and “empty”s. “default” would probably clash with the current keyword.
Thanks and all the best, OC > On 1. 2. 2025, at 18:07, MG <mg...@arscreat.com> wrote: > > Hi Paul, > I suggested Groovy could support additional null-like types, which are also > compatible with any type, but can have different semantics from null. > Some examples: > nil, representing "nothing" could dissappear when added to a collection or > inserted into a GString. > empty could indicate that a variable/field has intentionally been left > uninitilaized (contrary to having been left uninitialized by error, as null > would indicate). > default could be a special case for empty, implying that code should treat > this as having some sort of default value or exhibit default behavior. > sql_null could give SQL NULL like logic behavior. > error/invalid would represent a generic "error object". > This behavior would be impossible to add to static Groovy without JVM support. > In this case the memory adresses 0 = null, 1 = nil, 2 = empty, 3 = default, > ... could be used to encode this. > But could be added to dynamic Groovy through NilObject, EmptyObject, etc. > I also asked something along the lineof whether Groovy could support giving > the full call chain in a.b.c.d in the NPE if e.g. c === NullObject. > Cheers, > mg > > On 31/01/2025 21:54, Paul King wrote: >> We have spoken about adding support (in dynamic Groovy) for NullObject >> just like you suggest. I couldn't find it right now in a Jira or the >> current mailing lists. Maybe it was codehaus days. >> >> The original thinking of NullObject was that it shouldn't normally >> appear in user code. But maybe it's fine in this case. >> >> Paul. >> >> On Fri, Jan 31, 2025 at 7:49 AM o...@ocs.cz <mailto:o...@ocs.cz> >> <o...@ocs.cz> <mailto:o...@ocs.cz> wrote: >>> Hi there, >>> >>> is there a way to write a method with argument which would match null >>> specifically when called? This does not work: >>> >>> === >>> 1022 ocs /tmp> <q.groovy >>> class Test { >>> def foo(Collection foo) {} >>> def foo(Map foo) {} >>> def foo(org.codehaus.groovy.runtime.NullObject foo) {} >>> } >>> new Test().foo(null) >>> 1023 ocs /tmp> /usr/local/groovy-4.0.25/bin/groovy q >>> Caught: groovy.lang.GroovyRuntimeException: Ambiguous method overloading >>> for method Test#foo. >>> Cannot resolve which method to invoke for [null] due to overlapping >>> prototypes between: >>> [interface java.util.Collection] >>> [interface java.util.Map] >>> === >>> >>> Thanks! >>> OC >
