Hi Jakub, Regarding the Null Object, I believe it to be a second hand solution. Having a Null Object that returns 0, null, "" or false for every method call, or a nil that acts as in Objective C that doesn't tell you when is being poked the wrong way is the first step into madness. It will never tell you about runtime errors, and you will find those errors once some data that is being outputed from the systems gets into your DB/Logs/Screen/whatever and just by chance you see that and say "Hey! that wasn't supposed to be there!". Then all hell breaks loose, and you start chasing code that never happens because your data will never be wrong and will always gracefully degrade. I believe that pattern is a bad pattern and humanity should feel bad about it. In fact, I believe it will be a feature that will drive people away from PHP and not towards it. Besides, the whole point of this idea I brought was to avoid checks that the interpreter could catch. If I return a Null Object, I'm forced to always ask for it.
Now, regarding the "NULL belongs to PHP and this language never aimed to become Java" part. That is interesting because a) I never wanted to be Java, and in fact, I want it to be as more different to it as possible because I know what is bad and good and Java. b) As far as I remember, from the beginning of PHP, NULL was as in C a rename for 0. You could use 0, FALSE and NULL indistinctly. I'm not saying to eliminate null. Null does serve some other purposes, specially when you are managing memory, or bits, or whatever. I'm talking about making it represent less things and make the language more expressive. I hope transmitted my idea right. Thanks for the reply, Facundo On Mon, Mar 28, 2016 at 3:13 AM, Kubo2 <kelerest...@gmail.com> wrote: > Hi Facundo Martínez, > > I think the best solution to yourself described problem above would be > the Null Object Design Pattern > (https://en.wikipedia.org/wiki/Null_Object_pattern). In my opinion, > NULL belongs to PHP and this language never aimed to become Java or > similar. > > Jakub > > On 22 March 2016 at 01:34, Facundo Martinez Correa > <fnmartine...@gmail.com> wrote: > > Hello, > > > > I am reaching you in order to obtain feedback on this RFC proposal. > > > > I have been playing with PHP 7 for a project in the company that I am > > currently working for. One of the many drawbacks that I saw in PHP was > the > > there were no types. With type hinting I had confindence again in PHP. > With > > return type hinting a wasn't able to resist to try it. So here I am, > making > > a whole new platform entirely in PHP 7, using type hints in everything. > > Arguments and returns alike. Given my tendency to language purity imagine > > my surprise when my code inadvertently tryied to sneak a NULL into a > method > > expecting an object... And failing thanks to strictness in object and > null > > treatments in the new PHP 7. "SWEET!" I yelled. > > > > Now imagine my dumbfoundedness when a Repository of mine tryed to return > a > > NULL, and because it ought to return have returned a User, it threw a > > TypeError. At first I said "sweet." But then I realized the problem. > There > > are many times where we need uncertainty. Code is a reflection of > reality, > > and as such, it must reflect uncertainty. NULL is a good enough way to > > express nonexistence, albeit a bad one. We have been using it in code for > > years, but it is also used to say many things. Things that cause > > uncertainty in the code. I receive a null, does it mean it doesn't > exists? > > That it will exist? Should I allow it? Is it a good value? I for sure > don't > > know. And in my experience, I have used it for many of those cases. And > in > > many situations that I'm not proud of, all of them at the same time. > > > > So I want to "return a NULL". I want to express uncertainty, a > > nonexistence. But I want to express that I will return something. And I > > want to have this NULL checking at interpretation time. I want > everything, > > and none of the drawbacks. As we say here in Argentina, I want the bread > > and the cake. What can we do to have it? After a bit of thought the Maybe > > monad came to me. > > > > My experience in Haskell reminded me of this. To have a structure than > > represents uncertainty, is the best way to take away the responsibility > > from NULL. To express it in no other way. But my experience in Java has > > taught me that Optional of something is not a good way to tackle the > > problem. I still have to check if my Optional isEmpty. I still have to > > check for null. That is because Java has that type erasure after > > compilation time that doesn't allow me to play nice with polymorphism. > But > > maybe PHP can. Maybe PHP will give me the polymorphism at execution time > to > > discern an empty Maybe from the one that is not. So I don't have to check > > for null ever again in my life. So my code can be free of nulls. So I can > > express uncertainty and nonexistance, while I return a User from my > > repository. > > > > I hope someone would like this idea. I'm also open to suggestions. > > Kind regards > > Facundo Martínez > > > > -- > Cheers, > Kubis >
