Null Functions


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 9 of 9

Thread: Null Functions

  1. #1
    Jonathan Allen Guest

    Null Functions

    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




  2. #2
    Willy Van den Driessche Guest

    Re: Null Functions

    > 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



  3. #3
    Jonathan Allen Guest

    Re: Null Functions

    > 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
    >
    >




  4. #4
    Willy Van den Driessche Guest

    Re: Null Functions

    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



  5. #5
    Jonathan Allen Guest

    Re: Null Functions

    > 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
    >
    >




  6. #6
    Ed Courtenay Guest

    Re: Null Functions

    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
    >
    >
    >




  7. #7
    Willy Van den Driessche Guest

    Re: Null Functions


    "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

  8. #8
    Jonathan Allen Guest

    Re: Null Functions

    > 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)
    >





  9. #9
    Bill McCarthy Guest

    Re: Null Functions

    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.














Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center