Hello, internals!
DbC is good thing, but the way you want to do this via language changes is
really awful. Why do you want to add more custom features into the
language, instead of providing an API to extend it in a more natural way by
framework developers?
Many existing implementation of DbC is just kind of bytecode compilers and
IDE tools. Main idea of DbC is to help developer with writing a better code
without errors. But then, during compiling (production mode) all checks
will be removed.
Am I one who think that this code is looking weird?
public function destroy($id)
require(strlen <http://www.php.net/strlen>($id) > 10)
return(is_bool <http://www.php.net/is_bool>($>))
{
@unlink <http://www.php.net/unlink>($this->path . $id);
}
This part of code is breaks block structure of function, adding custom
part of code, which is not related to the function logic itself.
Instead of doing this weird syntax only for personal fun, just think
about more general usages of parser and assertions.
As you know, I'm working with aspect-oriented programming in PHP and
have a library for that. And it wasn't easy to implement it, because
there is no API for that from PHP. This techniques can be also used
for DbC as well.
So, my suggestion is to drop current rfc and start more general one,
called "PHP Language Extension API", which will include an API for
defining metadata and API for opcode manipulation. Compare previous
example with another one with plain metadata:
[Require => strlen <http://www.php.net/strlen>($id) > 10)]
[Return => is_bool <http://www.php.net/is_bool>($__result))
public function destroy($id)
{
@unlink <http://www.php.net/unlink>($this->path . $id);
}
This code then will be parsed and PHP hooks that were registered by
register_parser_extension() will be called and extension will
produce a valid opcodes for that for method destroy(), by modifying AST-node.
This way is much elegant and can be reused later for many features,
like Design By Contracts, native SQL support syntax in PHP (LINQ),
Aspect-Oriented Programming, hooks and much more.
Just stop to create custom features in the engine itself and give this
work for framework and PHP-extension developers.
2015-02-10 13:32 GMT+03:00 Lester Caine <les...@lsces.co.uk>:
> On 09/02/15 23:47, Yasuo Ohgaki wrote:
> > The RFC draft is ready.
> > https://wiki.php.net/rfc/dbc2
>
> > These contracts are evaluated development time only. Therefore, there is
> no performance penalty with DbC.
>
> Sorry but that makes no sense to me at all. If this is something only to
> use with an IDE then why does it have to have anything that is visible
> at 'run time'? This seems to be going down the track of "we will be
> compiling this eventually" and that is just not what PHP *IS* about.
> These are more hints, but assume that at runtime what they define is not
> relevant?
>
> ALL of this discussion on type hinting how ever it is handled is simply
> sidestepping the major plus on PHP with associative arrays. I see no
> point expanding every database record read to 'magic access functions'
> for multiple variables and it *IS* the scalar values stored in these
> arrays that needs the 'hint/constraint' control.
>
> I am getting even more confused about just what all the different
> factions are trying to achieve. Yes I know I can totally ignore all of
> it, but with my current tools losing traction because of all the 'better
> ways of working' what in my opinion IS the best way to allow different
> factions to add their own pet style is drowning simple clean solutions
> such as docblock.
>
> --
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
