Hello PHP internals,
Currently PHP doesn't support what could be a good feature for code
quality, return typing (or if you prefer to call it: return type
hinting).
Since the procedure says that before any real RFC should be done, the
interest for this topic should be gauged, I've drafted something here:
https://gist.github.com/dlsniper/5863012
The goals for this discussion are:
- gauge the interest in having such a feature in PHP.NEXT
- find weak spots in the draft
- find potential problems with the suggested way of doing the implementation
- determine if the advantages would outweigh the disadvantages and
this should go forward as a RFC
As you can see, the draft doesn't include any patch and since my C
skills are mostly nonexistent, I currently can't provide one
unfortunately. I would however love to do it with proper guidance from
someone that could spare some of his/her time to help me out.
This said, thank you very much for your time, consideration and
feedback on this subject.
Best regards,
Florin
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
Hello PHP internals,
Currently PHP doesn't support what could be a good feature for code
quality, return typing (or if you prefer to call it: return type
hinting).Since the procedure says that before any real RFC should be done, the
interest for this topic should be gauged, I've drafted something here:
https://gist.github.com/dlsniper/5863012The goals for this discussion are:
- gauge the interest in having such a feature in PHP.NEXT
- find weak spots in the draft
- find potential problems with the suggested way of doing the
implementation- determine if the advantages would outweigh the disadvantages and
this should go forward as a RFCAs you can see, the draft doesn't include any patch and since my C
skills are mostly nonexistent, I currently can't provide one
unfortunately. I would however love to do it with proper guidance from
someone that could spare some of his/her time to help me out.This said, thank you very much for your time, consideration and
feedback on this subject.Best regards,
FlorinFlorin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan--
PHP really doesn't need function return type declaration since PHP doesn't
even support variable declaration. This would make sense in a language like
C or C++ where the compiler can do static analyses to determine potential
errors before compiling.
Since PHP is a loosely typed dynamic language, however, the fact that a
function can return something of any type is quite liberating and it turns
out that you don't need the static analyses to write better code with PHP,
because most of the errors static analyses helps you with aren't really the
things you are most concerned with. For example consider the following bug:
<?php
function userTimezone($userId, PDO $db) {
$result = [];
if (!($stmt = $db->prepare('SELECT timezone FROM users WHERE
users.id = ?'))) {
return false;
}
if ($stmt->execute([$userId])) {
$result = $stmt->fetchAll(PDO::FETCH_ASSOC);
}
return array_pop($result);
}
?>
If in the above code PDO::prepare returns false (upon failure) for any
reason $stmt will not be of the expected type. In that case the function
returns a boolean false to indicate failure (or it can throw an exception
as well). If the Exception is throw the function's return value is still
implicitly null. However, the return type of the function isn't what we
actually care about here, because it doesn't solve our real problem. The
real problem we care about is the fact that the function failed and
couldn't keep its promise. If we force the function to only return an array
we can't tell the difference between an empty result set or a failure case
unless we strictly stick to exceptions. In none of those cases was the
function's return value type hint helpful.
Sherif,
I have to disagree with you on this in the same way that we have type hints
for input variables on methods, this could also be useful.
Consider an interface with a getter method defined. As it stands now in
php, they're not entirely useful, since you can't define what type of
object your expecting from the implementer. That greatly reduces the
functionality of an interface and this proposal gives solution to that
problem.
Florin,
I think the overall concept is good, I want to see something like this in
the future, but I think this might be the wrong approach. I don't think we
should be hinting primitives. if we're going to have a return type hint on
a method, I would have it match the functionality of the input type hints
for functions we already have, where you can hint at an instance of an
object type, such as Iterator or StdClass, or an array, but not hint
primitives such as int and string, like I currently see in the draft.
Also, you should be aware that your proposed syntax for the return type (
<type> ) is interfering with:
https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
me.
On Wed, Jun 26, 2013 at 5:08 AM, Sherif Ramadan theanomaly.is@gmail.comwrote:
On Wed, Jun 26, 2013 at 5:50 AM, Florin Patan florinpatan@gmail.com
wrote:Hello PHP internals,
Currently PHP doesn't support what could be a good feature for code
quality, return typing (or if you prefer to call it: return type
hinting).Since the procedure says that before any real RFC should be done, the
interest for this topic should be gauged, I've drafted something here:
https://gist.github.com/dlsniper/5863012The goals for this discussion are:
- gauge the interest in having such a feature in PHP.NEXT
- find weak spots in the draft
- find potential problems with the suggested way of doing the
implementation- determine if the advantages would outweigh the disadvantages and
this should go forward as a RFCAs you can see, the draft doesn't include any patch and since my C
skills are mostly nonexistent, I currently can't provide one
unfortunately. I would however love to do it with proper guidance from
someone that could spare some of his/her time to help me out.This said, thank you very much for your time, consideration and
feedback on this subject.Best regards,
FlorinFlorin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan--
PHP really doesn't need function return type declaration since PHP doesn't
even support variable declaration. This would make sense in a language like
C or C++ where the compiler can do static analyses to determine potential
errors before compiling.Since PHP is a loosely typed dynamic language, however, the fact that a
function can return something of any type is quite liberating and it turns
out that you don't need the static analyses to write better code with PHP,
because most of the errors static analyses helps you with aren't really the
things you are most concerned with. For example consider the following bug:<?php
function userTimezone($userId, PDO $db) {
$result = [];
if (!($stmt = $db->prepare('SELECTtimezoneFROM users WHERE
users.id= ?'))) {
return false;
}
if ($stmt->execute([$userId])) {
$result = $stmt->fetchAll(PDO::FETCH_ASSOC);
}
return array_pop($result);
}
?>If in the above code PDO::prepare returns false (upon failure) for any
reason $stmt will not be of the expected type. In that case the function
returns a boolean false to indicate failure (or it can throw an exception
as well). If the Exception is throw the function's return value is still
implicitly null. However, the return type of the function isn't what we
actually care about here, because it doesn't solve our real problem. The
real problem we care about is the fact that the function failed and
couldn't keep its promise. If we force the function to only return an array
we can't tell the difference between an empty result set or a failure case
unless we strictly stick to exceptions. In none of those cases was the
function's return value type hint helpful.
2013/6/26 Maxwell Max@maxvandervelde.com:
Sherif,
I have to disagree with you on this in the same way that we have type hints
for input variables on methods, this could also be useful.
Consider an interface with a getter method defined. As it stands now in
php, they're not entirely useful, since you can't define what type of
object your expecting from the implementer. That greatly reduces the
functionality of an interface and this proposal gives solution to that
problem.Florin,
I think the overall concept is good, I want to see something like this in
the future, but I think this might be the wrong approach. I don't think we
should be hinting primitives. if we're going to have a return type hint on
a method, I would have it match the functionality of the input type hints
for functions we already have, where you can hint at an instance of an
object type, such as Iterator or StdClass, or an array, but not hint
primitives such as int and string, like I currently see in the draft.
Also, you should be aware that your proposed syntax for the return type (
<type> ) is interfering with:
https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
me.
Thanks Maxwell, you summarized very well what I was thinking about it.
So +1 from me for the general feature at a first glance, but it should
then be very close to what is possible with input type hinting.
It makes it possible to write interfaces that acts like specifications
and to easier the writing of:
class Foo {
public function bar($input) {
$return = Baz::foo($input);
if (!$return instanceof ReturnType)
trigger_error("Cannot divide by zero", E_USER_ERROR); //
or throwing some RuntimeException
return $return;
}
}
to:
class Foo {
public function <ReturnType> bar($input) {
return Baz::foo($input);
}
}
On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT patrickallaert@php.netwrote:
2013/6/26 Maxwell Max@maxvandervelde.com:
Sherif,
I have to disagree with you on this in the same way that we have type
hints
for input variables on methods, this could also be useful.
Consider an interface with a getter method defined. As it stands now in
php, they're not entirely useful, since you can't define what type of
object your expecting from the implementer. That greatly reduces the
functionality of an interface and this proposal gives solution to that
problem.Florin,
I think the overall concept is good, I want to see something like this in
the future, but I think this might be the wrong approach. I don't think
we
should be hinting primitives. if we're going to have a return type hint
on
a method, I would have it match the functionality of the input type hints
for functions we already have, where you can hint at an instance of an
object type, such as Iterator or StdClass, or an array, but not hint
primitives such as int and string, like I currently see in the draft.
Also, you should be aware that your proposed syntax for the return type (
<type> ) is interfering with:
https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
me.Thanks Maxwell, you summarized very well what I was thinking about it.
So +1 from me for the general feature at a first glance, but it should
then be very close to what is possible with input type hinting.It makes it possible to write interfaces that acts like specifications
and to easier the writing of:class Foo {
public function bar($input) {
$return = Baz::foo($input);
if (!$return instanceof ReturnType)
trigger_error("Cannot divide by zero", E_USER_ERROR); //
or throwing some RuntimeExceptionreturn $return; }}
to:
class Foo {
public function <ReturnType> bar($input) {
return Baz::foo($input);
}
}
+1 for the global idea as this would help so much OO programs and framework
based programs.
But what Sherif said proves as well the limits of the idea. PHP is not
strongly typed. So each check, should it be type hinting or return type
hinting, has to be done at runtime , which is bad for performances.
Not talking about the type juggling which could lead the programmer as
shooting himself.
Julien.Pauli
On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT <patrickallaert@php.net
wrote:
But what Sherif said proves as well the limits of the idea. PHP is not
strongly typed. So each check, should it be type hinting or return type
hinting, has to be done at runtime , which is bad for performances.Not talking about the type juggling which could lead the programmer as
shooting himself.Julien.Pauli
What about disabling the check in some environments (prod)? It would work
like an assertion I suppose. (Feel free to shoot at me if you think it's a
bad idea)
Marco Pivetta
2013/6/26 Marco Pivetta ocramius@gmail.com:
<shoot> This is typically something that has always been rejected in the past. </shootWhat about disabling the check in some environments (prod)? It would work
like an assertion I suppose. (Feel free to shoot at me if you think it's a
bad idea)
2013/6/26 Julien Pauli jpauli@php.net:
But what Sherif said proves as well the limits of the idea. PHP is not
strongly typed. So each check, should it be type hinting or return type
hinting, has to be done at runtime , which is bad for performances.
It doesn't mean you have to use it, just that it might be used instead
of implementing a manual check in every function/method callers, or,
alternatively, in the function/method itself.
Being done at runtime by the language will for sure not be worst for
performance than doing it manually in pure PHP.
Not talking about the type juggling which could lead the programmer as
shooting himself.
Sure! Hence why if this is taken into account, it should really be
done the same way as it is done for input parameter hinting, to not
introduce what we already don't want there.
On Wed, Jun 26, 2013 at 4:21 PM, Patrick ALLAERT patrickallaert@php.netwrote:
2013/6/26 Julien Pauli jpauli@php.net:
But what Sherif said proves as well the limits of the idea. PHP is not
strongly typed. So each check, should it be type hinting or return type
hinting, has to be done at runtime , which is bad for performances.It doesn't mean you have to use it, just that it might be used instead
of implementing a manual check in every function/method callers, or,
alternatively, in the function/method itself.
Being done at runtime by the language will for sure not be worst for
performance than doing it manually in pure PHP.Not talking about the type juggling which could lead the programmer as
shooting himself.Sure! Hence why if this is taken into account, it should really be
done the same way as it is done for input parameter hinting, to not
introduce what we already don't want there.
I think that the return typehints a bit easier topic than the input type
hinting(for scalars), because that affects the caller, while return type
hinting is more contained: you write the function, you put the return
typehint there, if the method tries to return something else, then your
code is at fault.
So even if we would allow return typehints for scalars that would only
affects those functions where the developer opts-in.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I think that the return typehints a bit easier topic than the input type
hinting(for scalars), because that affects the caller, while return type
hinting is more contained: you write the function, you put the return
typehint there, if the method tries to return something else, then your
code is at fault.
So even if we would allow return typehints for scalars that would only
affects those functions where the developer opts-in.
So a function author doesn't trust himself and therefore we change the
language syntax?
johannes
On Wed, Jun 26, 2013 at 4:48 PM, Johannes Schlüter
johannes@schlueters.de wrote:
I think that the return typehints a bit easier topic than the input type
hinting(for scalars), because that affects the caller, while return type
hinting is more contained: you write the function, you put the return
typehint there, if the method tries to return something else, then your
code is at fault.
So even if we would allow return typehints for scalars that would only
affects those functions where the developer opts-in.So a function author doesn't trust himself and therefore we change the
language syntax?johannes
All,
Thanks for the feedback so far.
I've added the typing for scalars as I thought it would be nice to
have them but if it's easier to start with supporting what we already
have for argument hinting then it would be a great win for the
language nonetheless.
To address the performance concern issues, I think the performance
issues should be very little, like a call to instanceof for example,
but I can't say for sure. Of course benchmarks for the actual
implementation will need to be made and a manual entry should note
that using this feature might have a performance impact if really
needed (as I would imagine in 15000 function calls, something that you
might see in todays frameworks it could have a more visible impact).
@johannes it's not about the author of the function doesn't trust
itself, it's about I'm writing a interface and I expect to receive a
array but someone returns a string or a single value.
That's why I've said that the feature is more about code quality that
new toys for developers. Those who opt-in for using this in interfaces
would guarantee that every implementation of their interface would be
consistent in return type, just like what we have today for arguments,
where you can guarantee that you'll have the type you need in your
method.
If the feedback will be positive for this, as it is right now, I would
also like to start working on a patch for this in 2-3 weeks maybe so
this is a early request for help for anyone that could point me out in
the right direction or champion this patch. I'll make another request
when I'll be ready to start working on the patch.
Best regards.
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
I know this conversation kinda stopped a couple weeks ago, but I want to
throw into the ring that HHVM already has a syntax for return type hinting
and it'd be awesome if we (with my PHP hat on) brought the two
implementations together rather than take them further apart.
In HHVM's case a function might look something like:
function foo(SomeClass $bar, int $baz) : bool {
}
function foo(SomeClass $bar, int $baz) : bool {
}
This does have the advantage that function declarations are still grepable.
In my experience this is one of the loudest complaints about previous ideas.
I know this conversation kinda stopped a couple weeks ago, but I want to
throw into the ring that HHVM already has a syntax for return type hinting
and it'd be awesome if we (with my PHP hat on) brought the two
implementations together rather than take them further apart.In HHVM's case a function might look something like:
function foo(SomeClass $bar, int $baz) : bool {
}
Hi Sara,
Thanks for the input.
While playing with GO I did found that this type of syntax is a bit better.
Since you brought up the discussion, would you think it would make
more sense to actually start and integrate HHVM into PHP rather that
patching it up?
Or better yet, rewrite it with a HH VM in mind?
I know and fully understand it's a gigantic task but at some point in
a software lifecycle there's only so much patching up you can do
before you can't patch it anymore.
Thanks.
Best regards,
Florin
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
Hello,
I'm new with php internal. Here is my first answer but i use php everyday.
I think that the return type is needed in php. When you make an interface,
why are you not sure of the return of the function made by the user ?
Of course you can specified it as comment but if you want to be sure of the
return you have to test it and when the class is implementing your
interface...
That's definitively weird, isn't it?
I use PHPStorm (and I'm probably not the only one here, haha) and love so
much the warning when I'm wrong with return type.
Why is it a feature of phpstorm and not of the language ? Weird. Again.
I hope i help !
Bye.
Le 10 juil. 2013 10:08, "Florin Patan" florinpatan@gmail.com a écrit :
I know this conversation kinda stopped a couple weeks ago, but I want to
throw into the ring that HHVM already has a syntax for return type
hinting
and it'd be awesome if we (with my PHP hat on) brought the two
implementations together rather than take them further apart.In HHVM's case a function might look something like:
function foo(SomeClass $bar, int $baz) : bool {
}
Hi Sara,
Thanks for the input.
While playing with GO I did found that this type of syntax is a bit better.
Since you brought up the discussion, would you think it would make
more sense to actually start and integrate HHVM into PHP rather that
patching it up?
Or better yet, rewrite it with a HH VM in mind?
I know and fully understand it's a gigantic task but at some point in
a software lifecycle there's only so much patching up you can do
before you can't patch it anymore.
Thanks.Best regards,
FlorinFlorin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
While playing with GO I did found that this type of syntax is a bit better.
Yeah, we played with a few formats (including the one originally proposed
and found some issues (like specifying closures as return types: function
function($foo, $bar) ($foo) { return makeCallback($foo); } Even if you
add <> around the return type, that's still a bit.. weird.
Since you brought up the discussion, would you think it would make
more sense to actually start and integrate HHVM into PHP rather that
patching it up?
HHVM isn't built on PHP (apart from a few very small pieces) so
"integrating" it would mean, well... replacing it. It's like suggesting to
integrate linux into windows. :p
Or better yet, rewrite it with a HH VM in mind?
I do think we (again, wearing my PHP hat) should look at plugging in LLVM
or something similar. In my perfect world PHP and HHVM both have enough to
offer that users get to use the tool most appropriate for their needs. For
HHVM that means working on the build system and the runtime. For PHP that
means speeding up and extending the language. We'll never match because
the two projects don't agree on every piece of philosophy, but we can try
to keep close enough to avoid major issues for end users.
-Sara
On Wed, Jun 26, 2013 at 4:48 PM, Johannes Schlüter
johannes@schlueters.dewrote:
I think that the return typehints a bit easier topic than the input type
hinting(for scalars), because that affects the caller, while return type
hinting is more contained: you write the function, you put the return
typehint there, if the method tries to return something else, then your
code is at fault.
So even if we would allow return typehints for scalars that would only
affects those functions where the developer opts-in.So a function author doesn't trust himself and therefore we change the
language syntax?johannes
or not trusting the subsystem that he/she calls, and he/she wants to make a
hard promise about the return value.
I could also mention, that this feature could be used in static analysis
and IDEs(albeit most IDEs out there already supports docblocks).
I'm not saying that this feature is a must, I just wanted to emphasize that
it is a little bit less touchy subject than the (scalar) input typehints.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Johannes,
2013/6/26 Johannes Schlüter johannes@schlueters.de:
So a function author doesn't trust himself and therefore we change the
language syntax?
In the following example:
class Foo {
public function bar($input) {
$return = Baz::foo($input);
if (!$return instanceof ReturnType)
trigger_error("Cannot divide by zero", E_USER_ERROR); //
or throwing some RuntimeException
return $return;
}
}
Baz class can be from a 3rd party software and I may want to enforce
the fact that my Foo::bar() method returns an instance of ReturnType
or throw an exception or trigger an error.
This is moez easily written with this proposition:
class Foo {
public function <ReturnType> bar($input) {
return Baz::foo($input);
}
}
With the same reasoning you had, you would avoid using parameter type
hinting and interfaces for your own project if there's no other people
using it.
Hi.
At the moment we can type hint array, classes, interfaces, callable, etc.
As PHP is loosely typed and has type juggling thinking of (or at least
trying to get PHP to enforce) a particular type (string, int, float,
boolean) would be the wrong way to go - too many different behaviours
(block if not a suitable type, block if not a suitable castable value,
nonblocking with auto juggling, etc.). But if we consider that type
juggling is the domain of the type 'scalar', then this would/could act as a
suitable hinter.
If a method has been designed to accept a scalar, there is nothing to stop
the passing in of a resource, callable, closure or object, etc.
But with the type hint, in my head, it is now no different to any other
type hint.
scalar, callable, interface, class, array (and others I'm sure).
This isn't about trying to cast the value to a type - PHP is intrinsically
loosely typed and that is core to everything. But as the core can easily
tell an array from a callable, then a scalar would seem to fit right in.
And if we can have scalar type hinting, scalar return type hinting
would/should also be possible.
Is this a feasible option?
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT patrickallaert@php.net
wrote:2013/6/26 Maxwell Max@maxvandervelde.com:
Sherif,
I have to disagree with you on this in the same way that we have type
hints
for input variables on methods, this could also be useful.
Consider an interface with a getter method defined. As it stands now in
php, they're not entirely useful, since you can't define what type of
object your expecting from the implementer. That greatly reduces the
functionality of an interface and this proposal gives solution to that
problem.Florin,
I think the overall concept is good, I want to see something like this
in
the future, but I think this might be the wrong approach. I don't think
we
should be hinting primitives. if we're going to have a return type hint
on
a method, I would have it match the functionality of the input type
hints
for functions we already have, where you can hint at an instance of an
object type, such as Iterator or StdClass, or an array, but not hint
primitives such as int and string, like I currently see in the draft.
Also, you should be aware that your proposed syntax for the return type
(
<type> ) is interfering with:
https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
me.Thanks Maxwell, you summarized very well what I was thinking about it.
So +1 from me for the general feature at a first glance, but it should
then be very close to what is possible with input type hinting.It makes it possible to write interfaces that acts like specifications
and to easier the writing of:class Foo {
public function bar($input) {
$return = Baz::foo($input);
if (!$return instanceof ReturnType)
trigger_error("Cannot divide by zero", E_USER_ERROR); //
or throwing some RuntimeExceptionreturn $return; }}
to:
class Foo {
public function <ReturnType> bar($input) {
return Baz::foo($input);
}
}+1 for the global idea as this would help so much OO programs and framework
based programs.But what Sherif said proves as well the limits of the idea. PHP is not
strongly typed. So each check, should it be type hinting or return type
hinting, has to be done at runtime , which is bad for performances.Not talking about the type juggling which could lead the programmer as
shooting himself.Julien.Pauli
Hi,
Type juggling is explicitly not allowed in the draft and I would hope
it can remain the same in the final implementation.
That's actually one of the things I want to prevent.
I love PHP because of type juggling which can be very handy at times
but for such feature this would be a total no no.
As for limited applicability, I think that frameworks could benefit
greatly from this as well as systems where you really count on having
the least surprise possible from code. And as more people turn to PHP
to bootstrap their startup, idea or whatnot, having more code quality
features would only help the language to maintain its traction and
improve the life all-around.
Best regards
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
Hi!
Currently PHP doesn't support what could be a good feature for code
quality, return typing (or if you prefer to call it: return type
hinting).
What changed since the last time we discussed this?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Currently PHP doesn't support what could be a good feature for code
quality, return typing (or if you prefer to call it: return type
hinting).What changed since the last time we discussed this?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi,
Well I don't want to sound disrespectful, but to be honest, nothing
really. Just the year and the fact that I don't want to allow for
double return types, like object or null or false, like in the other
proposal, if you would read the gist. While I would like to have full
type hinting available, including scalars as well, I think we could
greatly benefit from it even without them.
Like I've said, it's about code quality, something that PHP
programmers lack today badly because PHP is so flexible (don't even
try to argue with that).
As for the argument of don't design features that are optional, like
you've said in the past discussion, here's a optional feature that
everyone uses it today: argument type hinting. Is it optional, yes?
Could we live without it? Yes. Would everyone be sane without it? Not
sure.
PHP is too flexible for its own good. The fact that we have good use
cases for such a feature, just look at the thread so far, makes is
useful to consider. And I don't understand why having return typing
would be such a bad thing when we already have argument typing, which
is a half baked feature (even worst, no?) as it doesn't allow for
scalar hinting. And just having this half baked feature in the
language makes is very unattractive for some people and reduces the
code quality, but for others it's extremely useful, do you want to
argue that we don't need this because .... ?
Best regards
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan