Eliminating the ability to have Null.

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Eliminating the ability to have Null.

Jordo Odroj
Hello,

I've always found that having the option to set an object's value to null is the worst feature of virtually every single language in existence. Why can't we have the haxe language support None | Some<Type> instead?
The ability to assign the null object, who's type is Null to any object is strange. What's really going on, is that from the compiler/type system's perspective, Null is a subtype of every class/type that is created. Yet, it is an exception to every of subtype relationship.
In all other cases,
if x is a subtype of y, then anything you can do to y, you can also do to x (as far as method invocation etc.)
The type system treats Null as a subtype of z, for all objects z, yet it is not the case that anything you can do on an instance of z, you can do on an instance of Null.
For all cases where you are tempted to use a Null value, just use an Option.
Of course, there's the issue of integrating onto different platforms, but it is pretty straightforward to map code that accepts nulls, to Options.

Jordo

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

Tony Polinelli
woudnt a change like this break virtually ALL existing code + make integration with (porting etc) other languages such as as3, javascript, a nightmare?



On Mon, Jan 17, 2011 at 6:14 PM, Jordo Odroj <[hidden email]> wrote:
Hello,

I've always found that having the option to set an object's value to null is the worst feature of virtually every single language in existence. Why can't we have the haxe language support None | Some<Type> instead?
The ability to assign the null object, who's type is Null to any object is strange. What's really going on, is that from the compiler/type system's perspective, Null is a subtype of every class/type that is created. Yet, it is an exception to every of subtype relationship.
In all other cases,
if x is a subtype of y, then anything you can do to y, you can also do to x (as far as method invocation etc.)
The type system treats Null as a subtype of z, for all objects z, yet it is not the case that anything you can do on an instance of z, you can do on an instance of Null.
For all cases where you are tempted to use a Null value, just use an Option.
Of course, there's the issue of integrating onto different platforms, but it is pretty straightforward to map code that accepts nulls, to Options.

Jordo

--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

Jordo Odroj
I just posted another topic asking about our future plans to support Multiptypes. Multitypes would make this quite simple.
Integrating with PHP/javascript would be very easy. You just declare that the PHP/js methods return (in multitype speak) x : String | Null
It's just supporting code that has already been written that is slightly more difficult.
We could keep the ability to allow nulls, or even write a script that converts your entire code base to use multitypes, if you ever assign a null to something, or check for null values, etc.
Or you could have a compiler setting that allows it. For past projects, I might keep that setting, but for future projects, I would definitely turn it off.

On Sun, Jan 16, 2011 at 11:25 PM, Tony Polinelli <[hidden email]> wrote:
woudnt a change like this break virtually ALL existing code + make integration with (porting etc) other languages such as as3, javascript, a nightmare?



On Mon, Jan 17, 2011 at 6:14 PM, Jordo Odroj <[hidden email]> wrote:
Hello,

I've always found that having the option to set an object's value to null is the worst feature of virtually every single language in existence. Why can't we have the haxe language support None | Some<Type> instead?
The ability to assign the null object, who's type is Null to any object is strange. What's really going on, is that from the compiler/type system's perspective, Null is a subtype of every class/type that is created. Yet, it is an exception to every of subtype relationship.
In all other cases,
if x is a subtype of y, then anything you can do to y, you can also do to x (as far as method invocation etc.)
The type system treats Null as a subtype of z, for all objects z, yet it is not the case that anything you can do on an instance of z, you can do on an instance of Null.
For all cases where you are tempted to use a Null value, just use an Option.
Of course, there's the issue of integrating onto different platforms, but it is pretty straightforward to map code that accepts nulls, to Options.

Jordo

--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

jlm@justinfront.net
Wow yer multitypes seem to be what I was suggesting in my last post... almost exactly did not realize they were a proposal, so I think they are a good idea.  Null's can be a pain with flash especially with Int's but I would be very worried about their removal as I can't really see how that would work with flash player like Tony says but maybe I am wrong, happy to try no nulls, if it makes code simpler to work with, but I suspect not.


On 17 Jan 2011, at 08:35, Jordo Odroj wrote:

I just posted another topic asking about our future plans to support Multiptypes. Multitypes would make this quite simple.
Integrating with PHP/javascript would be very easy. You just declare that the PHP/js methods return (in multitype speak) x : String | Null
It's just supporting code that has already been written that is slightly more difficult.
We could keep the ability to allow nulls, or even write a script that converts your entire code base to use multitypes, if you ever assign a null to something, or check for null values, etc.
Or you could have a compiler setting that allows it. For past projects, I might keep that setting, but for future projects, I would definitely turn it off.

On Sun, Jan 16, 2011 at 11:25 PM, Tony Polinelli <[hidden email]> wrote:
woudnt a change like this break virtually ALL existing code + make integration with (porting etc) other languages such as as3, javascript, a nightmare?



On Mon, Jan 17, 2011 at 6:14 PM, Jordo Odroj <[hidden email]> wrote:
Hello,

I've always found that having the option to set an object's value to null is the worst feature of virtually every single language in existence. Why can't we have the haxe language support None | Some<Type> instead?
The ability to assign the null object, who's type is Null to any object is strange. What's really going on, is that from the compiler/type system's perspective, Null is a subtype of every class/type that is created. Yet, it is an exception to every of subtype relationship.
In all other cases,
if x is a subtype of y, then anything you can do to y, you can also do to x (as far as method invocation etc.)
The type system treats Null as a subtype of z, for all objects z, yet it is not the case that anything you can do on an instance of z, you can do on an instance of Null.
For all cases where you are tempted to use a Null value, just use an Option.
Of course, there's the issue of integrating onto different platforms, but it is pretty straightforward to map code that accepts nulls, to Options.

Jordo

--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

Nicolas Cannasse
In reply to this post by Jordo Odroj
Le 17/01/2011 08:14, Jordo Odroj a écrit :
> Hello,
>
> I've always found that having the option to set an object's value to
> null is the worst feature of virtually every single language
> in existence. Why can't we have the haxe language support None |
> Some<Type> instead?

The issue is not the language itself, since it's not that much hard to
enforce not-nullness of class members - it still requires some extensive
analysis of class constructor call.

The main issue is that many platform API have not been designed with
such feature in mind, and that would require the developer to either
propagates Null<Foo> types or add == null checks in many places.

I might at some point in the future make some experiments with this, but
it's not high priority.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

Jordo Odroj
Nicolas, the longer we wait, the harder it will be. If we had multitypes, it wouldn't even have to be Null<ClassName> It would just be:
var x = function (x: MyClass | Null) {

}

If you know that a platform api could return null, then you define the haxe bindings *at the bridge point into the other platform* such that all things that could return null, return Null | TheOtherType. Then, you keep all things pure in haxe land. If anything returns null from another platform api (php etc) when the bindings did *not* indicate Null | Othertype, then that is a runtime system failure. Then we can switch on a compiler mode, where any reference to null is a compiler error (in haxe code). Any api into another platform that comes back null, without defining the return type from the platform api to be Null | OtherType would be a runtime failure. Because, let's face it, you should know the api's well enough to be able to indicate whether or not they return null anyways, so it's not unreasonable to require that a developer indicate this in the platform api's return type. In fact, once we document it, we'll save them much trouble later on.
I think we could do this. Nicolas, I only have a little ML experience, but do you think it would be reasonable for me to implement this? 
As someone who write OCaml, Nicolas, I was hoping you would appreciate where I am coming from. The stronger the typing the less errors we experience in production, and this saves us all time, money, and stress.

This is one of those things, where if you never knew you could have it, you'd never long for it, but once you try it, you'll never want to go back.

Jordo

On Mon, Jan 17, 2011 at 12:32 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 17/01/2011 08:14, Jordo Odroj a écrit :

Hello,

I've always found that having the option to set an object's value to
null is the worst feature of virtually every single language
in existence. Why can't we have the haxe language support None |
Some<Type> instead?

The issue is not the language itself, since it's not that much hard to enforce not-nullness of class members - it still requires some extensive analysis of class constructor call.

The main issue is that many platform API have not been designed with such feature in mind, and that would require the developer to either propagates Null<Foo> types or add == null checks in many places.

I might at some point in the future make some experiments with this, but it's not high priority.

Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

Jordo Odroj
Oh, and I've never got the chance to thank you, Nicolas, for your awesome and, quite frankly, elegant invention Haxe. I really don't even know how to show my thanks. It's been nothing but a joy to be working with Haxe.
The request to eliminate null, is merely an attempt to take care of the one remaining language feature that I consider to be "impure".
With "untyped" and Dynamic, you (the programmer) declare that you wish to break type safety, and otherwise the experience is very pure. However, null is this evil concept that breaks the type system "on your behalf" without ever asking you, and without you ever indicating that it should. It's the only inconsistency that I've found in the language so far.
Thanks again.

On Mon, Jan 17, 2011 at 12:42 AM, Jordo Odroj <[hidden email]> wrote:
Nicolas, the longer we wait, the harder it will be. If we had multitypes, it wouldn't even have to be Null<ClassName> It would just be:
var x = function (x: MyClass | Null) {

}

If you know that a platform api could return null, then you define the haxe bindings *at the bridge point into the other platform* such that all things that could return null, return Null | TheOtherType. Then, you keep all things pure in haxe land. If anything returns null from another platform api (php etc) when the bindings did *not* indicate Null | Othertype, then that is a runtime system failure. Then we can switch on a compiler mode, where any reference to null is a compiler error (in haxe code). Any api into another platform that comes back null, without defining the return type from the platform api to be Null | OtherType would be a runtime failure. Because, let's face it, you should know the api's well enough to be able to indicate whether or not they return null anyways, so it's not unreasonable to require that a developer indicate this in the platform api's return type. In fact, once we document it, we'll save them much trouble later on.
I think we could do this. Nicolas, I only have a little ML experience, but do you think it would be reasonable for me to implement this? 
As someone who write OCaml, Nicolas, I was hoping you would appreciate where I am coming from. The stronger the typing the less errors we experience in production, and this saves us all time, money, and stress.

This is one of those things, where if you never knew you could have it, you'd never long for it, but once you try it, you'll never want to go back.

Jordo

On Mon, Jan 17, 2011 at 12:32 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 17/01/2011 08:14, Jordo Odroj a écrit :

Hello,

I've always found that having the option to set an object's value to
null is the worst feature of virtually every single language
in existence. Why can't we have the haxe language support None |
Some<Type> instead?

The issue is not the language itself, since it's not that much hard to enforce not-nullness of class members - it still requires some extensive analysis of class constructor call.

The main issue is that many platform API have not been designed with such feature in mind, and that would require the developer to either propagates Null<Foo> types or add == null checks in many places.

I might at some point in the future make some experiments with this, but it's not high priority.

Nicolas

--
haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

Renaud Bardet-2
Hi, I find this mutliType feature amazing, and I agree with Jordo on the null thing,
I'm just willing to ask about the syntax you're employing, I've seen foo( x : A|B ) and foo( T : A|B )
what is the reflexion beyond that syntax ?
I'm a little afraid of having to do unclear things to handle that feature such as the given example
function foo( x : A|B) {
    switch( x ) {
        case A : //
        case B : //
    }
}
It doesn't seems clear that we are talking about type in this switch-case, and what if I would like to actually switch on that value ?
Could it be a more like defining a pseudo Type, like
function foo( x : T(Int|String) ) {
    switch ( T ) {
        case Int :  
                        switch ( x ) {
                                case 1 : //
                                case 2 : //
                        }
        case String :
                        foo( Std.parseInt( x ) ) ;
}
that's just some thoughts,
 
Renaud

Sent: Monday, January 17, 2011 12:22 PM
Subject: Re: [haXe] Eliminating the ability to have Null.

Oh, and I've never got the chance to thank you, Nicolas, for your awesome and, quite frankly, elegant invention Haxe. I really don't even know how to show my thanks. It's been nothing but a joy to be working with Haxe.
The request to eliminate null, is merely an attempt to take care of the one remaining language feature that I consider to be "impure".
With "untyped" and Dynamic, you (the programmer) declare that you wish to break type safety, and otherwise the experience is very pure. However, null is this evil concept that breaks the type system "on your behalf" without ever asking you, and without you ever indicating that it should. It's the only inconsistency that I've found in the language so far.
Thanks again.

On Mon, Jan 17, 2011 at 12:42 AM, Jordo Odroj <[hidden email]> wrote:
Nicolas, the longer we wait, the harder it will be. If we had multitypes, it wouldn't even have to be Null<ClassName> It would just be:
var x = function (x: MyClass | Null) {

}

If you know that a platform api could return null, then you define the haxe bindings *at the bridge point into the other platform* such that all things that could return null, return Null | TheOtherType. Then, you keep all things pure in haxe land. If anything returns null from another platform api (php etc) when the bindings did *not* indicate Null | Othertype, then that is a runtime system failure. Then we can switch on a compiler mode, where any reference to null is a compiler error (in haxe code). Any api into another platform that comes back null, without defining the return type from the platform api to be Null | OtherType would be a runtime failure. Because, let's face it, you should know the api's well enough to be able to indicate whether or not they return null anyways, so it's not unreasonable to require that a developer indicate this in the platform api's return type. In fact, once we document it, we'll save them much trouble later on.
I think we could do this. Nicolas, I only have a little ML experience, but do you think it would be reasonable for me to implement this? 
As someone who write OCaml, Nicolas, I was hoping you would appreciate where I am coming from. The stronger the typing the less errors we experience in production, and this saves us all time, money, and stress.

This is one of those things, where if you never knew you could have it, you'd never long for it, but once you try it, you'll never want to go back.

Jordo

On Mon, Jan 17, 2011 at 12:32 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 17/01/2011 08:14, Jordo Odroj a écrit :

Hello,

I've always found that having the option to set an object's value to
null is the worst feature of virtually every single language
in existence. Why can't we have the haxe language support None |
Some<Type> instead?

The issue is not the language itself, since it's not that much hard to enforce not-nullness of class members - it still requires some extensive analysis of class constructor call.

The main issue is that many platform API have not been designed with such feature in mind, and that would require the developer to either propagates Null<Foo> types or add == null checks in many places.

I might at some point in the future make some experiments with this, but it's not high priority.

Nicolas

--
haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org
--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

John A. De Goes
In reply to this post by Jordo Odroj

The Stax standard library does not use null anywhere (except when wrapping external code), and has a very nice Option enum and extension methods that make dealing with optional values easy.

Multitypes would be another solution, but it's not quite as easy to work with.

For example, let's say you have an optional value foo that has a method "bar" which return an optional value of type "Bar", which has a method "baz" which returns an optional value of type Baz. You want to invoke all these methods and end up with an optional value.

Using multitypes, you would have to write:

var baz: Bar | Null = switch (foo) {
  case Null: null;
  case Foo: 
    val bar = foo.bar();

    switch (bar) {
      case Null: null;
      case Bar: bar.baz();
  }
}

With Option, you would write:

var baz = foo.flatMap(function(foo) return foo.bar().flatMap(function(bar) return bar.baz()));

If HaXe had short lambdas, you could write:

var baz = foo.flatMap(foo -> foo.bar().flatMap(bar -> bar.baz()))

If HaXe had monadic shorthand, you could write:

var baz = do {
  bar <- foo.bar();
  baz <- bar.baz();
} yield baz;

In any case, all of the above are cleaner than the multitype solution.

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Jan 17, 2011, at 12:14 AM, Jordo Odroj wrote:

Hello,

I've always found that having the option to set an object's value to null is the worst feature of virtually every single language in existence. Why can't we have the haxe language support None | Some<Type> instead?
The ability to assign the null object, who's type is Null to any object is strange. What's really going on, is that from the compiler/type system's perspective, Null is a subtype of every class/type that is created. Yet, it is an exception to every of subtype relationship.
In all other cases,
if x is a subtype of y, then anything you can do to y, you can also do to x (as far as method invocation etc.)
The type system treats Null as a subtype of z, for all objects z, yet it is not the case that anything you can do on an instance of z, you can do on an instance of Null.
For all cases where you are tempted to use a Null value, just use an Option.
Of course, there's the issue of integrating onto different platforms, but it is pretty straightforward to map code that accepts nulls, to Options.

Jordo
--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

John A. De Goes
In reply to this post by Renaud Bardet-2

That's not a good solution. Scala allows arbitrary switching on value types. So, for example, you can write:

val x = y match { case foo: Foo => 1 }

This is more difficult in HaXe because the "has type" operator ":" is overloaded with another meaning inside case expressions. Still, it should be possible to parse something like:

var x = switch(y) {
  case foo: Foo: 1
}

This code would work with any "y", even if not a multitype. Then, when multitypes are added, no special feature or unique syntax needs to be introduced in order to deal with them:

var y: Int | String = "foo";

var x = switch(y) {
  case anyInt: Int: Std.string(anyInt);
  case anyString: String: anyString;
}

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Jan 17, 2011, at 8:18 AM, Renaud Bardet wrote:

Hi, I find this mutliType feature amazing, and I agree with Jordo on the null thing,
I'm just willing to ask about the syntax you're employing, I've seen foo( x : A|B ) and foo( T : A|B )
what is the reflexion beyond that syntax ?
I'm a little afraid of having to do unclear things to handle that feature such as the given example
function foo( x : A|B) {
    switch( x ) {
        case A : //
        case B : //
    }
}
It doesn't seems clear that we are talking about type in this switch-case, and what if I would like to actually switch on that value ?
Could it be a more like defining a pseudo Type, like
function foo( x : T(Int|String) ) {
    switch ( T ) {
        case Int :  
                        switch ( x ) {
                                case 1 : //
                                case 2 : //
                        }
        case String :
                        foo( Std.parseInt( x ) ) ;
}
that's just some thoughts,
 
Renaud

Sent: Monday, January 17, 2011 12:22 PM
Subject: Re: [haXe] Eliminating the ability to have Null.

Oh, and I've never got the chance to thank you, Nicolas, for your awesome and, quite frankly, elegant invention Haxe. I really don't even know how to show my thanks. It's been nothing but a joy to be working with Haxe.
The request to eliminate null, is merely an attempt to take care of the one remaining language feature that I consider to be "impure".
With "untyped" and Dynamic, you (the programmer) declare that you wish to break type safety, and otherwise the experience is very pure. However, null is this evil concept that breaks the type system "on your behalf" without ever asking you, and without you ever indicating that it should. It's the only inconsistency that I've found in the language so far.
Thanks again.

On Mon, Jan 17, 2011 at 12:42 AM, Jordo Odroj <[hidden email]> wrote:
Nicolas, the longer we wait, the harder it will be. If we had multitypes, it wouldn't even have to be Null<ClassName> It would just be:
var x = function (x: MyClass | Null) {

}

If you know that a platform api could return null, then you define the haxe bindings *at the bridge point into the other platform* such that all things that could return null, return Null | TheOtherType. Then, you keep all things pure in haxe land. If anything returns null from another platform api (php etc) when the bindings did *not* indicate Null | Othertype, then that is a runtime system failure. Then we can switch on a compiler mode, where any reference to null is a compiler error (in haxe code). Any api into another platform that comes back null, without defining the return type from the platform api to be Null | OtherType would be a runtime failure. Because, let's face it, you should know the api's well enough to be able to indicate whether or not they return null anyways, so it's not unreasonable to require that a developer indicate this in the platform api's return type. In fact, once we document it, we'll save them much trouble later on.
I think we could do this. Nicolas, I only have a little ML experience, but do you think it would be reasonable for me to implement this? 
As someone who write OCaml, Nicolas, I was hoping you would appreciate where I am coming from. The stronger the typing the less errors we experience in production, and this saves us all time, money, and stress.

This is one of those things, where if you never knew you could have it, you'd never long for it, but once you try it, you'll never want to go back.

Jordo

On Mon, Jan 17, 2011 at 12:32 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 17/01/2011 08:14, Jordo Odroj a écrit :

Hello,

I've always found that having the option to set an object's value to
null is the worst feature of virtually every single language
in existence. Why can't we have the haxe language support None |
Some<Type> instead?

The issue is not the language itself, since it's not that much hard to enforce not-nullness of class members - it still requires some extensive analysis of class constructor call.

The main issue is that many platform API have not been designed with such feature in mind, and that would require the developer to either propagates Null<Foo> types or add == null checks in many places.

I might at some point in the future make some experiments with this, but it's not high priority.

Nicolas

--
haXe - an open source web programming language
http://haxe.org





--
haXe - an open source web programming language
http://haxe.org
--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

Jordo Odroj
My not employ ML style pattern matching that allows you to express structural depth quite easilly? I recalled using them years ago and they were quite powerful.

On Mon, Jan 17, 2011 at 8:28 AM, John A. De Goes <[hidden email]> wrote:

That's not a good solution. Scala allows arbitrary switching on value types. So, for example, you can write:

val x = y match { case foo: Foo => 1 }

This is more difficult in HaXe because the "has type" operator ":" is overloaded with another meaning inside case expressions. Still, it should be possible to parse something like:

var x = switch(y) {
  case foo: Foo: 1
}

This code would work with any "y", even if not a multitype. Then, when multitypes are added, no special feature or unique syntax needs to be introduced in order to deal with them:

var y: Int | String = "foo";

var x = switch(y) {
  case anyInt: Int: Std.string(anyInt);
  case anyString: String: anyString;
}

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Jan 17, 2011, at 8:18 AM, Renaud Bardet wrote:

Hi, I find this mutliType feature amazing, and I agree with Jordo on the null thing,
I'm just willing to ask about the syntax you're employing, I've seen foo( x : A|B ) and foo( T : A|B )
what is the reflexion beyond that syntax ?
I'm a little afraid of having to do unclear things to handle that feature such as the given example
function foo( x : A|B) {
    switch( x ) {
        case A : //
        case B : //
    }
}
It doesn't seems clear that we are talking about type in this switch-case, and what if I would like to actually switch on that value ?
Could it be a more like defining a pseudo Type, like
function foo( x : T(Int|String) ) {
    switch ( T ) {
        case Int :  
                        switch ( x ) {
                                case 1 : //
                                case 2 : //
                        }
        case String :
                        foo( Std.parseInt( x ) ) ;
}
that's just some thoughts,
 
Renaud

Sent: Monday, January 17, 2011 12:22 PM
Subject: Re: [haXe] Eliminating the ability to have Null.

Oh, and I've never got the chance to thank you, Nicolas, for your awesome and, quite frankly, elegant invention Haxe. I really don't even know how to show my thanks. It's been nothing but a joy to be working with Haxe.
The request to eliminate null, is merely an attempt to take care of the one remaining language feature that I consider to be "impure".
With "untyped" and Dynamic, you (the programmer) declare that you wish to break type safety, and otherwise the experience is very pure. However, null is this evil concept that breaks the type system "on your behalf" without ever asking you, and without you ever indicating that it should. It's the only inconsistency that I've found in the language so far.
Thanks again.

On Mon, Jan 17, 2011 at 12:42 AM, Jordo Odroj <[hidden email]> wrote:
Nicolas, the longer we wait, the harder it will be. If we had multitypes, it wouldn't even have to be Null<ClassName> It would just be:
var x = function (x: MyClass | Null) {

}

If you know that a platform api could return null, then you define the haxe bindings *at the bridge point into the other platform* such that all things that could return null, return Null | TheOtherType. Then, you keep all things pure in haxe land. If anything returns null from another platform api (php etc) when the bindings did *not* indicate Null | Othertype, then that is a runtime system failure. Then we can switch on a compiler mode, where any reference to null is a compiler error (in haxe code). Any api into another platform that comes back null, without defining the return type from the platform api to be Null | OtherType would be a runtime failure. Because, let's face it, you should know the api's well enough to be able to indicate whether or not they return null anyways, so it's not unreasonable to require that a developer indicate this in the platform api's return type. In fact, once we document it, we'll save them much trouble later on.
I think we could do this. Nicolas, I only have a little ML experience, but do you think it would be reasonable for me to implement this? 
As someone who write OCaml, Nicolas, I was hoping you would appreciate where I am coming from. The stronger the typing the less errors we experience in production, and this saves us all time, money, and stress.

This is one of those things, where if you never knew you could have it, you'd never long for it, but once you try it, you'll never want to go back.

Jordo

On Mon, Jan 17, 2011 at 12:32 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 17/01/2011 08:14, Jordo Odroj a écrit :

Hello,

I've always found that having the option to set an object's value to
null is the worst feature of virtually every single language
in existence. Why can't we have the haxe language support None |
Some<Type> instead?

The issue is not the language itself, since it's not that much hard to enforce not-nullness of class members - it still requires some extensive analysis of class constructor call.

The main issue is that many platform API have not been designed with such feature in mind, and that would require the developer to either propagates Null<Foo> types or add == null checks in many places.

I might at some point in the future make some experiments with this, but it's not high priority.

Nicolas

--
haXe - an open source web programming language
http://haxe.org





--
haXe - an open source web programming language
http://haxe.org
--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

overriding field access

Renaud Bardet-2
Hi, I'm wondering if there is a way of "overriding" the access to fields
I have
 
class Foo {
    public var foo : Float ;
}
 
and
 
class Bar implements Dynamic<Float> {
    var foos : Array<Foo> ;
    public function resolve ( param : String ) {
        var tmp : Float = .0 ; 
        for ( f in foos)
            if ( Reflect.field( f, param ) != null )
                tmp += Reflect.field( f, param ) ;
        
        return tmp ;
    }
}
 
wich works well, but I'd like to have typeChecking, so is there a way of telling that Bar implements Foo but accessing bar.foo consists in calling bar.resolve( "foo" ) ?
 
Regards,
Renaud

Sent: Tuesday, January 18, 2011 3:42 AM
Subject: Re: [haXe] Eliminating the ability to have Null.

My not employ ML style pattern matching that allows you to express structural depth quite easilly? I recalled using them years ago and they were quite powerful.

On Mon, Jan 17, 2011 at 8:28 AM, John A. De Goes <[hidden email]> wrote:

That's not a good solution. Scala allows arbitrary switching on value types. So, for example, you can write:

val x = y match { case foo: Foo => 1 }

This is more difficult in HaXe because the "has type" operator ":" is overloaded with another meaning inside case expressions. Still, it should be possible to parse something like:

var x = switch(y) {
  case foo: Foo: 1
}

This code would work with any "y", even if not a multitype. Then, when multitypes are added, no special feature or unique syntax needs to be introduced in order to deal with them:

var y: Int | String = "foo";

var x = switch(y) {
  case anyInt: Int: Std.string(anyInt);
  case anyString: String: anyString;
}

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Jan 17, 2011, at 8:18 AM, Renaud Bardet wrote:

Hi, I find this mutliType feature amazing, and I agree with Jordo on the null thing,
I'm just willing to ask about the syntax you're employing, I've seen foo( x : A|B ) and foo( T : A|B )
what is the reflexion beyond that syntax ?
I'm a little afraid of having to do unclear things to handle that feature such as the given example
function foo( x : A|B) {
    switch( x ) {
        case A : //
        case B : //
    }
}
It doesn't seems clear that we are talking about type in this switch-case, and what if I would like to actually switch on that value ?
Could it be a more like defining a pseudo Type, like
function foo( x : T(Int|String) ) {
    switch ( T ) {
        case Int :  
                        switch ( x ) {
                                case 1 : //
                                case 2 : //
                        }
        case String :
                        foo( Std.parseInt( x ) ) ;
}
that's just some thoughts,
 
Renaud

Sent: Monday, January 17, 2011 12:22 PM
Subject: Re: [haXe] Eliminating the ability to have Null.

Oh, and I've never got the chance to thank you, Nicolas, for your awesome and, quite frankly, elegant invention Haxe. I really don't even know how to show my thanks. It's been nothing but a joy to be working with Haxe.
The request to eliminate null, is merely an attempt to take care of the one remaining language feature that I consider to be "impure".
With "untyped" and Dynamic, you (the programmer) declare that you wish to break type safety, and otherwise the experience is very pure. However, null is this evil concept that breaks the type system "on your behalf" without ever asking you, and without you ever indicating that it should. It's the only inconsistency that I've found in the language so far.
Thanks again.

On Mon, Jan 17, 2011 at 12:42 AM, Jordo Odroj <[hidden email]> wrote:
Nicolas, the longer we wait, the harder it will be. If we had multitypes, it wouldn't even have to be Null<ClassName> It would just be:
var x = function (x: MyClass | Null) {

}

If you know that a platform api could return null, then you define the haxe bindings *at the bridge point into the other platform* such that all things that could return null, return Null | TheOtherType. Then, you keep all things pure in haxe land. If anything returns null from another platform api (php etc) when the bindings did *not* indicate Null | Othertype, then that is a runtime system failure. Then we can switch on a compiler mode, where any reference to null is a compiler error (in haxe code). Any api into another platform that comes back null, without defining the return type from the platform api to be Null | OtherType would be a runtime failure. Because, let's face it, you should know the api's well enough to be able to indicate whether or not they return null anyways, so it's not unreasonable to require that a developer indicate this in the platform api's return type. In fact, once we document it, we'll save them much trouble later on.
I think we could do this. Nicolas, I only have a little ML experience, but do you think it would be reasonable for me to implement this? 
As someone who write OCaml, Nicolas, I was hoping you would appreciate where I am coming from. The stronger the typing the less errors we experience in production, and this saves us all time, money, and stress.

This is one of those things, where if you never knew you could have it, you'd never long for it, but once you try it, you'll never want to go back.

Jordo

On Mon, Jan 17, 2011 at 12:32 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 17/01/2011 08:14, Jordo Odroj a écrit :

Hello,

I've always found that having the option to set an object's value to
null is the worst feature of virtually every single language
in existence. Why can't we have the haxe language support None |
Some<Type> instead?

The issue is not the language itself, since it's not that much hard to enforce not-nullness of class members - it still requires some extensive analysis of class constructor call.

The main issue is that many platform API have not been designed with such feature in mind, and that would require the developer to either propagates Null<Foo> types or add == null checks in many places.

I might at some point in the future make some experiments with this, but it's not high priority.

Nicolas

--
haXe - an open source web programming language
http://haxe.org





--
haXe - an open source web programming language
http://haxe.org
--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: overriding field access

Lars Madson
Le 18/01/2011 14:52, Renaud Bardet a écrit :
accessing bar.foo consists in calling bar.resolve( "foo" ) ?
Why not use a gette/setter for foo propertie and directly implements Foo instead of Dynamic ?

Laurent

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: overriding field access

Renaud Bardet-2
Sorry, I should have told that Foo has a large amount of fields,
and not that I'm lazy but it is meant to grow, so can become quite unreadable
 

Sent: Tuesday, January 18, 2011 4:04 PM
Subject: Re: [haXe] overriding field access

Le 18/01/2011 14:52, Renaud Bardet a écrit :
accessing bar.foo consists in calling bar.resolve( "foo" ) ?
Why not use a gette/setter for foo propertie and directly implements Foo instead of Dynamic ?

Laurent


--
haXe - an open source web programming language
http://haxe.org
--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: overriding field access

Cauê W.
I don't think you will be able to do this.

The reason why you can't is that it's inconsistent:


var foo:Bar = new Bar();
trace(foo.foo); //called foo.resolve("foo")

var foo:Foo = new Bar();
trace(foo.foo); //can't call resolve !

2011/1/18 Renaud Bardet <[hidden email]>
Sorry, I should have told that Foo has a large amount of fields,
and not that I'm lazy but it is meant to grow, so can become quite unreadable
 

Sent: Tuesday, January 18, 2011 4:04 PM
Subject: Re: [haXe] overriding field access

Le 18/01/2011 14:52, Renaud Bardet a écrit :
accessing bar.foo consists in calling bar.resolve( "foo" ) ?
Why not use a gette/setter for foo propertie and directly implements Foo instead of Dynamic ?

Laurent


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: overriding field access

Renaud Bardet-2
Ok, I understand, I'll keep it my way and be very carefull
 
Thanks

Sent: Tuesday, January 18, 2011 5:14 PM
Subject: Re: [haXe] overriding field access

I don't think you will be able to do this.

The reason why you can't is that it's inconsistent:


var foo:Bar = new Bar();
trace(foo.foo); //called foo.resolve("foo")

var foo:Foo = new Bar();
trace(foo.foo); //can't call resolve !

2011/1/18 Renaud Bardet <[hidden email]>
Sorry, I should have told that Foo has a large amount of fields,
and not that I'm lazy but it is meant to grow, so can become quite unreadable
 

Sent: Tuesday, January 18, 2011 4:04 PM
Subject: Re: [haXe] overriding field access

Le 18/01/2011 14:52, Renaud Bardet a écrit :
accessing bar.foo consists in calling bar.resolve( "foo" ) ?
Why not use a gette/setter for foo propertie and directly implements Foo instead of Dynamic ?

Laurent


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

Jordo Odroj
In reply to this post by Jordo Odroj
There are many ways to go about this. After thinking about it for a while, it makes sense to employ the convention that any result from another platform must be multityped with Null. This seems pretty simple to make a compiler option for. (I trivialize the matter, but here is the high level description of how we can go about integrating with platforms)
Also, any library that was written under the assumption that Null *SHOULD* be a subtype of any other object reference, we could do the same thing for.

The haxe compiler would have something like:
if (NullNotSubtypeOfObjectPoint) {  // super awesome mode that I propose
     // null is not a valid keyword anywhere,
     // all objects coming from other platforms must be multityped with Null
     // for all libraries that are not written in this special mode, enforce that their return values must be received as multityped with Null
} else {
    // procede as current
}

The two challenges are integrating with platforms, and preexisting libraries. Both of which seem pretty straightforward to at least *describe* at a high level. The implementation could be very difficult. I only have a bit of ML experience, but I can take a stab at this if someone would implement multitypes, and point me in the right direction. In my opinion, haxe is at it's infant stages. I want this language to succeed, because I acknowledge that it hits all the right marks for the current state of web and mobile technology. 
(Note, I'm not assuming that multitypes are the absolute best solution, I'm willing to hear what other's favorites are but the general concept should be the same as far as integrating this with other code):


If you need further convincing, you can consider the opinion of the original "inventor" of null:

"I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."
C.A.R. Hoare

We have the *luxury* of being in the beginning stages of haxe. Note that by "beginning stages" I don't mean that haxe is underdeveloped, but that I see huge possibilities for it. Eliminating null is going to be a great step in this direction.

Jordo

On Mon, Jan 17, 2011 at 6:42 PM, Jordo Odroj <[hidden email]> wrote:
My not employ ML style pattern matching that allows you to express structural depth quite easilly? I recalled using them years ago and they were quite powerful.

On Mon, Jan 17, 2011 at 8:28 AM, John A. De Goes <[hidden email]> wrote:

That's not a good solution. Scala allows arbitrary switching on value types. So, for example, you can write:

val x = y match { case foo: Foo => 1 }

This is more difficult in HaXe because the "has type" operator ":" is overloaded with another meaning inside case expressions. Still, it should be possible to parse something like:

var x = switch(y) {
  case foo: Foo: 1
}

This code would work with any "y", even if not a multitype. Then, when multitypes are added, no special feature or unique syntax needs to be introduced in order to deal with them:

var y: Int | String = "foo";

var x = switch(y) {
  case anyInt: Int: Std.string(anyInt);
  case anyString: String: anyString;
}

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Jan 17, 2011, at 8:18 AM, Renaud Bardet wrote:

Hi, I find this mutliType feature amazing, and I agree with Jordo on the null thing,
I'm just willing to ask about the syntax you're employing, I've seen foo( x : A|B ) and foo( T : A|B )
what is the reflexion beyond that syntax ?
I'm a little afraid of having to do unclear things to handle that feature such as the given example
function foo( x : A|B) {
    switch( x ) {
        case A : //
        case B : //
    }
}
It doesn't seems clear that we are talking about type in this switch-case, and what if I would like to actually switch on that value ?
Could it be a more like defining a pseudo Type, like
function foo( x : T(Int|String) ) {
    switch ( T ) {
        case Int :  
                        switch ( x ) {
                                case 1 : //
                                case 2 : //
                        }
        case String :
                        foo( Std.parseInt( x ) ) ;
}
that's just some thoughts,
 
Renaud

Sent: Monday, January 17, 2011 12:22 PM
Subject: Re: [haXe] Eliminating the ability to have Null.

Oh, and I've never got the chance to thank you, Nicolas, for your awesome and, quite frankly, elegant invention Haxe. I really don't even know how to show my thanks. It's been nothing but a joy to be working with Haxe.
The request to eliminate null, is merely an attempt to take care of the one remaining language feature that I consider to be "impure".
With "untyped" and Dynamic, you (the programmer) declare that you wish to break type safety, and otherwise the experience is very pure. However, null is this evil concept that breaks the type system "on your behalf" without ever asking you, and without you ever indicating that it should. It's the only inconsistency that I've found in the language so far.
Thanks again.

On Mon, Jan 17, 2011 at 12:42 AM, Jordo Odroj <[hidden email]> wrote:
Nicolas, the longer we wait, the harder it will be. If we had multitypes, it wouldn't even have to be Null<ClassName> It would just be:
var x = function (x: MyClass | Null) {

}

If you know that a platform api could return null, then you define the haxe bindings *at the bridge point into the other platform* such that all things that could return null, return Null | TheOtherType. Then, you keep all things pure in haxe land. If anything returns null from another platform api (php etc) when the bindings did *not* indicate Null | Othertype, then that is a runtime system failure. Then we can switch on a compiler mode, where any reference to null is a compiler error (in haxe code). Any api into another platform that comes back null, without defining the return type from the platform api to be Null | OtherType would be a runtime failure. Because, let's face it, you should know the api's well enough to be able to indicate whether or not they return null anyways, so it's not unreasonable to require that a developer indicate this in the platform api's return type. In fact, once we document it, we'll save them much trouble later on.
I think we could do this. Nicolas, I only have a little ML experience, but do you think it would be reasonable for me to implement this? 
As someone who write OCaml, Nicolas, I was hoping you would appreciate where I am coming from. The stronger the typing the less errors we experience in production, and this saves us all time, money, and stress.

This is one of those things, where if you never knew you could have it, you'd never long for it, but once you try it, you'll never want to go back.

Jordo

On Mon, Jan 17, 2011 at 12:32 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 17/01/2011 08:14, Jordo Odroj a écrit :

Hello,

I've always found that having the option to set an object's value to
null is the worst feature of virtually every single language
in existence. Why can't we have the haxe language support None |
Some<Type> instead?

The issue is not the language itself, since it's not that much hard to enforce not-nullness of class members - it still requires some extensive analysis of class constructor call.

The main issue is that many platform API have not been designed with such feature in mind, and that would require the developer to either propagates Null<Foo> types or add == null checks in many places.

I might at some point in the future make some experiments with this, but it's not high priority.

Nicolas

--
haXe - an open source web programming language
http://haxe.org





--
haXe - an open source web programming language
http://haxe.org
--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

Heinz Hölzer-2
Yes, nullability is a big problem.

Let's take this code for example:

enum Option<T> {
    Some(a:T);
    None;
}

var opt = Some(null); // legal code and passing null to an enum constructor can't even be checked inside of the constructor.

Am 20.01.2011 07:53, schrieb Jordo Odroj:
There are many ways to go about this. After thinking about it for a while, it makes sense to employ the convention that any result from another platform must be multityped with Null. This seems pretty simple to make a compiler option for. (I trivialize the matter, but here is the high level description of how we can go about integrating with platforms)
Also, any library that was written under the assumption that Null *SHOULD* be a subtype of any other object reference, we could do the same thing for.

The haxe compiler would have something like:
if (NullNotSubtypeOfObjectPoint) {  // super awesome mode that I propose
     // null is not a valid keyword anywhere,
     // all objects coming from other platforms must be multityped with Null
     // for all libraries that are not written in this special mode, enforce that their return values must be received as multityped with Null
} else {
    // procede as current
}

The two challenges are integrating with platforms, and preexisting libraries. Both of which seem pretty straightforward to at least *describe* at a high level. The implementation could be very difficult. I only have a bit of ML experience, but I can take a stab at this if someone would implement multitypes, and point me in the right direction. In my opinion, haxe is at it's infant stages. I want this language to succeed, because I acknowledge that it hits all the right marks for the current state of web and mobile technology. 
(Note, I'm not assuming that multitypes are the absolute best solution, I'm willing to hear what other's favorites are but the general concept should be the same as far as integrating this with other code):


If you need further convincing, you can consider the opinion of the original "inventor" of null:

" I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."
C.A.R. Hoare

We have the *luxury* of being in the beginning stages of haxe. Note that by "beginning stages" I don't mean that haxe is underdeveloped, but that I see huge possibilities for it. Eliminating null is going to be a great step in this direction.

Jordo

On Mon, Jan 17, 2011 at 6:42 PM, Jordo Odroj <[hidden email]> wrote:
My not employ ML style pattern matching that allows you to express structural depth quite easilly? I recalled using them years ago and they were quite powerful.

On Mon, Jan 17, 2011 at 8:28 AM, John A. De Goes <[hidden email]> wrote:

That's not a good solution. Scala allows arbitrary switching on value types. So, for example, you can write:

val x = y match { case foo: Foo => 1 }

This is more difficult in HaXe because the "has type" operator ":" is overloaded with another meaning inside case expressions. Still, it should be possible to parse something like:

var x = switch(y) {
  case foo: Foo: 1
}

This code would work with any "y", even if not a multitype. Then, when multitypes are added, no special feature or unique syntax needs to be introduced in order to deal with them:

var y: Int | String = "foo";

var x = switch(y) {
  case anyInt: Int: Std.string(anyInt);
  case anyString: String: anyString;
}

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Jan 17, 2011, at 8:18 AM, Renaud Bardet wrote:

Hi, I find this mutliType feature amazing, and I agree with Jordo on the null thing,
I'm just willing to ask about the syntax you're employing, I've seen foo( x : A|B ) and foo( T : A|B )
what is the reflexion beyond that syntax ?
I'm a little afraid of having to do unclear things to handle that feature such as the given example
function foo( x : A|B) {
    switch( x ) {
        case A : //
        case B : //
    }
}
It doesn't seems clear that we are talking about type in this switch-case, and what if I would like to actually switch on that value ?
Could it be a more like defining a pseudo Type, like
function foo( x : T(Int|String) ) {
    switch ( T ) {
        case Int :  
                        switch ( x ) {
                                case 1 : //
                                case 2 : //
                        }
        case String :
                        foo( Std.parseInt( x ) ) ;
}
that's just some thoughts,
 
Renaud

Sent: Monday, January 17, 2011 12:22 PM
Subject: Re: [haXe] Eliminating the ability to have Null.

Oh, and I've never got the chance to thank you, Nicolas, for your awesome and, quite frankly, elegant invention Haxe. I really don't even know how to show my thanks. It's been nothing but a joy to be working with Haxe.
The request to eliminate null, is merely an attempt to take care of the one remaining language feature that I consider to be "impure".
With "untyped" and Dynamic, you (the programmer) declare that you wish to break type safety, and otherwise the experience is very pure. However, null is this evil concept that breaks the type system "on your behalf" without ever asking you, and without you ever indicating that it should. It's the only inconsistency that I've found in the language so far.
Thanks again.

On Mon, Jan 17, 2011 at 12:42 AM, Jordo Odroj <[hidden email]> wrote:
Nicolas, the longer we wait, the harder it will be. If we had multitypes, it wouldn't even have to be Null<ClassName> It would just be:
var x = function (x: MyClass | Null) {

}

If you know that a platform api could return null, then you define the haxe bindings *at the bridge point into the other platform* such that all things that could return null, return Null | TheOtherType. Then, you keep all things pure in haxe land. If anything returns null from another platform api (php etc) when the bindings did *not* indicate Null | Othertype, then that is a runtime system failure. Then we can switch on a compiler mode, where any reference to null is a compiler error (in haxe code). Any api into another platform that comes back null, without defining the return type from the platform api to be Null | OtherType would be a runtime failure. Because, let's face it, you should know the api's well enough to be able to indicate whether or not they return null anyways, so it's not unreasonable to require that a developer indicate this in the platform api's return type. In fact, once we document it, we'll save them much trouble later on.
I think we could do this. Nicolas, I only have a little ML experience, but do you think it would be reasonable for me to implement this? 
As someone who write OCaml, Nicolas, I was hoping you would appreciate where I am coming from. The stronger the typing the less errors we experience in production, and this saves us all time, money, and stress.

This is one of those things, where if you never knew you could have it, you'd never long for it, but once you try it, you'll never want to go back.

Jordo

On Mon, Jan 17, 2011 at 12:32 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 17/01/2011 08:14, Jordo Odroj a écrit :

Hello,

I've always found that having the option to set an object's value to
null is the worst feature of virtually every single language
in existence. Why can't we have the haxe language support None |
Some<Type> instead?

The issue is not the language itself, since it's not that much hard to enforce not-nullness of class members - it still requires some extensive analysis of class constructor call.

The main issue is that many platform API have not been designed with such feature in mind, and that would require the developer to either propagates Null<Foo> types or add == null checks in many places.

I might at some point in the future make some experiments with this, but it's not high priority.

Nicolas

--
haXe - an open source web programming language
http://haxe.org





--
haXe - an open source web programming language
http://haxe.org
--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org




--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

John A. De Goes

True, although if you're using Stax, you should use toOption(), e.g.:

null.toOption();

Or:

possiblyNullValue.toOption();

This will ensure you don't ever have to deal with nulls.

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Jan 20, 2011, at 1:44 AM, Heinz Hölzer wrote:

Yes, nullability is a big problem.

Let's take this code for example:

enum Option<T> {
    Some(a:T);
    None;
}

var opt = Some(null); // legal code and passing null to an enum constructor can't even be checked inside of the constructor.

Am 20.01.2011 07:53, schrieb Jordo Odroj:
There are many ways to go about this. After thinking about it for a while, it makes sense to employ the convention that any result from another platform must be multityped with Null. This seems pretty simple to make a compiler option for. (I trivialize the matter, but here is the high level description of how we can go about integrating with platforms)
Also, any library that was written under the assumption that Null *SHOULD* be a subtype of any other object reference, we could do the same thing for.

The haxe compiler would have something like:
if (NullNotSubtypeOfObjectPoint) {  // super awesome mode that I propose
     // null is not a valid keyword anywhere,
     // all objects coming from other platforms must be multityped with Null
     // for all libraries that are not written in this special mode, enforce that their return values must be received as multityped with Null
} else {
    // procede as current
}

The two challenges are integrating with platforms, and preexisting libraries. Both of which seem pretty straightforward to at least *describe* at a high level. The implementation could be very difficult. I only have a bit of ML experience, but I can take a stab at this if someone would implement multitypes, and point me in the right direction. In my opinion, haxe is at it's infant stages. I want this language to succeed, because I acknowledge that it hits all the right marks for the current state of web and mobile technology. 
(Note, I'm not assuming that multitypes are the absolute best solution, I'm willing to hear what other's favorites are but the general concept should be the same as far as integrating this with other code):


If you need further convincing, you can consider the opinion of the original "inventor" of null:

" I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."
C.A.R. Hoare

We have the *luxury* of being in the beginning stages of haxe. Note that by "beginning stages" I don't mean that haxe is underdeveloped, but that I see huge possibilities for it. Eliminating null is going to be a great step in this direction.

Jordo

On Mon, Jan 17, 2011 at 6:42 PM, Jordo Odroj <[hidden email]> wrote:
My not employ ML style pattern matching that allows you to express structural depth quite easilly? I recalled using them years ago and they were quite powerful.

On Mon, Jan 17, 2011 at 8:28 AM, John A. De Goes <[hidden email]> wrote:

That's not a good solution. Scala allows arbitrary switching on value types. So, for example, you can write:

val x = y match { case foo: Foo => 1 }

This is more difficult in HaXe because the "has type" operator ":" is overloaded with another meaning inside case expressions. Still, it should be possible to parse something like:

var x = switch(y) {
  case foo: Foo: 1
}

This code would work with any "y", even if not a multitype. Then, when multitypes are added, no special feature or unique syntax needs to be introduced in order to deal with them:

var y: Int | String = "foo";

var x = switch(y) {
  case anyInt: Int: Std.string(anyInt);
  case anyString: String: anyString;
}

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Jan 17, 2011, at 8:18 AM, Renaud Bardet wrote:

Hi, I find this mutliType feature amazing, and I agree with Jordo on the null thing,
I'm just willing to ask about the syntax you're employing, I've seen foo( x : A|B ) and foo( T : A|B )
what is the reflexion beyond that syntax ?
I'm a little afraid of having to do unclear things to handle that feature such as the given example
function foo( x : A|B) {
    switch( x ) {
        case A : //
        case B : //
    }
}
It doesn't seems clear that we are talking about type in this switch-case, and what if I would like to actually switch on that value ?
Could it be a more like defining a pseudo Type, like
function foo( x : T(Int|String) ) {
    switch ( T ) {
        case Int :  
                        switch ( x ) {
                                case 1 : //
                                case 2 : //
                        }
        case String :
                        foo( Std.parseInt( x ) ) ;
}
that's just some thoughts,
 
Renaud

Sent: Monday, January 17, 2011 12:22 PM
Subject: Re: [haXe] Eliminating the ability to have Null.

Oh, and I've never got the chance to thank you, Nicolas, for your awesome and, quite frankly, elegant invention Haxe. I really don't even know how to show my thanks. It's been nothing but a joy to be working with Haxe.
The request to eliminate null, is merely an attempt to take care of the one remaining language feature that I consider to be "impure".
With "untyped" and Dynamic, you (the programmer) declare that you wish to break type safety, and otherwise the experience is very pure. However, null is this evil concept that breaks the type system "on your behalf" without ever asking you, and without you ever indicating that it should. It's the only inconsistency that I've found in the language so far.
Thanks again.

On Mon, Jan 17, 2011 at 12:42 AM, Jordo Odroj <[hidden email]> wrote:
Nicolas, the longer we wait, the harder it will be. If we had multitypes, it wouldn't even have to be Null<ClassName> It would just be:
var x = function (x: MyClass | Null) {

}

If you know that a platform api could return null, then you define the haxe bindings *at the bridge point into the other platform* such that all things that could return null, return Null | TheOtherType. Then, you keep all things pure in haxe land. If anything returns null from another platform api (php etc) when the bindings did *not* indicate Null | Othertype, then that is a runtime system failure. Then we can switch on a compiler mode, where any reference to null is a compiler error (in haxe code). Any api into another platform that comes back null, without defining the return type from the platform api to be Null | OtherType would be a runtime failure. Because, let's face it, you should know the api's well enough to be able to indicate whether or not they return null anyways, so it's not unreasonable to require that a developer indicate this in the platform api's return type. In fact, once we document it, we'll save them much trouble later on.
I think we could do this. Nicolas, I only have a little ML experience, but do you think it would be reasonable for me to implement this? 
As someone who write OCaml, Nicolas, I was hoping you would appreciate where I am coming from. The stronger the typing the less errors we experience in production, and this saves us all time, money, and stress.

This is one of those things, where if you never knew you could have it, you'd never long for it, but once you try it, you'll never want to go back.

Jordo

On Mon, Jan 17, 2011 at 12:32 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 17/01/2011 08:14, Jordo Odroj a écrit :

Hello,

I've always found that having the option to set an object's value to
null is the worst feature of virtually every single language
in existence. Why can't we have the haxe language support None |
Some<Type> instead?

The issue is not the language itself, since it's not that much hard to enforce not-nullness of class members - it still requires some extensive analysis of class constructor call.

The main issue is that many platform API have not been designed with such feature in mind, and that would require the developer to either propagates Null<Foo> types or add == null checks in many places.

I might at some point in the future make some experiments with this, but it's not high priority.

Nicolas

--
haXe - an open source web programming language
http://haxe.org





--
haXe - an open source web programming language
http://haxe.org
--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Eliminating the ability to have Null.

justin_mills
Can Stax do flash without nulls, and still let you use haxe normally or
do you have to learn a new approach to code, for me stax is a confusion,
why use it over normal haxe I am just interested, is it easy to install
can I use current haxe code with it or do i mix and match like as3 and
haXe can?

--
haXe - an open source web programming language
http://haxe.org
12