Hi Alexander, On Tue, Feb 10, 2015 at 2:44 PM, Alexander Lisachenko < lisachenko...@gmail.com> wrote:
> 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? > > First of all, I know that you have something working, so your opinion and suggestions are important for us. I already told that currently we are in a brainstorming phase We already have two drafts: https://wiki.php.net/rfc/dbc (doc-comment based) https://wiki.php.net/rfc/dbc2 (inspired by D language) both have their pros and cons. > 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. > this should be implemented with zero-cost assert proposed long time ago https://wiki.php.net/rfc/expectations > > Am I one who think that this code is looking weird? > > public function destroy($id) > require(strlen($id) > 10) > return(is_bool($>)) > { > @unlink($this->path . $id); > } > > For me it's quite readable. > > 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($id) > 10)] > [Return => is_bool($__result)) > public function destroy($id) > { > @unlink($this->path . $id); > } > for me it's less readable, but this is a general solution that may be reused for other features. So, it's interesting. > > 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. > I thought about this way, and you are welcome to start composing another RFC. it makes sense and has its advantages. Unfortunately, it relays on many unavailable features that has to be designed as well (annotations, AST manipulation, opcode manipulation), but may be this is a right road. > 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. > D and Effiel approach may work as well, but if you like another (annotation based) approach - be involved into development. At first we'll need 3-rd RFC that defines all the things that must be implemented. I may help, with RFC, design and implementation. Thanks. Dmitry. > > > > 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 > > > > >
