View mode: basic / threaded / horizontal-split · Log in · Help
February 20, 2012
Safe navigation operator
Hi,

http://groovy.codehaus.org/Operators#Operators-SafeNavigationOperator

What do you folks think about this? Would it be useful to have in D? It 
would make navigating large object graphs with possible null values much 
easier.

-- 
- Alex
February 20, 2012
Re: Safe navigation operator
On Monday, 20 February 2012 at 00:55:15 UTC, Alex Rønne Petersen 
wrote:
> Hi,
>
> http://groovy.codehaus.org/Operators#Operators-SafeNavigationOperator
>
> What do you folks think about this? Would it be useful to have 
> in D? It would make navigating large object graphs with 
> possible null values much easier.

The traditional counter point to this is that it encourages 
bad/lazy design. I don't really agree, but I don't ache for it 
either.
February 20, 2012
Re: Safe navigation operator
Hmm.. safe, but what about void methods? Silently not invoking methods
seems like a bad idea to me.

crypto?.encrypt(password)
Oops! :P

The Elvis operator looks kind of neat though. Although in D it's a bit
challenging since cast(bool) doesn't always do what you want. E.g. it
returns false on non-initialized string, true on zero-length
initialized string.
February 20, 2012
Re: Safe navigation operator
On 20-02-2012 03:00, Andrej Mitrovic wrote:
> Hmm.. safe, but what about void methods? Silently not invoking methods
> seems like a bad idea to me.
>
> crypto?.encrypt(password)
> Oops! :P
>
> The Elvis operator looks kind of neat though. Although in D it's a bit
> challenging since cast(bool) doesn't always do what you want. E.g. it
> returns false on non-initialized string, true on zero-length
> initialized string.

I think the Elvis operator only makes sense on fields and properties.

Good point about cast(bool).

-- 
- Alex
February 20, 2012
Re: Safe navigation operator
On 02/19/2012 08:00 PM, Bernard Helyer wrote:
> On Monday, 20 February 2012 at 00:55:15 UTC, Alex Rønne Petersen wrote:
>> Hi,
>>
>> http://groovy.codehaus.org/Operators#Operators-SafeNavigationOperator
>>
>> What do you folks think about this? Would it be useful to have in D?
>> It would make navigating large object graphs with possible null values
>> much easier.
>
> The traditional counter point to this is that it encourages bad/lazy
> design. I don't really agree, but I don't ache for it either.

I wonder then, if this argument has been made:

I think non-nullable types would be /far/ more helpful for this.

As far as I can tell, the intend of having a "better" design would be to 
find undesired nulls as close to their origination point as possible.  I 
really think there have to be more methodical ways to do this (ex: 
non-nullable types) that don't rely on fallable human whim.  After all, 
if I need the ?. and don't have it, I'll just write an if-statement 
instead.  It'll be the same poor design, and it will be more difficult 
to read too.

Or maybe... in debug mode references could be fat pointers that have 
both the data ptr and a second integer that points to information about 
where the last assignment took place.

struct PhatRef(T)
{
	T* data;
	AssignmentEntry* lastAssignment;
}

struct AssignmentEntry
{
	string fileName;
	size_t lineNumber;
}


Then this:

void main()
{
	Foo foo;
}

Gets lowered by the compiler into this:

void main()
{
	Foo foo;
	foo.lastAssignment.fileName   = "main.d";
	foo.lastAssignment.lineNumber = 2;
}

When the null foo is referenced, the crash handler/debugger/whatever can 
traverse the AssignmentEntry structure and display the debugging info. 
This would save soooooo much time!
February 20, 2012
Re: Safe navigation operator
On 20-02-2012 03:35, Chad J wrote:
> On 02/19/2012 08:00 PM, Bernard Helyer wrote:
>> On Monday, 20 February 2012 at 00:55:15 UTC, Alex Rønne Petersen wrote:
>>> Hi,
>>>
>>> http://groovy.codehaus.org/Operators#Operators-SafeNavigationOperator
>>>
>>> What do you folks think about this? Would it be useful to have in D?
>>> It would make navigating large object graphs with possible null values
>>> much easier.
>>
>> The traditional counter point to this is that it encourages bad/lazy
>> design. I don't really agree, but I don't ache for it either.
>
> I wonder then, if this argument has been made:
>
> I think non-nullable types would be /far/ more helpful for this.
>
> As far as I can tell, the intend of having a "better" design would be to
> find undesired nulls as close to their origination point as possible. I
> really think there have to be more methodical ways to do this (ex:
> non-nullable types) that don't rely on fallable human whim. After all,
> if I need the ?. and don't have it, I'll just write an if-statement
> instead. It'll be the same poor design, and it will be more difficult to
> read too.
>
> Or maybe... in debug mode references could be fat pointers that have
> both the data ptr and a second integer that points to information about
> where the last assignment took place.
>
> struct PhatRef(T)
> {
> T* data;
> AssignmentEntry* lastAssignment;
> }
>
> struct AssignmentEntry
> {
> string fileName;
> size_t lineNumber;
> }
>
>
> Then this:
>
> void main()
> {
> Foo foo;
> }
>
> Gets lowered by the compiler into this:
>
> void main()
> {
> Foo foo;
> foo.lastAssignment.fileName = "main.d";
> foo.lastAssignment.lineNumber = 2;
> }
>
> When the null foo is referenced, the crash handler/debugger/whatever can
> traverse the AssignmentEntry structure and display the debugging info.
> This would save soooooo much time!

I'd personally have to object to this. My virtual machine code heavily 
relies on references being plain pointers. That being said, the idea is 
not bad at all! (It would be easily realizable in a managed language.)

It would be nice if D had language-integrated non-nullable types a la Spec#.

-- 
- Alex
February 20, 2012
Re: Safe navigation operator
On 02/19/2012 09:50 PM, Alex Rønne Petersen wrote:
> On 20-02-2012 03:35, Chad J wrote:
>> On 02/19/2012 08:00 PM, Bernard Helyer wrote:
>>> On Monday, 20 February 2012 at 00:55:15 UTC, Alex Rønne Petersen wrote:
>>>> Hi,
>>>>
>>>> http://groovy.codehaus.org/Operators#Operators-SafeNavigationOperator
>>>>
>>>> What do you folks think about this? Would it be useful to have in D?
>>>> It would make navigating large object graphs with possible null values
>>>> much easier.
>>>
>>> The traditional counter point to this is that it encourages bad/lazy
>>> design. I don't really agree, but I don't ache for it either.
>>
>> I wonder then, if this argument has been made:
>>
>> I think non-nullable types would be /far/ more helpful for this.
>>
>> As far as I can tell, the intend of having a "better" design would be to
>> find undesired nulls as close to their origination point as possible. I
>> really think there have to be more methodical ways to do this (ex:
>> non-nullable types) that don't rely on fallable human whim. After all,
>> if I need the ?. and don't have it, I'll just write an if-statement
>> instead. It'll be the same poor design, and it will be more difficult to
>> read too.
>>
>> Or maybe... in debug mode references could be fat pointers that have
>> both the data ptr and a second integer that points to information about
>> where the last assignment took place.
>>
>> struct PhatRef(T)
>> {
>> T* data;
>> AssignmentEntry* lastAssignment;
>> }
>>
>> struct AssignmentEntry
>> {
>> string fileName;
>> size_t lineNumber;
>> }
>>
>>
>> Then this:
>>
>> void main()
>> {
>> Foo foo;
>> }
>>
>> Gets lowered by the compiler into this:
>>
>> void main()
>> {
>> Foo foo;
>> foo.lastAssignment.fileName = "main.d";
>> foo.lastAssignment.lineNumber = 2;
>> }
>>
>> When the null foo is referenced, the crash handler/debugger/whatever can
>> traverse the AssignmentEntry structure and display the debugging info.
>> This would save soooooo much time!
>
> I'd personally have to object to this. My virtual machine code heavily
> relies on references being plain pointers. That being said, the idea is
> not bad at all! (It would be easily realizable in a managed language.)
>
> It would be nice if D had language-integrated non-nullable types a la
> Spec#.
>

Yeah, I figured the fat pointer would have to be configurable somehow 
just because of exactly this sort of thing.

I still wonder what code that breaks with this would look like exactly. 
 Maybe there is a way to make it work in more possible situations.
February 20, 2012
Re: Safe navigation operator
On 20-02-2012 06:53, Chad J wrote:
> On 02/19/2012 09:50 PM, Alex Rønne Petersen wrote:
>> On 20-02-2012 03:35, Chad J wrote:
>>> On 02/19/2012 08:00 PM, Bernard Helyer wrote:
>>>> On Monday, 20 February 2012 at 00:55:15 UTC, Alex Rønne Petersen wrote:
>>>>> Hi,
>>>>>
>>>>> http://groovy.codehaus.org/Operators#Operators-SafeNavigationOperator
>>>>>
>>>>> What do you folks think about this? Would it be useful to have in D?
>>>>> It would make navigating large object graphs with possible null values
>>>>> much easier.
>>>>
>>>> The traditional counter point to this is that it encourages bad/lazy
>>>> design. I don't really agree, but I don't ache for it either.
>>>
>>> I wonder then, if this argument has been made:
>>>
>>> I think non-nullable types would be /far/ more helpful for this.
>>>
>>> As far as I can tell, the intend of having a "better" design would be to
>>> find undesired nulls as close to their origination point as possible. I
>>> really think there have to be more methodical ways to do this (ex:
>>> non-nullable types) that don't rely on fallable human whim. After all,
>>> if I need the ?. and don't have it, I'll just write an if-statement
>>> instead. It'll be the same poor design, and it will be more difficult to
>>> read too.
>>>
>>> Or maybe... in debug mode references could be fat pointers that have
>>> both the data ptr and a second integer that points to information about
>>> where the last assignment took place.
>>>
>>> struct PhatRef(T)
>>> {
>>> T* data;
>>> AssignmentEntry* lastAssignment;
>>> }
>>>
>>> struct AssignmentEntry
>>> {
>>> string fileName;
>>> size_t lineNumber;
>>> }
>>>
>>>
>>> Then this:
>>>
>>> void main()
>>> {
>>> Foo foo;
>>> }
>>>
>>> Gets lowered by the compiler into this:
>>>
>>> void main()
>>> {
>>> Foo foo;
>>> foo.lastAssignment.fileName = "main.d";
>>> foo.lastAssignment.lineNumber = 2;
>>> }
>>>
>>> When the null foo is referenced, the crash handler/debugger/whatever can
>>> traverse the AssignmentEntry structure and display the debugging info.
>>> This would save soooooo much time!
>>
>> I'd personally have to object to this. My virtual machine code heavily
>> relies on references being plain pointers. That being said, the idea is
>> not bad at all! (It would be easily realizable in a managed language.)
>>
>> It would be nice if D had language-integrated non-nullable types a la
>> Spec#.
>>
>
> Yeah, I figured the fat pointer would have to be configurable somehow
> just because of exactly this sort of thing.
>
> I still wonder what code that breaks with this would look like exactly.
> Maybe there is a way to make it work in more possible situations.

Well, in my case, I'm emitting raw machine code that simply uses 
references as pointers. I could adjust it to work with fat pointers, but 
then that means I have to special-case code generation when using the D 
runtime's GC versus any of the built-in GCs, which would be annoying. :/

-- 
- Alex
February 21, 2012
Re: Safe navigation operator
On 02/20/2012 06:39 AM, Alex Rønne Petersen wrote:
> On 20-02-2012 06:53, Chad J wrote:
>> On 02/19/2012 09:50 PM, Alex Rønne Petersen wrote:
>>> On 20-02-2012 03:35, Chad J wrote:
>>>> On 02/19/2012 08:00 PM, Bernard Helyer wrote:
>>>>> On Monday, 20 February 2012 at 00:55:15 UTC, Alex Rønne Petersen
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> http://groovy.codehaus.org/Operators#Operators-SafeNavigationOperator
>>>>>>
>>>>>> What do you folks think about this? Would it be useful to have in D?
>>>>>> It would make navigating large object graphs with possible null
>>>>>> values
>>>>>> much easier.
>>>>>
>>>>> The traditional counter point to this is that it encourages bad/lazy
>>>>> design. I don't really agree, but I don't ache for it either.
>>>>
>>>> I wonder then, if this argument has been made:
>>>>
>>>> I think non-nullable types would be /far/ more helpful for this.
>>>>
>>>> As far as I can tell, the intend of having a "better" design would
>>>> be to
>>>> find undesired nulls as close to their origination point as possible. I
>>>> really think there have to be more methodical ways to do this (ex:
>>>> non-nullable types) that don't rely on fallable human whim. After all,
>>>> if I need the ?. and don't have it, I'll just write an if-statement
>>>> instead. It'll be the same poor design, and it will be more
>>>> difficult to
>>>> read too.
>>>>
>>>> Or maybe... in debug mode references could be fat pointers that have
>>>> both the data ptr and a second integer that points to information about
>>>> where the last assignment took place.
>>>>
>>>> struct PhatRef(T)
>>>> {
>>>> T* data;
>>>> AssignmentEntry* lastAssignment;
>>>> }
>>>>
>>>> struct AssignmentEntry
>>>> {
>>>> string fileName;
>>>> size_t lineNumber;
>>>> }
>>>>
>>>>
>>>> Then this:
>>>>
>>>> void main()
>>>> {
>>>> Foo foo;
>>>> }
>>>>
>>>> Gets lowered by the compiler into this:
>>>>
>>>> void main()
>>>> {
>>>> Foo foo;
>>>> foo.lastAssignment.fileName = "main.d";
>>>> foo.lastAssignment.lineNumber = 2;
>>>> }
>>>>
>>>> When the null foo is referenced, the crash handler/debugger/whatever
>>>> can
>>>> traverse the AssignmentEntry structure and display the debugging info.
>>>> This would save soooooo much time!
>>>
>>> I'd personally have to object to this. My virtual machine code heavily
>>> relies on references being plain pointers. That being said, the idea is
>>> not bad at all! (It would be easily realizable in a managed language.)
>>>
>>> It would be nice if D had language-integrated non-nullable types a la
>>> Spec#.
>>>
>>
>> Yeah, I figured the fat pointer would have to be configurable somehow
>> just because of exactly this sort of thing.
>>
>> I still wonder what code that breaks with this would look like exactly.
>> Maybe there is a way to make it work in more possible situations.
>
> Well, in my case, I'm emitting raw machine code that simply uses
> references as pointers. I could adjust it to work with fat pointers, but
> then that means I have to special-case code generation when using the D
> runtime's GC versus any of the built-in GCs, which would be annoying. :/
>

That's encouraging actually.  My ideal would be to use fat pointers 
whenever possible in code that might break, and special case away other 
situations with bit twiddling, optimizations, or where ABI trickery 
matters.
Top | Discussion index | About this forum | D home