Re: Design by Contract

Hi, On Wed, Feb 11, 2015 at 10:05 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote: > Hi! > > > That one actually looks better to me, but: I'm not sure how > annotation > > syntax is supposed to support expressions or closures, > > > > > > keep AST. > > So we'd have a zval type that is the raw AST? Would it also be available > to user functions or internal functions/classes? It's an intriguing > concept but I'm not sure we appreciate all the consequences of it - > adding new type is a rather big change as everything should support it. > Or did you mean something else? > This is just an initial idea, and some research is required. I don't propose to add new ZVAL type. AST may be just stored internally and accesses through extended Reflection API. This API may provide some classes to represent AST nodes. > > Is it some special form of annotation for this > > purpose only (meh)? > > > > > > yes. some special attributes. requires/ensures/invariant > > Ah, so <<require()>> annotation would work different than any other type > of annotation? Then I don't see any use for it to use annotation syntax > (whatever it would be) - same syntax should mean same or at least > similar function. Maybe I am still missing what you meant. > I don't understand you as well. It should be clear, that annotation should allow declaration of any attributes, and some of them may be used for different purposes. some for DbC. > > > Oh, and <<>> syntax is *ugly* ;) > > > > > > It's from HHVM. I don't like it as well, please, propose the better one. > > Pretty much every other one is better: > Java and the followers, Python: @foo > C#: [foo] > [foo] is already a legal syntax in PHP - array with constant foo. Thanks. Dmitry. > > -- > Stas Malyshev > smalyshev@gmail.com >