Re: [PHP-DEV] RFC: Expectations

Hi Joe, is there any penalty of catch-AssertionException-blocks? Are those eliminated in production code? Thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Annotations in PHP7

Hi List, this may be off-topic. However i'm wondering how this could be an annotation? It looks like code. Why not include this into proper method? What am i missing? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Annotations in PHP7

Am 19.02.2015 um 08:14 schrieb Dmitry Stogov: On Thu, Feb 19, 2015 at 2:12 AM, François Laupretre > wrote: If I understand Dmitry correctly, this would be stored as the compiler internal representation of the 'new Entity("foo")' code, but this wouldn't be exe

Re: [PHP-DEV] [VOTE] Expectations

Am 20.02.2015 um 12:27 schrieb Joe Watkins: I work on a massive codebase, 3m loc, the ability to document that we throw SomeAssertionException in *insert circumstance* is extremely appealing. It would allow us to structure the documentation and the code in a way that really makes sense especially

Re: [PHP-DEV] [VOTE] Expectations

The alternatives are not nice, in my opinion. What are this alternatives? What are the drawbacks of "warning" in production code? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Expectations

AssertionExceptions are not intended to be caught, they are intended to be seen, in a specific environment. Joe, your argumentation is around how (not) to use exceptions. I can see your point and it's valid. My point is about not to implement exceptions at all. If exceptions are not intende

Re: [PHP-DEV] [VOTE] Expectations

Am 20.02.2015 um 15:09 schrieb Nikita Popov: On Fri, Feb 20, 2015 at 3:02 PM, Crypto Compress mailto:cryptocompr...@googlemail.com>> wrote: AssertionExceptions are not intended to be caught, they are intended to be seen, in a specific environment. Joe

Re: [PHP-DEV] [VOTE] Expectations

To be harsh: All comments in favour of throwing exceptions here, substantiate theirs needs with dead, never reached and potentially buggy code. The *changed code flow in production* is the big pitfall of this RFC and an absolute no-go. I like zero-cost assertions but throwing exceptions is wron

Re: [PHP-DEV] [VOTE] Expectations

Am 21.02.2015 um 04:10 schrieb Yasuo Ohgaki: Hi Crypto, On Fri, Feb 20, 2015 at 11:02 PM, Crypto Compress mailto:cryptocompr...@googlemail.com>> wrote: AssertionExceptions are not intended to be caught, they are intended to be seen, in a specific environment. Joe

Re: [PHP-DEV] [VOTE] Expectations

Am 28.02.2015 um 20:08 schrieb Patrick Schaaf: Am 28.02.2015 19:32 schrieb "Crypto Compress" mailto:cryptocompr...@googlemail.com>>: > > class BankAccount { > function Add($amount) { > assert($amount > 0); > // ... code block ...

Re: [PHP-DEV] static constructor

Hello Johannes, class Foo { private static function __static() { throw new Exception("boom"); } } while(true) { try { $foo = new Foo; } catch (Exception ex) {} } Would this code be valid? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, vi

Re: [PHP-DEV] static constructor

Am 12.03.2015 um 12:33 schrieb Johannes Ott: Am 12.03.2015 um 12:16 schrieb Crypto Compress: Hello Johannes, class Foo { private static function __static() { throw new Exception("boom"); } } while(true) { try { $foo = new Foo; } catch (Ex

Re: [PHP-DEV] static constructor

Hello Johannes, in other mails you argue with Rowan about global state. I think it's better to focus on innovation of "class context" in global scope, as it's impossible to reason the disadvantages of global state away. (Discussions on variable scope are painful too.) And two questions: 1. B

Re: [PHP-DEV] [VOTE] Make empty() a Variadic

Am 12.03.2015 um 20:42 schrieb Thomas Punt: The only compromise I can think of (though not sure on its feasibility) would be to have a flag as the last parameter that defaulted to logically AND'ing its args with the ability to switch the semantics to logically OR the args. Hello Thomas, how a

Re: [PHP-DEV] [VOTE] Make empty() a Variadic

Am 13.03.2015 um 09:57 schrieb Matteo Beccati: On 13/03/2015 07:46, Crypto Compress wrote: how about two separate methods all_empty() and non[e]_empty()? How about empty() and full() ? Ok, that was a bad attempt as a joke, but please no ;) Hello Matteo, don't get your point. Ar

Re: [PHP-DEV] static constructor

Am 13.03.2015 um 11:30 schrieb Johannes Ott: Am 13.03.2015 um 07:45 schrieb Crypto Compress: Hello Johannes, in other mails you argue with Rowan about global state. I think it's better to focus on innovation of "class context" in global scope, as it's impossible to reason

Re: [PHP-DEV] [VOTE] Make empty() a Variadic

how about two separate methods all_empty() and non[e]_empty()? How about empty() and full() ? Ok, that was a bad attempt as a joke, but please no ;) don't get your point. Are you against my naming suggestions or the possibility to check many vars on emptiness? There are these two groups with c

Re: [PHP-DEV] static constructor

So I do not see the need of a explicit class deconstructor, because the language should already react correctly on this issues as I can see so far The language cannot know the order of dependencies and how to destruct them. A dependcy between destructors of instances, which the language have t

Re: [PHP-DEV] static constructor

I think I now get the misunderstanding I had on your destructor question Sorry for confusion. My points are agnostic about implementation details and concrete code. It's up to ppl to use this feature as they like. - first point is a logical conclusion: If there is a cctor, there should be

Re: [PHP-DEV] [RFC] Loosening heredoc/nowdoc scanner

Hi, Manual: "Also, the identifier must follow the same naming rules as any other label in PHP: it must contain only alphanumeric characters and underscores, and must start with a non-digit character or underscore." RFC: "Ends a quotation when the closing identifier is followed by a newline o

Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http

* Why should we have our own HTTP API and not follow PSR-7? possible points: - PHP-FIG propose no implementations; pecl_http does - PHP-FIG focus on frameworks; pecl_http in core is useable without dependencies by every simple script - PSR-7 is a moving target; pecl_http exists for ten years

Re: [PHP-DEV] [RFC] Immutable variables and objects

The with*() methods in PSR-7 are documented to return a new instance, not modify the existing instance. Yes, there's no way in PHP itself to force that syntactically, which is why documentation exists. :-) Also, in the benchmarks we've run the performance cost of all those new objects is measu

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

I would go with Http\ Why not the reserved Php\Http\? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Property Accessors for 5.5

Hello Clint, Nikita and Stas. > To facilitate complete functionality with properties it is necessary to > provide accessor functions to act on isset() and unset() calls. > Note: isset & unset implementations are always provided with default > implementations unless the author explicitly defines t

Re: [PHP-DEV] [VOTE] Alternative typehinting syntax for accessors

Hello Nikita, for me this "maybe-of-type"-typehinting is a small progression in the right direction. But "Default values and nullability" would break existing code as you need to add a default null at "design-time" (BC break): a = $a; $this->b = $b; } } // test only a $c = new C("f

Re: [PHP-DEV] [VOTE] Alternative typehinting syntax for accessors

Am 21.01.2013 23:59, schrieb Nikita Popov: > Sorry if it wasn't clear: The nullability stuff only applies if a typehint > is used. If no typehint is used, then you can freely assign null, regardless > of whether or not you have the "= null" in the declaration > (no typehint = everything's valid

Re: [PHP-DEV] [VOTE] Property Accessors for 5.5

Am 22.01.2013 22:27, schrieb Clint Priest: property accessors and magic accessors use the same pre/post function and logic So this is the reason for some "magic" behaviour of "property accessors". Logically "property accessors" may be a subset of "magic accessors" but not the other way around.

Re: [PHP-DEV] C# properties vs. accessors RFC

> I'd just like to point out the fact that RFC v1.1 from a year ago was exactly as above but people wanted all of these other features. They were not a property, they had no "guarding", no unset, isset, etc. The original RFC that was exactly as c# had it, nobody liked it. It was changed to its

Re: [PHP-DEV] C# properties vs. accessors RFC

Hello Levi, Agreed, but if they are automatically generated then I see no harm in allow custom `isset` and `unset` behavior as long as it doesn't get in the way or complicate things. If override of isset/unset is possible, we will end up debugging: true === isset($this->someUninitializedV

Re: [PHP-DEV] C# properties vs. accessors RFC

Well actually you're right. .3 was written by Dennis long ago and I wrote accessors to be exactly as that document described except where there was ambiguity. @Steve Clay: this would be a perfect point to start with

Re: [PHP-DEV] C# properties vs. accessors RFC

Hello! 1) not able to vote 2) looked at patch 3) do not understand the patch so i have a question regarding guards... e.g.: guard->in_unset = 1; /* Prevent recursion */ zend_call_method_with_1_params(&object, zobj->ce, &zobj->ce->__unset, ZEND_UNSET_FUNC_NAME, NULL, member); guard->in_unset =

Re: [PHP-DEV] C# properties vs. accessors RFC

Thank you! Will look at it tomorrow. Am 24.01.2013 00:45, schrieb Clint Priest: On 1/23/2013 5:04 PM, Crypto Compress wrote: guard->in_unset = 1; /* Prevent recursion */ zend_call_method_with_1_params(&object, zobj->ce, &zobj->ce->__unset, ZEND_UNSET_FUNC_NAME, NULL, membe

Re: [PHP-DEV] C# properties vs. accessors RFC

Am 24.01.2013 02:12, schrieb Levi Morrison: I also don't like the `?` for `nullable`. Just stick with PHP convention and do: class Foo { public Bar $bar = NULL; } There is no such PHP convention. The PHP convention is *not restrict type* (+"loosely typed" addons). So N

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

Hello List, how about sort of Tick-Tock development model? Tick = optimize/bugfix Tock = shiny new features e.g. http://en.wikipedia.org/wiki/Intel_Tick-Tock cryptocompress -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add get_object_constants and get_class_constants

Hello Mike, thank you! It is a useful feature to me. My usecase are checks on defined constants: e.g. on my Bitmasks i want to check if given position-value is valid for current bitmask: http://3v4l.org/CR2qJ e.g. in my Exception Handler i check Exception-Codes: if not defined in Exception cla

Re: [PHP-DEV] Add get_object_constants and get_class_constants

Am 27.02.2013 16:58, schrieb Mike Willbanks: I am simply suggesting an alternative to using Reflection whereas: get_class_constants([object|string]); get_object_constants([object]); Do we need both; probably not; the first would likely do. +1 for the first one only Am 27.02.2013 16:12, Anal

Re: [PHP-DEV] Add get_object_constants and get_class_constants

Am 27.02.2013 18:16, schrieb Mike Willbanks: how many times this is done a quick search on GitHub for: - "ReflectionClass" (PHP/Code): 240,922 - "getConstants" (PHP/Code): 22,208 This search is not accurate nor representative but there are some more usecases in this results. cryptocompress

Re: [PHP-DEV] Add get_object_constants and get_class_constants

"Get rid of ~10% of all reflection usecases with only one function." This is really an exorbitant shiny argument on its own. Simple too good to be true. What am i missing? :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add get_object_constants and get_class_constants

sorry, i pollute this thread with discussion about reflection... Am 27.02.2013 19:19, schrieb Nikita Popov: > Why the heck do we want to get rid of Reflection? > Do we want to alias *all* Reflection methods in this way? definitely not, but: I can access all properties of an object without reflec

Re: [PHP-DEV] Add get_object_constants and get_class_constants

In fact calls to this function are perfectly cacheable by op-caches and can be optimized near zero. This would be a *great performance gain* for this 10% Reflection usecases. cryptocompress -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.