Re: [PHP-DEV] RFC: Expectations

[Crypto Compress]

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

[Crypto Compress]

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

[Crypto Compress]

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 executed until an external mechanism decides
to do so. So, this is PHP code and it is compiled and stored in
memory besides the function opcodes, but not evaluated.


Right. It's even not compiled into bytecode, just parsed into AST and 
then associated with function/class/property like doc-comment.


You're right, it contains code. The key point is that this code
will never be executed nor used in any way until an external
mechanism decides to retrieve and evaluate it. That's metadata.


Right again.


Hi,

thank you for the answers. I understand the "anything is possible" 
argument and would like to see/push future ideas in direction of 
domain-specific languages (DSL) opposite to another aspect-oriented 
programming (AOP) extension as in current examples. Sorry for offtopic.


Thanks

cryptocompress

Re: [PHP-DEV] [VOTE] Expectations

[Crypto Compress]

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 for new developers. The alternatives are not
nice, in my opinion. It's not about runtime, and the ability to catch
specific exceptions by name, at all,



there shouldn't be any catch blocks for AssertionExceptions in deployed code


Hello Joe,

can you please explain a bit more how you would achieve this in 3m loc?

Thanks!

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Expectations

[Crypto Compress]

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

[Crypto Compress]

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 intended to be caught, they don't need to be 
thrown (even if the context is different).
If exceptions are not thrown and not caught, we can use "error" in dev 
and some easing severity (warning, zero cost nothing) in prod.


Freely adapted from Murphy: If assertion exception can be catched, it 
will be even in production.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Expectations

[Crypto Compress]

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, 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 intended to be caught, they don't need to be
thrown (even if the context is different).
If exceptions are not thrown and not caught, we can use "error" in
dev and some easing severity (warning, zero cost nothing) in prod.

Freely adapted from Murphy: If assertion exception can be catched,
it will be even in production.


The point behind AssertionException is that
a) It will leave the scope where with the failed assertion 
immediately. A warning would continue running the code, even though 
some precondition is violated, which doesn't make sense.


Assumed context is wrong here.
- exception in development: error
- no exception in production: warning, zero cost nothing

Rephrased: A zero-cost non-existing exception would continue running the 
code, ...


In a previous email you brought up the point if or not derive 
AssertionEx from Exception. I argue that all child exception MUST BE 
derived from Exception. Any exception to this is not an Exception. (my 
english is too limited to explain this, sorry)



b) It can still be gracefully handled (unlike a fatal error). E.g. the 
unit testing framework can catch it, so you can continue running all 
your tests even if one causes an assertion failure.


Unit test frameworks do this already. No change here.


When Joe says "not intended to be caught" this is referring to 
"normal" code. Catching them at the top-level still makes sense, e.g. 
for the unit testing case mentioned or even just to print a nice error 
message with extra information. Using an exception instead of a fatal 
error also means that things like "finally" will still run, so your 
code can still release locks etc even if an assertion failure occurred.


In production this will never happen. We go round in circles here. I am 
aware of you preference on "exceptions everywhere".





Nikita

Re: [PHP-DEV] [VOTE] Expectations

[Crypto Compress]

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 wrong.


my 2 cents



...exceptions are not used by default...


Can't find this point in RFC.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Expectations

[Crypto Compress]

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, 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 intended to be caught, they don't need to be
thrown (even if the context is different).
If exceptions are not thrown and not caught, we can use "error" in
dev and some easing severity (warning, zero cost nothing) in prod.

Freely adapted from Murphy: If assertion exception can be catched,
it will be even in production.


Assertion is only for development and testing.
We need errors or exceptions during development and testing, but
not in production. Therefore, errors/exception should not be catched
by code in general. Isn't assertion nature?

I don't insist not to enable assertion in production environment.
There might be software that needs extreme reliability and stability.
For these softwares, it makes sense to enable assertions and catch
errors/exceptions to do some cleanups.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net <mailto:yohg...@ohgaki.net>


Hi Yasuo,

sorry for the late answer. My point is about throwing exceptions 
(assert.exceptions=1). I think it is wrong to allow to change code-flow 
by ini-setting and in current context it is wrong to throw exceptions 
altogether. Let's assume this code example in dev-mode with exceptions:


class BankAccount {
function Add($amount) {
assert($amount > 0);
// ... code block ...
}
}

Now the programmer implementing "code block" to gracefully handle 
$amount > 0 has a problem. There is no way to (Unit)test failing path on 
development machine. Code after assertion is never called for failing 
contitions. What to do? Delete assertion is out of question. Disable 
zend.assertions on development machine seems to be the wrong way too. 
The only way to handle this is to disable exceptions 
(assert.exceptions=0) so expected code flow is restored. This, if 
allowed to be changed, should be at least the default.


IMO ability to run and test code broadly outweighs "provides stacktrace 
by default" argument and for some reason i fear assert.exceptions=1 will 
be the only case soon.


cryptocompress

Re: [PHP-DEV] [VOTE] Expectations

[Crypto Compress]

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 ...
> }
> }
>
> Now the programmer implementing "code block" to gracefully handle 
$amount > 0 has a problem. There is no way to (Unit)test failing path 
on development machine. Code after assertion is never called for 
failing contitions. What to do?


Put the assert AFTER handling the always-to-be-done validation, of 
course. Doesn't make sense otherwise.


Patrick




if ($amount > 0) { ...code block... }
// else {
throw new WrongAmountEx();
// }

Frankly i can't see any point in using assertion after checked 
expression thus duplicate the expression. It's simple a bug. As 
situation is clearly wrong, throw/exit/die and change code flow as 
desired. This is not the "conditionally unreachable code" case i argue 
about.

Re: [PHP-DEV] static constructor

[Crypto Compress]

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, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] static constructor

[Crypto Compress]

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 (Exception ex) {}
}

Would this code be valid?

Have to think about this issue, but on the first look I would say yes!

Because the meaning of the static constructor is to do some necassary
initialize for the class it should be able to throw an Exception if it
cannot do it's work correctly. For example if it needs to read some
configuration from a Database and is not able to connect.

For the caller I although would say, that the error inside the static
constructor should be catchable, for the simple fact that every Error
should be catchable for user-errorhandling.

What is your point of view for this? I'm open for discussion about this.

Regards


If it's valid code then caching thrown exception and rethrow as 
wrapped-inner-exception on each subsequent access on Foo, seems 
feasible. I like the idea but cannot wrap my head around this.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] static constructor

[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 the disadvantages of global state away. 
(Discussions on variable scope are painful too.)


And two questions:
1. By definition cctor is guaranteed to be executed only once. Right?
2. In your examples you employ some external resources in cctor (e.g. 
logger, db, ini-files). Do you intend to propose a cdtor to release this 
resources?


Thank you!

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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 about two separate methods all_empty() and non[e]_empty()?

Thank you!

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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. Are you against my naming suggestions or the 
possibility to check many vars on emptiness?
There are these two groups with contrary expectations. What is the 
downside to give both a proper solution?


Thanks!

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] static constructor

[Crypto Compress]

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 the disadvantages of global state away.
(Discussions on variable scope are painful too.)

And two questions:
1. By definition cctor is guaranteed to be executed only once. Right?

Yes as the __static should be as well. See discussion with Rowan and
Patrick for details.

As I already told, I still have to clearify howto react if an exception
occurs inside the static class constructor. I prefer at the moment the
variant that a second try will raise a fatal error. But I will think
about this before I'll prepare the RFC.


2. In your examples you employ some external resources in cctor (e.g.
logger, db, ini-files). Do you intend to propose a cdtor to release this
resources?

For my understanding the lifecycle of a class is from the loading of the
class definition to the end of the application or until some explicit
class unload (don't know whether php has such feature).


PHP has no explicit class domain unload feature and you do not plan to 
implement this. Okay.




If loading a
instance to a static member you must be aware that this instance will
live till the end of lifetime of the class (that is the basic of
static). But at the end I hope PHP is unsetting all static members as
well, which should trigger the destructor of this instance as well.

If PHP is not reacting like this (but I'm sure it is because without all
suggested singletons here would be a huge memory and connection leak as
well), I know what my second rfc would be :D

Second point if you open a resource to read some data inside a method
and do not assure that it is closed again either explicit inside the
method or on a global pattern (for example my DBAdapter I use to read,
holds a single connection to database which is closed at the very end of
run), this would be poor code inside the static constructor as well as
it would be inside every other method.


This "poor code inside the static constructor" seems to be a crucial 
point of your RFC.





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.




Regards,


Thank you!


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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 contrary expectations. What is the
downside to give both a proper solution?
The "proper solution" you suggest adds two more functions and I think 
we plenty already.


For current problem area there are exactly zero functions.


We can't make empty variadic because it's ambiguous? Fine, I think I 
can live with it.


Somewhat masochistic approach considering we can unambiguous get rid of 
code bloat.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] static constructor

[Crypto Compress]

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 to
know by itself that sounds horrific indeed.

If one instance has destruction dependcies to other instances, you
should have used any kind of linking pattern between this instances so
the __destruct of the first instance destructed can handle the
destruction dependcies. At the moment I cannot think about any use case,
where this should be done another way. Maybe you have a concret example
for me, so I can think about this?


a) Implicit order of dependencies:
Logger should be the last destructed
DatabaseLogger before FileLogger before error_log-Logger...

b) How to destruct:
Write "Bye!" before closing socket.



On destruction/unload of a class the language should be able to unset
static properties in random order for this reason, without any need of a
class destructor?!


Reverse creation order.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] static constructor

[Crypto Compress]

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 a cdtor.
- second point is about implicit order: Shutdown process will free in 
reversed creation order. Classes don't have guaranteed creation order.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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 or any of these characters: space, tab, period (concat), comma, 
semicolon, closing parentheses, closing square bracket (arrays) and null 
byte (end of file)."


Is "Loosened restrictions" listing equal !(alphanumeric characters and 
underscores) as described in manual for "label"?


cryptocompress

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

* 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
- PSR-7 can be complementary to pecl_http not the other way around (c 
code can't use php code?)

- native implementations should be faster

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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 measured in nanoseconds, ie, small enough that we're not
worried about it.  (Hats off to the PHP Internals folks for making that
fast!)

It is great that this is fast, but I wonder (maybe off-topic?) why do
it? I.e. it is clear that in something like:

$a = new Request->withHeaders(...)->withBody(...)
->withEncoding(...)->withETag(...)

the intermediate objects are useless and nobody needs 5 new objects when
you do it. Am I missing something here?


Hi,

my assumptions after some testing:
- This is only true in case of reassigning ($a = clone $a) the old 
variable, as refcount for underlying values remains 1 for all values in 
clones, so cow don't need to copy anything.
- If the old object is not thrown away, then memory consumption is 
doubled and the "fast" argument is wrong.
(Performance, of cloning an object without copying values and of some 
method calls, is negligible.)


Omit mutator methods (with*/set*) is a simple and logical way to achieve 
immutability in PHP. No need for const/final/...


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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

[Crypto Compress]

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 their own.

a) With magic methods we can make the accessed property inaccessible (as
properties may appear/disappear at runtime) and so we need some magic there
(__isset/__unset as of 5.1).
A property (accessors) is defined at design-time and may not become
inaccessible so the default implementation for isset/unset should be 
sufficient.


b) Result of (unset)$this->foo is always NULL.
If we provide a way to alter this "set(NULL)" behavior:
- it may fail before calling set(NULL)
- unset($this->foo); $this->foo !== (unset)$this->foo; // foo is not foo?

c) Logically isset/unset methods wrap up getter/setter at a higher level.
Maybe both methods are better suited for "operator 
overloading/overriding RFC"

where i would again expect some magic too.

I wonder what the functionality would be as someone have to override
isset/unset accessors. Do you have some examples?

cryptocompress

http://3v4l.org/NJWsW


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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("foo", null);
var_dump($c->a === "foo");

// test only b
$c = new C(null, "foo");
var_dump($c->b === "foo");
?>

http://3v4l.org/4oi9k

cryptocompress


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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). "public $foo;" will continue to 
behave

> exactly the same way it did before :)
> Nikita

Nonetheless there is the same complication. I like to test 
"half-instantiated"

objects (maybe this is common/best practice?):

a = $a;
$this->b = $b;
}
}

// test only a
$c = new C("foo", null); // fail
var_dump($c->a === "foo");

// test only b
$c = new C(null, "foo"); // fail
var_dump($c->b === "foo");
?>

So if i want typehinting, i have to add "= null" without any real benefit as
for testing. Current behavior doesn't restrict NULL values. Why change this?
"method-like optional values"?


--
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

[Crypto Compress]

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.


cryptocompress

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

> 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 current incarnation because it now mimics exactly what 
everyone is use to with __get(), etc.


i think you refer to RFC 0.3 (could not find C# in 1.1):
https://wiki.php.net/rfc/propertygetsetsyntax#properties_in_c

cryptocompress

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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->someUninitializedValue)
or
unset($this->memoryConsuming); // with no effect

What is the benefit of this?



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 NULL is automatically allowed.

cryptocompress


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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

[Crypto Compress]

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 = 0; /* Prevent recursion */

this code would only prevent nested/parallel access to same accessor but 
not circular?

e.g.: getter -> setter -> null-checker -> null-setter -> getter
sorry it this is a dumb question :)

cryptocompress

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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, member);

guard->in_unset = 0; /* Prevent recursion */


a) That applies to __unset (magic method) only
b) guard is name specific (another name would have a different guard)
c) Those three lines are not new code, they have just been moved 
around a bit.


The code (for unset accessors) you are looking for is here:
https://github.com/cpriest/php-src/blob/accessors-5.5/Zend/zend_object_handlers.c#L986 



this code would only prevent nested/parallel access to same accessor 
but not circular?

e.g.: getter -> setter -> null-checker -> null-setter -> getter
sorry it this is a dumb question :)

cryptocompress






--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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 NULL is automatically allowed.

For properties, yes, but the idea it stems from is type-hints. Given
the following type-hint, passing a null is not allowed:

 class Foo {
   function bar(Bar $bar) {}
 }

Whereas in the following NULL is allowed:

 class Foo {
   function bar(Bar $bar = NULL) {}
 }

This is what I mean by the PHP convention for allowing NULL.


Hello Levi,

you absolutly right. I was confused by the syntax. This properties are 
normal

methods and should behave the same. Mixing "initialize-with-NULL" and
"optional/nullable" is somewhat messy though.

cryptocompress


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Crypto Compress]

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

[Crypto Compress]

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 class, the underlying api may have changed

...


array  *get_defined_constants* ([ bool |$categorize|= false ] )
As there is no equivalent function for classes, i like it simply for the 
sake of completeness too :)


To get rid of performance penalty, i mostly hardcode static arrays with 
all the constants (high maintenance costs!).


cryptocompress

Re: [PHP-DEV] Add get_object_constants and get_class_constants

[Crypto Compress]

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, Analyst (Frank Schenk) trolled:

bitmask class to shuffle around with class constants


shuffle bits around with clearly named constants:
http://php.net/manual/en/language.operators.bitwise.php
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Acl/Permission/MaskBuilder.php

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

[Crypto Compress]

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

https://github.com/search?l=php&q=ReflectionClass&ref=searchresults&type=Code
https://github.com/search?l=php&q=getConstants&ref=searchresults&type=Code

--
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

[Crypto Compress]

"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

[Crypto Compress]

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 reflection e.g. with 
foreach.
Why i need reflection (ability to examine at runtime!) to do same for 
constants (they will not change at runtime)?


cryptocompress

http://3v4l.org/94bru

--
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

[Crypto Compress]

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.php