Null Functions

[Jonathan Allen]

Would adding Null Functions to the CLR be a good thing?

Syntax example...

Class String
Public Function Length() As Integer
Return //the length of the string
End Function

Public Null Function Length() As Integer
Return 0
End Function
End Class

Dim S as String

The Null Function would be written as any other Shared (C# Static) method,
only the way it would be called is different.

The first thing the runtime does is check to see if S is Nothing (C# Null).
If it is, then it would check to see if there was a matching Null function
for the variable type. If there is, it is used. Otherwise it raises an
Exception as is currently does.

--
Jonathan Allen

[Willy Van den Driessche]

> The first thing the runtime does is check to see if S is Nothing (C#
Null).
> If it is, then it would check to see if there was a matching Null function
> for the variable type. If there is, it is used. Otherwise it raises an
> Exception as is currently does.

There is a conceptual elegance in what you are proposing. It would
introduce the Null Object design pattern for methods.

However, there are some objections :
1) the semantics can get heavy. Methods like this cannot be instance
methods. They MUST be class methods (there is no 'this' or 'self' or 'me'
or ...) If you don't agree then just think what methods like this would
behave in when combined with inheritance. In BaseClass has a virtual null
method and DerivedClass overrides this method, which method will get called
with a null argument ?(I'm pretty sure you don't want it to be the null
method of the *declared* type of the variable. The point is that Null
methods don't mix very well with all polymorphism constructions like
implementation and interface inheritance
2) the control flow will lose clarity ( it's not that obvious to see why
you're not getting in a certain function you just put a breakpoint in)
3) most troubling would be that performance would suffer too much. Imagine
this check for each and every function call. Language designers have been
known to be killed for less <g>.

Fortunately you can always implement these "null functions" yourself by
going to class methods yourself. I've used this idiom on occasions in
classic VB by putting "checker methods" in bas modules. For "real
objects", they just called the method, for Nothing there was special logic.

If I use it for real objects that do use polymorphism, I introduce a class
to encapsulate this behavior. 'Nothing' then becomes an unwanted guest and
all cases that where nothing, use a (singleton) instance of the Special Null
Object Class. (There is one such class for each need of a nullobject)


--
Van den Driessche Willy
For a work in progress :
http://users.skynet.be/wvdd2/index.html

[Jonathan Allen]

> 1)
> Methods like this cannot be instance
> methods. They MUST be class methods

No argument there.

> In BaseClass has a virtual null
> method and DerivedClass overrides this method, which method will get
called
> with a null argument ?(I'm pretty sure you don't want it to be the null
> method of the *declared* type of the variable.

Since there is no instance to consider, it would have to be based on the
variable's declared type.

***********************

> 2) the control flow will lose clarity ( it's not that obvious to see why
> you're not getting in a certain function you just put a breakpoint in)

1. First of all, this would be considered an advanced technique. I wouldn't
expect novices to use it.
2. A person should be aware if they have any null functions in their own
classes.
3. It would be revealed if the user stepped into the function instead of
using a break point.

******************
> 3) most troubling would be that performance would suffer too much.
Imagine
> this check for each and every function call.

I don't know the full cost yet, but I don't think it would be that great.

1. This would be limited to special cases like String.Length, you wouldn't
want to use it for all methods.

2. You have to check for null references for every function call anyways.
How else would the CLR know when to throw an exception?

3. The JIT would resolve the alternate paths at compile time, so it is a one
time cost.

Dim S as String
S.Length

current path...
If S Is Null then Throw Exception
Else continue executing String.Length

new path...
If S Is Null then execute String.Null_Length
Else continue executing String.Length

--
Jonathan Allen


"Willy Van den Driessche" <Willy.Van.denDriessche@skynet.be> wrote in
message news:3bb0fd9f@news.devx.com...
> > The first thing the runtime does is check to see if S is Nothing (C#
> Null).
> > If it is, then it would check to see if there was a matching Null
function
> > for the variable type. If there is, it is used. Otherwise it raises an
> > Exception as is currently does.
>
> There is a conceptual elegance in what you are proposing. It would
> introduce the Null Object design pattern for methods.
>
> However, there are some objections :
> 1) the semantics can get heavy. Methods like this cannot be instance
> methods. They MUST be class methods (there is no 'this' or 'self' or 'me'
> or ...) If you don't agree then just think what methods like this would
> behave in when combined with inheritance. In BaseClass has a virtual null
> method and DerivedClass overrides this method, which method will get
called
> with a null argument ?(I'm pretty sure you don't want it to be the null
> method of the *declared* type of the variable. The point is that Null
> methods don't mix very well with all polymorphism constructions like
> implementation and interface inheritance
> 2) the control flow will lose clarity ( it's not that obvious to see why
> you're not getting in a certain function you just put a breakpoint in)
> 3) most troubling would be that performance would suffer too much.
Imagine
> this check for each and every function call. Language designers have
been
> known to be killed for less <g>.
>
> Fortunately you can always implement these "null functions" yourself by
> going to class methods yourself. I've used this idiom on occasions in
> classic VB by putting "checker methods" in bas modules. For "real
> objects", they just called the method, for Nothing there was special
logic.
>
> If I use it for real objects that do use polymorphism, I introduce a class
> to encapsulate this behavior. 'Nothing' then becomes an unwanted guest
and
> all cases that where nothing, use a (singleton) instance of the Special
Null
> Object Class. (There is one such class for each need of a nullobject)
>
>
> --
> Van den Driessche Willy
> For a work in progress :
> http://users.skynet.be/wvdd2/index.html
>
>

[Willy Van den Driessche]

OK jonathan, now I get your point. Since you don't want these things to
play in the polymorphism game, you're right that it's a compile-time thing.
(Actually - don't tell anybody - but Delphi has such a method in its TObject
class. The free method allows you to deallocate an instance. [Delphi is
manage-memory-but-not-for-recounted-interfaces-yourself-language]. The free
method can also be called with a nil variable, in which case it is a no-op.
Needless to say, the Borland boys played some assembler tricks to get this
done [by inspecting the self pointer on the stack]. And I must say that I
like that thought)

Being a compile-time thing, the performance won't suffer, as you pointed out
with the exception-path example. Then the only possible remaining objection
is Ockhams axe : Entities should not be multiplied witout necessity. It's a
principle that holds for every programmer but for holds even more for
language designers. I guess that's why they didn't and will not introduce
it. After all, you could just write

class String
public shared strLen (byval aString as String) as long
if aString = null then
strlen = 0
else
strlen = aString.length
end if
end function

That code is not that hard to write and the code to use it :

string.strlen(myString)

is more complicated than :

myString.length

but not in such a way that it would justify adding a new language syntax for
it.
Note that I favor syntactic sugar over mathematical minimalistic languages,
but in this case I guess it would not be worth it. I'm waiting for a Dan
appleman book to arrive because I'm curious if your problem could not be
solved by using method attributes. (see thread about
<System.Diagnostics.DebuggerStepThrough()> in vb.dotnet.technical)

See you,
--
Van den Driessche Willy
For a work in progress :
http://users.skynet.be/wvdd2/index.html

[Jonathan Allen]

> Note that I favor syntactic sugar over mathematical minimalistic
languages,
> but in this case I guess it would not be worth it.

Maybe it isn't useful enough to add to particular language, but what about
the CLR itself? Adding that feature to the String class would be very useful
in languages like VB.Net, which consider Nothing and the Empty String to be
equal. This addition would make them truly equal in all respects.

--
Jonathan Allen


"Willy Van den Driessche" <Willy.Van.denDriessche@skynet.be> wrote in
message news:3bb10952$1@news.devx.com...
> OK jonathan, now I get your point. Since you don't want these things to
> play in the polymorphism game, you're right that it's a compile-time
thing.
> (Actually - don't tell anybody - but Delphi has such a method in its
TObject
> class. The free method allows you to deallocate an instance. [Delphi is
> manage-memory-but-not-for-recounted-interfaces-yourself-language]. The
free
> method can also be called with a nil variable, in which case it is a
no-op.
> Needless to say, the Borland boys played some assembler tricks to get this
> done [by inspecting the self pointer on the stack]. And I must say that I
> like that thought)
>
> Being a compile-time thing, the performance won't suffer, as you pointed
out
> with the exception-path example. Then the only possible remaining
objection
> is Ockhams axe : Entities should not be multiplied witout necessity. It's
a
> principle that holds for every programmer but for holds even more for
> language designers. I guess that's why they didn't and will not introduce
> it. After all, you could just write
>
> class String
> public shared strLen (byval aString as String) as long
> if aString = null then
> strlen = 0
> else
> strlen = aString.length
> end if
> end function
>
> That code is not that hard to write and the code to use it :
>
> string.strlen(myString)
>
> is more complicated than :
>
> myString.length
>
> but not in such a way that it would justify adding a new language syntax
for
> it.
> Note that I favor syntactic sugar over mathematical minimalistic
languages,
> but in this case I guess it would not be worth it. I'm waiting for a Dan
> appleman book to arrive because I'm curious if your problem could not be
> solved by using method attributes. (see thread about
> <System.Diagnostics.DebuggerStepThrough()> in vb.dotnet.technical)
>
> See you,
> --
> Van den Driessche Willy
> For a work in progress :
> http://users.skynet.be/wvdd2/index.html
>
>

[Ed Courtenay]

I can see your reasoning here Jonathan, but I (personally) think that it
could be quite dangerous.

Given your example below, I take it that you would expect the following
code:

Dim S As String
Console.WriteLine(S.Length);

to produce "0". This in my eyes is wrong - a NULL string is not a
zero-length string and vica versa.

Also, the other problem here is that you are suggesting that code can be run
from an uninstantiated object - there is no null function to be called if
the object itself is null!

--
Ed Courtenay
http://www.edcourtenay.co.uk
((wrong && wrong) != right)

"Jonathan Allen" <greywolf@cts.com> wrote in message
news:3bb0d1ea@news.devx.com...
> Would adding Null Functions to the CLR be a good thing?
>
> Syntax example...
>
> Class String
> Public Function Length() As Integer
> Return //the length of the string
> End Function
>
> Public Null Function Length() As Integer
> Return 0
> End Function
> End Class
>
> Dim S as String
>
> The Null Function would be written as any other Shared (C# Static) method,
> only the way it would be called is different.
>
> The first thing the runtime does is check to see if S is Nothing (C#
Null).
> If it is, then it would check to see if there was a matching Null function
> for the variable type. If there is, it is used. Otherwise it raises an
> Exception as is currently does.
>
> --
> Jonathan Allen
>
>
>

[Willy Van den Driessche]

"Ed Courtenay" <ed@edcourtenay.co.uk> wrote:
>I can see your reasoning here Jonathan, but I (personally) think that it
>could be quite dangerous.
>
>Given your example below, I take it that you would expect the following
>code:
>
>Dim S As String
>Console.WriteLine(S.Length);
>
>to produce "0". This in my eyes is wrong - a NULL string is not a
>zero-length string and vica versa.
That's not what Jonathan was saying, I think. He just suggested that the
length of a null string could return 0. This would avoid if statements all
over the place (while implicitly they are still there).

>
>Also, the other problem here is that you are suggesting that code can be
run
>from an uninstantiated object - there is no null function to be called if
>the object itself is null!

Ed, that's why we agreed that it should be a class method (shared). You
don't need an instance to call a class method

>
>--

Willy

[Jonathan Allen]

> This in my eyes is wrong - a NULL string is not a
> zero-length string and vica versa.

I don't want to get bogged down in the specifics of that example, but rather
focus on the concept as a whole.

> there is no null function to be called if
> the object itself is null!

It would work just like a shared function, no object required.

--
Jonathan Allen


"Ed Courtenay" <ed@edcourtenay.co.uk> wrote in message
news:3bb1997f$1@news.devx.com...
> I can see your reasoning here Jonathan, but I (personally) think that it
> could be quite dangerous.
>
> Given your example below, I take it that you would expect the following
> code:
>
> Dim S As String
> Console.WriteLine(S.Length);
>
> to produce "0". This in my eyes is wrong - a NULL string is not a
> zero-length string and vica versa.
>
> Also, the other problem here is that you are suggesting that code can be
run
> from an uninstantiated object - there is no null function to be called if
> the object itself is null!
>
> --
> Ed Courtenay
> http://www.edcourtenay.co.uk
> ((wrong && wrong) != right)
>

[Bill McCarthy]

Hi JA,

"Jonathan Allen" <greywolf@cts.com> wrote in message
news:3bb143e3@news.devx.com...
>
> Maybe it isn't useful enough to add to particular language, but what about
> the CLR itself? Adding that feature to the String class would be very
useful
> in languages like VB.Net, which consider Nothing and the Empty String to
be
> equal. This addition would make them truly equal in all respects.
>

It's not useful at all. It would still be doing a check to see if the string
is Nothing, so it is not more efficient. Instead you have added extra static
methods which will impact performance. It also introduces an incredible
burdon on anyone else writing classes as their classes would have to have
the same design interface or else there woudl be large scale inconsistencies
between different classes.

As to your claim that VB.NET treats Nothing and String.Empty to be equal,
that all depends on your definition of equal. If you test String.Empty =
Nothing then that will return True, but if you test String.Empty Is Nothing
then that will return False.

IOW: VB.NET does distinguish between the two !

What would be an absolute terrible design woudl be one that didn't let you
distinguish between the two and one that assumed that there was no
difference between instance methods and static methods, or no way to
differentiate between which ones were being called as all instance methods
would look like static ones. If it were possible to write String.Length()
instead of MyString.Length, then how would anyone be able to distinguish
between the two ?

And once that happens then what is Nothing and what is an instance ? The
only way to tell is to test for Is Nothing, which is the test your code
should have done in the first place.