Martin Scotta
On Thu, Apr 28, 2011 at 5:15 PM, Peter Lind <peter.e.l...@gmail.com> wrote:
> 2011/4/28 Martin Scotta <martinsco...@gmail.com>:
>
> * snip *
>
> > IMHO I would not trust on any return value, as PHP did not ensure
> anything
> > about them.
> > Even more, I do not write code that depend on return values, I prefer to
> > use input/output parameters,
>
> I cannot help but wonder why PHP is your language of choice. I mean no
> disrespect, but PHP does not have strict typing (for a reason) and
> forcing it upon PHP seems strange to me. Seeing as a) you'll either
> have to implement the return type hinting yourself in which case you'd
> know anyway what the return value is or b) you'd have to have others
> implement it in their libraries in which case you'd have to wait years
> for any noticeable effect, the feature seems useful only in edge cases
> (such as Hiphop, which I think one can question the mainstream
> usefulness of, currently).
>
I understand why PHP does not have strict typing as much as I understand why
PHP do not have good-qualities third-party libraries.
I'm not saying that there aren't good libraries, but the language has many
holes that makes almost impossible to build solid library (ie: include)
All the strictness of ppp, typehint and the like are not restrict things,
they are meant as boundaries for client code, to ensure the correct and well
defined behavior.
It's ok if you write all you code as procedural, or you don't like to write
classes, but IMHO the language should provide a solid foundation for them,
this way you can rely on libraries for common task and make your procedural
code even simpler, shorter and safer.
I'm not sure if return typehint will be a good idea, but I'm not against it.
I believe the language has to deal with other "pending" stuff prior to this.
PHP has many blind areas, whenever you call something, you don't know if you
will return or it will just die in a non-sense Fatal error.
> Personally, I read code if I'm not sure what a given function/method
> will return - or just test. I actually thought unit tests took care of
> issues like this. I don't think having a list of possible return
> values would make things simpler than the good old "try it and see" -
> which is one of the greatest assets of PHP.
>
> > This is the safer way I've found to achieve the same behavior
> >
> > function no_return(ReturnStatus $returnStatus) {
> > doSomething();
> >
> > if ( itWasOk() )
> > {
> > $returnStatus->setReturnValue( new Foo ); // return type hint
> > $returnStatus->success(); // return status
> > }
> > elseif ( isWasCritical() )
> > {
> > $returnStatus->setException( new RuntimeException );
> > $returnStatus->exception(); // return status
> > }
> > else
> > {
> > $returnStatus->fail(); // return status
> > }
> > }
> >
> > Of course I don't write all functions like this.
> > This is pattern I use when I need to ensure that the type returned is
> valid.
>
> I just return what I need to from the function/method or throw an
> exception. Indicating that you want to throw an exception instead of
> actually throwing one seems ... overly polite, at best. As far as I
> can tell, you'd have to check the ReturnStatus object anyway, so I
> don't see how you're any safer (PHP has functions for checking null
> values, false values, try/catch blocks and other things too). But
> maybe we're dealing with very different development environments and I
> just cannot see the usefulness of the suggested as it wouldn't make a
> positive difference in mine.
>
> Just a perspective from a typical webdev.
> Regards
> Peter
>
> --
> <hype>
> WWW: plphp.dk / plind.dk
> LinkedIn: plind
> BeWelcome/Couchsurfing: Fake51
> Twitter: kafe15
> </hype>
>
