Silly question time again ...
Currently I have an array of variables and the docblock annotation tells
me just what each element is intended to be. I process the variables on
that basis and while it may be helpful to have some higher level of
'restraint', I have a working flexible system. As a variable is
processed it is constrained by the appropriate rules. If PHP adds 'Type
Hints' they will only apply to where I am passing an array variable, and
the type hint adds additional processing to that which I already
maintain myself. How will that improve performance?
Add to this equation that the type and constraints of a variable may
well vary from one record set to another. It may well be that a fixed
set of types can be defined, but these are not the types currently being
defined and would include date types in parallel with a group of numeric
types.
Passing 'strict' types in some cases just does not compute in my book,
and even 'coercive' types only addresses a subset of the types needed so
that it adds another layer of 'checking' over what we already have in
much of the existing user code base. People keep going on about
different rule sets but this just adds another set of 'rules' rather
than a single solution.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Lester,
I am not sure I understand well, but the extended type syntax partially described in https://wiki.php.net/rfc/dbc may correspond to what you describe. Such extended syntax will be part of 'Design by Contract', meaning it's potentially too slow to run in production and checks can be turned on and off globally. When it is available, PHP argument type hints will become simplified fast checks that run every time, even in production.
Extended types will support nested syntax as complex as 'object(Iterable)|array('id' => int(]0:), * => string|array(string))'. No limit to the syntax you may support here. It will also be available as a dynamic feature which will allow to check a variable against a dynamically-defined type. This will bring dramatic performance improvement in data validation. I don't imagine type hints will bring much in terms of overall performance.
I guess that's what you mean but please confirm. I think this will be my next project for PHP, after STH if it passes.
Regards
François
De : Lester Caine [mailto:lester@lsces.co.uk]
Currently I have an array of variables and the docblock annotation tells
me just what each element is intended to be. I process the variables on
that basis and while it may be helpful to have some higher level of
'restraint', I have a working flexible system. As a variable is
processed it is constrained by the appropriate rules. If PHP adds 'Type
Hints' they will only apply to where I am passing an array variable, and
the type hint adds additional processing to that which I already
maintain myself. How will that improve performance?
It won't, except if you remove some redundant checks from your PHP code. Type checks performed by STH are faster than the equivalent PHP code, that's the only possible performance improvement I imagine.
Add to this equation that the type and constraints of a variable may
well vary from one record set to another. It may well be that a fixed
set of types can be defined, but these are not the types currently being
defined and would include date types in parallel with a group of numeric
types.Passing 'strict' types in some cases just does not compute in my book,
and even 'coercive' types only addresses a subset of the types needed so
that it adds another layer of 'checking' over what we already have in
much of the existing user code base. People keep going on about
different rule sets but this just adds another set of 'rules' rather
than a single solution.--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Lester,
I am not sure I understand well, but the extended type syntax partially described in https://wiki.php.net/rfc/dbc may correspond to what you describe. Such extended syntax will be part of 'Design by Contract', meaning it's potentially too slow to run in production and checks can be turned on and off globally. When it is available, PHP argument type hints will become simplified fast checks that run every time, even in production.
Extended types will support nested syntax as complex as 'object(Iterable)|array('id' => int(]0:), * => string|array(string))'. No limit to the syntax you may support here. It will also be available as a dynamic feature which will allow to check a variable against a dynamically-defined type. This will bring dramatic performance improvement in data validation. I don't imagine type hints will bring much in terms of overall performance.
I guess that's what you mean but please confirm. I think this will be my next project for PHP, after STH if it passes.
My point is simply that 'Type checks performed by STH are faster than
the equivalent PHP code' is only true if ... WHEN COMBINED WITH THE
EXISTING variable validation ... there IS a saving. In my book the type
check is simply part of the range validation so splitting those two does
not make sense. Once I've set up for one check, the other validations
simply follow on. If I ADD further 'magic' checks by using this 'new
feature' it does not do the whole job so I still need the existing
checks anyway.
Reworking 15+ years of code to create 'dbc' versions of the existing
annotations is another drain on available time. I can see someone
writing a 'converter' program to populate some parts of this, but I'm
not sure just how helpful that would be. Just as going through libraries
to see where someone has stripped the docblock and replaced it with the
'new fangled' stuff be that dbc or type hinting. Which is where I would
like existing tools to remain an option, so libraries would need to be
maintained as 'legacy' and 'new' even if we have to maintain those
ourselves :(
Currently I have an array of variables and the docblock annotation tells
me just what each element is intended to be. I process the variables on
that basis and while it may be helpful to have some higher level of
'restraint', I have a working flexible system. As a variable is
processed it is constrained by the appropriate rules. If PHP adds 'Type
Hints' they will only apply to where I am passing an array variable, and
the type hint adds additional processing to that which I already
maintain myself. How will that improve performance?It won't, except if you remove some redundant checks from your PHP code. Type checks performed by STH are faster than the equivalent PHP code, that's the only possible performance improvement I imagine.
Add to this equation that the type and constraints of a variable may
well vary from one record set to another. It may well be that a fixed
set of types can be defined, but these are not the types currently being
defined and would include date types in parallel with a group of numeric
types.Passing 'strict' types in some cases just does not compute in my book,
and even 'coercive' types only addresses a subset of the types needed so
that it adds another layer of 'checking' over what we already have in
much of the existing user code base. People keep going on about
different rule sets but this just adds another set of 'rules' rather
than a single solution.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Lester,
De : Lester Caine [mailto:lester@lsces.co.uk]
Reworking 15+ years of code to create 'dbc' versions of the existing
annotations is another drain on available time. I can see someone
writing a 'converter' program to populate some parts of this, but I'm
not sure just how helpful that would be.
Please read the document I reference before giving opinion.
The mechanism described here is based on code block information. It uses existing information and extends the syntax to check for more complex types. That's why I said it should fit your needs.
Not reading the document and replying negatively just you because I talked about DbC is poor, imo. DbC is just a concept, not an implementation. While alternate proposals may religiously copy syntax from D or Eiffel, I chose to adapt it the PHP way. For different reasons, including the ones you give (compatibility with pre-existing info), I chose to implement that by an extension of doc block syntax.
So, if you want to give an opinion, please read https://wiki.php.net/rfc/dbc first.
Just as going through libraries
to see where someone has stripped the docblock
This can be checked too, on a limited extent, as well as compatibility with possible PHP type hints. Ideally, it shouldn't be in comments, but is was done this way. And I am not convinced by the ' automatic conversion' way.
The only issue is that several list members are absolutely opposed to base anything on doc comments, despite the fact it has proved useful for years. Although I asked several times, none took the time to explain me why. It must be ovious, but not to me. So, an RFC proposing to extend doc block syntax has no chance to pass. It was already beginning in pre-discussions about DbC with constructive posts like : "No doc block. Period.".
However, I think this can be fully implemented in an extension, with no change to the core. So, no need to approve an RFC !
Hope to get your thoughts soon.
Regards
François
Hi Lester,
De : Lester Caine [mailto:lester@lsces.co.uk]
Reworking 15+ years of code to create 'dbc' versions of the existing
annotations is another drain on available time. I can see someone
writing a 'converter' program to populate some parts of this, but I'm
not sure just how helpful that would be.Please read the document I reference before giving opinion.
OK hands up ... with so many competing rfc's at the moment I was getting
mixed up with the 'alternative' formats. Actually I seem to have
something cached wrong locally :(
The mechanism described here is based on code block information. It uses existing information and extends the syntax to check for more complex types. That's why I said it should fit your needs.
Not reading the document and replying negatively just you because I talked about DbC is poor, imo. DbC is just a concept, not an implementation. While alternate proposals may religiously copy syntax from D or Eiffel, I chose to adapt it the PHP way. For different reasons, including the ones you give (compatibility with pre-existing info), I chose to implement that by an extension of doc block syntax.
So, if you want to give an opinion, please read https://wiki.php.net/rfc/dbc first.
See notes below.
Just as going through libraries
to see where someone has stripped the docblockThis can be checked too, on a limited extent, as well as compatibility with possible PHP type hints. Ideally, it shouldn't be in comments, but is was done this way. And I am not convinced by the ' automatic conversion' way.
A practical example is a package I'm trying to find some time to support
- phpgedview. The original has nicely documented code, while the
webtrees port reworked that to an alternate format which both made
following changes impractical, but more important made the code unusable
with phpdocumentor. A number of other libraries are suffering from the
same 'modernization' so it would be nice to refresh the original phpdoc
annotation with a modern raison-detra.
The only issue is that several list members are absolutely opposed to base anything on doc comments, despite the fact it has proved useful for years. Although I asked several times, none took the time to explain me why. It must be ovious, but not to me. So, an RFC proposing to extend doc block syntax has no chance to pass. It was already beginning in pre-discussions about DbC with constructive posts like : "No doc block. Period.".
Personally I'm 'docblock only'!
And I would prefer all of this type hinting was docblock only as well.
Analysing and profiling the code quality just like profiling SQL script
... a job that is done ON the code not IN the code, and if all of the
overhead of annotation can be stripped simply by ignoring the comments
then that has to be good?
However, I think this can be fully implemented in an extension, with no change to the core. So, no need to approve an RFC !
The bit I don't like with this is the same as a number of other
proposals. How errors are handled. Although that is just implementation.
I still prefer old school program flow, and throwing exceptions are only
appropriate when you are unable to process the 'error'. If variables
being passed to a function don't meet the conditions then the program
picks that up and produces an appropriate user message related to that
particular call rather than a programmers line number. It's the
difference between coding for the coder or coding for the user?
triangleArea says there is a DbC error, but the user needs to be advised
if possible just what value is a problem. It may be that a number that
was input at speed is a character short so the variable processing and
this is picked up even before triangleArea is called but it is the
constraints in triangleArea that provide the programmer with the
information on how to verify the inputs. That the right type is passed
is identified here as well so adding that data to the function call is a
waste of processing if the validation has already been done?
From a practical point of view, the annotation details may well be used
to populate javascript side validation and while I can see how your
'requires' clause can be added to add the size of a variable, an already
sized 'type' removes the need to add multiple 'requires' entries where a
variable is not otherwise constrained.
As you say, all this can be handled differently by different extensions
and third party tools and the phpdoc/docblock data is flexible, but the
rfc details how it will be used for a particular use senario
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk