Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

[Ralf Lang]

Am 11.01.2013 05:55, schrieb dukeofgaming:
> I have a question, maybe it is dumb: why not those opposed to using
> annotations just... refrain from using them?
> 

Although I am not the least against annotations, there are valid and
good technical reasons why one does not want to have a feature in the
language.

As Rasmus said, the code for annotations also needs to interface with
opcode caches and other core and close-to-core technologies. This will
require additional development and maint. time/manpower. This is a
finite resource, there is a tradeoff between expensive new language
features like annotations and other stuff which needs to be done. You
can probably not have both at the same time.

> Finally, I remember the lack of support for development has been a
> problem... so why not call out for support to the community?, from GSoC to
> PHP gurus litterate on Comp Sci and software engineering and architecture?

I think this has been done before and most who stay and contribute over
time have come here by their own means.

-- 
Ralf Lang
Linux Consultant / Developer

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

Re: [PHP-DEV] A remark about PHP's Vision and new things.

[Lars Strojny]

Hi Stas,

I think you hit a nail here. 

Am 10.01.2013 um 21:36 schrieb Stas Malyshev :

> Another thing is that we're not having some features that are used
> extensively in C# annotations, main being named parameters support.

To make sure we are not providing a somewhat cumbersome implementation, let’s 
start tackling named parameters first. It’s another long standing feature. We 
will most likely need named parameters for convenient annotations anyway. We 
have an (really old) RFC for that: https://wiki.php.net/rfc/namedparameters.

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

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue

[Stas Malyshev]

Hi!

> Re the ReflectionProperty::getParentProperty($this, 'foo') suggestion,
> is this supposed to already get the value of the property (and there
> would be an additional method ReflectionProperty::setParentProperty)?

I meant getting the ReflectionProperty class, but getting the actual
value is an option too. Of course, then it should be method on
ReflectionPropertyAccessor, since regular properties don't have this
thing. I'm not sure which is better - it depends on how much this would
be used. We could even not do anything special at all - as I said,
current reflection already has API to allow doing exactly this (well,
after property support is added), even if a bit long-winded.

> The current property can be obtained through
> EG(current_execute_data)->function_state.function. This holds the
> accessor function and the property can be taken from its name. Though
> this is obviously all a bit dirty and is probably not a good idea.
> Probably better to let people explicitly pass the property name.

I agree. That's why I also mentioned having __PROPERTY__ - this makes
copypasting methods a bit easier since you have less chances of making
typo in property names :)
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

[Stas Malyshev]

Hi!

> I have a question, maybe it is dumb: why not those opposed to using
> annotations just... refrain from using them?

We've been there before. You seem to be thinking as a person who only
writes software for himself and has to deal with software only written
by you. However, not everybody has such luxury. Once you start dealing
with bigger projects, language environment and language ecosystem starts
to matter, complexity of the code and complexity of what is being done
with the code starts to matter. If some code is too complex to be
properly understood, it will contain hard to find bugs, it will be
misused, it will be routed around in weird ways due to the fact people
don't understand how it works, and in general it will be a pain to all
around. Basically, it will be a piece of closed source in an open-source
project. And people will hate us for imposing this onto them.
So while "don't use it" may work with isolated features (nobody objects
to mongodb extension because they don't use mongodb), for language
features it does not work. Once it is in, you're stuck with it as a part
of your ecosystem. And since PHP has deep BC traditions, you are stuck
with it next to forever.

> Also, to maybe put things in better perspective and discourage visceral
> vote (because the topic will keep arising until the end of times, I'd bank
> on that) why not make a list of pros and cons to adding this to the
> language?

Did you read the past discussions about the topic? There was a lot of
argument outlined about pros and cons.

> Finally, I remember the lack of support for development has been a
> problem... so why not call out for support to the community?, from GSoC to
> PHP gurus litterate on Comp Sci and software engineering and architecture?

Please note that whoever you call out for will have to support this for
years to come. You probably can write an extension and then just drop it
out there and move on and let others deal with support. Even then
doesn't work that well but at least with extension the problem won't be
acute and will be localized. But with language core part you need
commitment for at least several years, otherwise it would just be piece
of buggy and clunky code that nobody can touch.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] A remark about PHP's Vision and new things.

[Stas Malyshev]

Hi!

> parameters is a great example. I'd also name another one,
> ReflectionNamespace; namespaces are converted to strings and attached to
> their classes during compile time and you can never reflect over them to
> grab for example their names.

I still can't understand why you need ReflectionNamespace. Namespaces
are just strings. If you have class name \Foo\bar\Baz, \Foo is
namespace, \Foo\bar is namespace, and both can be created by splitting
class name. For me, it's like asking for runtime support for #define in
C - I don't even understand how such thing can be working. Can you
explain what you mean here?

> I even mentioned to Andi back in 2010 that ZE gets re-written every 5
> years. That happened in 2000, 2005 and we're now hitting walls because
> of "monster" changes required to implement feature A or B. Maybe it's
> time to consider a rewrite again?

Rewrite of what? With what purpose? And who will be doing it?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] A remark about PHP's Vision and new things.

[Pierre Joye]

No. C++ is horrible. Very good read:
http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html
On Jan 11, 2013 5:06 AM, "Clint Priest"  wrote:

>  Oooh, a rewrite?  Can we write it in an object oriented language this
> time?  Please?   Pretty Please???
>
> :D
>
>  On 1/10/2013 9:49 PM, guilhermebla...@gmail.com wrote:
>
> Stas,
>
> I totally agree and Pierrick and I faced all these problems during the
> creation of patch.
> If PHP doesn't all have support required for a given feature, let's just
> not only discuss feature, but also the required support too. Named
> parameters is a great example. I'd also name another one,
> ReflectionNamespace; namespaces are converted to strings and attached to
> their classes during compile time and you can never reflect over them to
> grab for example their names.
> I even mentioned to Andi back in 2010 that ZE gets re-written every 5
> years. That happened in 2000, 2005 and we're now hitting walls because of
> "monster" changes required to implement feature A or B. Maybe it's time to
> consider a rewrite again?
>
> Cheers,
>
>
> On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev  
> wrote:
>
>
>  Hi!
>
>
>  I strongly suggest to anyone following the (too many) threads about
> annotations to try the C# annotation and see what it allows. It goes
>
>
> As far as I can see, C# annotations rely on two very important things:
> 1. Compiler support. Compiler really knows a lot about what annotations do.
> 2. Extensive library support. Annotations themselves are just passive
> metadata, what makes them work is .net framework that uses them.
>
> This means to make annotations as useful in PHP we would have to have
> substantial support in the engine (including bytecode caching
> provisions, etc.) and some libraries that require very
> latest-and-greatest version of PHP.
>
> Another thing is that we're not having some features that are used
> extensively in C# annotations, main being named parameters support.
>
> I am saying this not to oppose the idea of annotations or the idea of
> looking into C# and other languages (actually, I think anybody who talks
> about it should look at least into what C# and Java do with it - and
> also what Python does, which is completely different direction, just to
> know other options). I'm just saying porting this to PHP may be less
> than straightforward.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> --
> -Clint
>

Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

[dukeofgaming]

I have a question, maybe it is dumb: why not those opposed to using
annotations just... refrain from using them?

Annotations are currently used by the industry through workarounds to the
PHP language, so any argument on it's usefulness is completely moot. Adding
native support for this (no one says it is easy) is important for the
advancement of the language, you already have your proof of concept out
there, so there is really no discussing on whether they are a useful
feature or not.

Also, to maybe put things in better perspective and discourage visceral
vote (because the topic will keep arising until the end of times, I'd bank
on that) why not make a list of pros and cons to adding this to the
language?

Finally, I remember the lack of support for development has been a
problem... so why not call out for support to the community?, from GSoC to
PHP gurus litterate on Comp Sci and software engineering and architecture?

Regards,

David


On Thu, Jan 10, 2013 at 5:18 PM, Yahav Gindi Bar wrote:

> Agree, I thought about Those who don't want to annotations  at all. So we
> can add 2 extra options for those who don't want annotations at all and
> those who wish better proposal :)
>  PS : I'm with those who do wish annotations.
>
> ב-11 בינו 2013, בשעה 01:07, Ralf Lang  כתב/ה:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> >
> >>
> >> Just a thought - if the main argument is about syntax - we can
> >> propose few versions (Without implementing them) and then vote for
> >> 1) No annotations (attributes) at all. 2) Syntax #1 3) Syntax #2
> >> and so on.
> >>
> >> What do you think?
> >
> > If we come up with two bad ideas, it's not a reason to shred
> > annotations altogether. ;)
> >
> > Alternative wording:
> >
> > 1) Syntax #1
> > 2) Syntax #2
> > ...
> > n) Syntax #n
> > n+1) None of these - do nothing until we get better proposals.
> >
> > - --
> > Ralf Lang
> > Linux Consultant / Developer
> > Tel.: +49-170-6381563
> > Mail: l...@b1-systems.de
> > B1 Systems GmbH
> > Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
> > GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2.0.19 (GNU/Linux)
> > Comment: Using GnuPG with undefined - http://www.enigmail.net/
> >
> > iEYEARECAAYFAlDvSa8ACgkQCs1dsHJ/X7Ct/ACgx2PD/Pk4DDnFGC8QSq75K2J/
> > 8i8An0IXRxebk3663Y1rZaoZN+Fr5m6b
> > =k2Bt
> > -END PGP SIGNATURE-
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>

Re: [PHP-DEV] A remark about PHP's Vision and new things.

[dukeofgaming]

Hi,

I suggest you start defining action items in the RFC. After reading what
Stas and others say, this looks like too big a task to discuss in itself,
so it should be definitely be broken down.

You will probably find that as it is broken down, actual development
support will surface by itself.

Regards,

David


On Thu, Jan 10, 2013 at 9:49 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Stas,
>
> I totally agree and Pierrick and I faced all these problems during the
> creation of patch.
> If PHP doesn't all have support required for a given feature, let's just
> not only discuss feature, but also the required support too. Named
> parameters is a great example. I'd also name another one,
> ReflectionNamespace; namespaces are converted to strings and attached to
> their classes during compile time and you can never reflect over them to
> grab for example their names.
> I even mentioned to Andi back in 2010 that ZE gets re-written every 5
> years. That happened in 2000, 2005 and we're now hitting walls because of
> "monster" changes required to implement feature A or B. Maybe it's time to
> consider a rewrite again?
>
> Cheers,
>
>
> On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev  >wrote:
>
> > Hi!
> >
> > > I strongly suggest to anyone following the (too many) threads about
> > > annotations to try the C# annotation and see what it allows. It goes
> >
> > As far as I can see, C# annotations rely on two very important things:
> > 1. Compiler support. Compiler really knows a lot about what annotations
> do.
> > 2. Extensive library support. Annotations themselves are just passive
> > metadata, what makes them work is .net framework that uses them.
> >
> > This means to make annotations as useful in PHP we would have to have
> > substantial support in the engine (including bytecode caching
> > provisions, etc.) and some libraries that require very
> > latest-and-greatest version of PHP.
> >
> > Another thing is that we're not having some features that are used
> > extensively in C# annotations, main being named parameters support.
> >
> > I am saying this not to oppose the idea of annotations or the idea of
> > looking into C# and other languages (actually, I think anybody who talks
> > about it should look at least into what C# and Java do with it - and
> > also what Python does, which is completely different direction, just to
> > know other options). I'm just saying porting this to PHP may be less
> > than straightforward.
> >
> > --
> > Stanislav Malyshev, Software Architect
> > SugarCRM: http://www.sugarcrm.com/
> > (408)454-6900 ext. 227
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
> --
> Guilherme Blanco
> MSN: guilhermebla...@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>

Re: [PHP-DEV] A remark about PHP's Vision and new things.

[Clint Priest]

Oooh, a rewrite?  Can we write it in an object oriented language this 
time?  Please?   Pretty Please???


:D

On 1/10/2013 9:49 PM, guilhermebla...@gmail.com wrote:

Stas,

I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support required for a given feature, let's just
not only discuss feature, but also the required support too. Named
parameters is a great example. I'd also name another one,
ReflectionNamespace; namespaces are converted to strings and attached to
their classes during compile time and you can never reflect over them to
grab for example their names.
I even mentioned to Andi back in 2010 that ZE gets re-written every 5
years. That happened in 2000, 2005 and we're now hitting walls because of
"monster" changes required to implement feature A or B. Maybe it's time to
consider a rewrite again?

Cheers,


On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev wrote:


Hi!


I strongly suggest to anyone following the (too many) threads about
annotations to try the C# annotation and see what it allows. It goes

As far as I can see, C# annotations rely on two very important things:
1. Compiler support. Compiler really knows a lot about what annotations do.
2. Extensive library support. Annotations themselves are just passive
metadata, what makes them work is .net framework that uses them.

This means to make annotations as useful in PHP we would have to have
substantial support in the engine (including bytecode caching
provisions, etc.) and some libraries that require very
latest-and-greatest version of PHP.

Another thing is that we're not having some features that are used
extensively in C# annotations, main being named parameters support.

I am saying this not to oppose the idea of annotations or the idea of
looking into C# and other languages (actually, I think anybody who talks
about it should look at least into what C# and Java do with it - and
also what Python does, which is completely different direction, just to
know other options). I'm just saying porting this to PHP may be less
than straightforward.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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






--
-Clint

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue

[Clint Priest]

On 1/10/2013 6:57 PM, Nikita Popov wrote:

Even more generic, we just could use existing ReflectionProperty like

this (this is standard API, no changes needed):

(new ReflectionProperty(get_parent_class(),
'foo'))->setValue($this, $val);

Yes, this is even more long-winded, that's why maybe we should have
shortcut function for it. Depends on how frequently in practice we
expect to do it.


I like this idea as a solution to the problem.  It would be ideal if 
parent::$foo would work but since that is not currently a reasonable 
option, either leaving the user land programmer to use reflection to do 
it or to provide them with a shortcut way to do it is a good interim 
solution to the problem.


I'm not sure that we really even need a 'shortcut' to do it, we'd need 
some other people to chime in on that and how often the parent accessor 
would want to be called.



> I know that this is not an optimal solution, but I would much prefer
> this over some new syntax like "parent->foo". Once (if) static

I like this approach more too.


+1 as well



> properties have better engine support we can switch to the cleaner
> parent::$foo way. But until then I think that this is a good
compromise,

I'm afraid we couldn't though since parent::$foo already means
something
else - it's a static property "$foo" of the class that is parent of
current class. We could redefine it in this specific context, in
theory,
but that would be strange special case and I don't think it would be
good idea to do that. Our syntax kind of assumes the object has
only one
class and all properties belong to this class, so we don't have a
proper
syntax to express the idea of "same property, but with different
scope".


I try to see :: as a scope resolution operator rather than a static 
access operator. For methods that's how it works (you can call 
instance methods with it in a different scope, e.g. parent scope). So 
doing the same for properties isn't far off. But yes, I do agree that 
this would be rather tricky and could open another big can of worms 
(like we have with method calls from incompatible contexts), so it 
might not actually make sense to go down that path.
I agree with that general sentiment as :: as a scope resolution 
operator, it's just that right now, for ::$ that always translates to 
static property access which is the current conundrum.



> This is just a rough idea of what I'd do. The exact way this
would work
> still needs further discussion. E.g. one could make passing the
property
> name optional and assume the current property as default. Or one
could

If you assume current property you'd have to store it somewhere to
pass
it and have API for that function to extract it, which sounds like
very
tight coupling for this function. Maybe something like __PROPERTY__
would be better?


The current property can be obtained through 
EG(current_execute_data)->function_state.function. This holds the 
accessor function and the property can be taken from its name. Though 
this is obviously all a bit dirty and is probably not a good idea. 
Probably better to let people explicitly pass the property name.


Nikita


Is everyone okay with a long winded way to get/set the parent accessor 
if necessary?


(new ReflectionProperty(get_parent_class(), 'foo'))->setValue($this, $val);

Alternatively, reflection in some cases takes an object instance 
(ReflectionObject), we could extend ReflectionPropertyAccessor so that 
it could take an object, then something that is slightly shortened would 
work, like this:


(new ReflectionPropertyAccessor($this, 'foo'))->setValue(45);

That presently doesn't work, but could be made to work, especially 
considering it's a new sub-class anyways.


If we don't like setValue() being different b/w ReflectionProperty and 
ReflectionPropertyAccessor we could upgrade both classes to accept an 
object instance as its constructor argument...


--
-Clint

Re: [PHP-DEV] A remark about PHP's Vision and new things.

[guilhermebla...@gmail.com]

Stas,

I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support required for a given feature, let's just
not only discuss feature, but also the required support too. Named
parameters is a great example. I'd also name another one,
ReflectionNamespace; namespaces are converted to strings and attached to
their classes during compile time and you can never reflect over them to
grab for example their names.
I even mentioned to Andi back in 2010 that ZE gets re-written every 5
years. That happened in 2000, 2005 and we're now hitting walls because of
"monster" changes required to implement feature A or B. Maybe it's time to
consider a rewrite again?

Cheers,


On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev wrote:

> Hi!
>
> > I strongly suggest to anyone following the (too many) threads about
> > annotations to try the C# annotation and see what it allows. It goes
>
> As far as I can see, C# annotations rely on two very important things:
> 1. Compiler support. Compiler really knows a lot about what annotations do.
> 2. Extensive library support. Annotations themselves are just passive
> metadata, what makes them work is .net framework that uses them.
>
> This means to make annotations as useful in PHP we would have to have
> substantial support in the engine (including bytecode caching
> provisions, etc.) and some libraries that require very
> latest-and-greatest version of PHP.
>
> Another thing is that we're not having some features that are used
> extensively in C# annotations, main being named parameters support.
>
> I am saying this not to oppose the idea of annotations or the idea of
> looking into C# and other languages (actually, I think anybody who talks
> about it should look at least into what C# and Java do with it - and
> also what Python does, which is completely different direction, just to
> know other options). I'm just saying porting this to PHP may be less
> than straightforward.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

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

[guilhermebla...@gmail.com]

We all agree that nullable properties need to be addressed.
Now why just don't discuss a possible syntax and move on?
Initializers, parenthesis around unsetters, etc can all be detailed and
discussed later.

Here are the proposed syntaxes:

public DateTime? $date {
  get { ... }
  set { ... }
}

public DateTime $date = null {
  get { ... }
  set { ... }
}

public DateTime $date {
  get { ... }
  set($value = null) { ... }
}

public $date {
  get { ... }
  set(DateTime $value = null) { ... }
}


Now choose your options from 1-4 and move on...
Sometimes you truly love to discuss instead of act. Tsc, tsc, tsc...


Cheers,


On Thu, Jan 10, 2013 at 7:24 PM, Lazare Inepologlou wrote:

> Nikita,
>
>
> 2013/1/10 Nikita Popov 
>
> > On Tue, Jan 8, 2013 at 7:03 PM, Steve Clay  wrote:
> >
> > > On 1/8/13 2:56 AM, Christian Stoller wrote:
> > >
> > >> But the way 'nullable' properties are defined is not very intuitive
> and
> > >> unclean, in my opinion. Stas has already mentioned that.
> > >> `public DateTime $date = NULL;` // this looks like the property is
> > >> initialized with null, but it does not show that the property is
> > 'nullable'
> > >>
> > >
> > > Much agreed. After instantiation, these shouldn't behave differently:
> > >
> > > public $foo = null;
> > > public Foo $foo = null;
> > >
> > > Sure, method signatures have special behavior based on a default value,
> > > but IMO:
> > > 1. those semantics aren't entirely intuitive to begin with
> > > 2. property initializers aren't method sigs
> > > 3. the semantics would apply only to some properties
> > >
> > >
> > >
> > >   public DateTime? $date;
> > >>
> > >> In C# the question mark after a type is a short hand for a generic
> > >> Nullable type.
> > >>
> > >
> > > I like that it's an established practice of doing exactly what we're
> > > trying to do.
> > >
> > > Could we not just make it obvious?:
> > >
> > > public Foo|null $foo;
> > >
> >
> > I updated the RFC to include the current state regarding default value
> and
> > nullability:
> >
> >
> https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax
> >
> > One question that still needs to be discussed is what syntax regarding
> > parentheses we want to use if this makes it. Currently both set { } and
> > set($foo) { } style accessors are supported. Do we want to keep those two
> > with the new syntax?
> >
> > Nikita
> >
> > PS: I hope I'm not interrupting all those heated annotations discussion
> too
> > much ^^
> >
>
>
>
> In the RFC, one thing is not clear: How to provide typehints for nullable
> properties that actually have accessors.
>
> Will it be like this?
>
> public DateTime $date = null {
>   get { ... }
>   set { ... }
> }
>
>
>
>
> Lazare INEPOLOGLOU
> Ingénieur Logiciel
>



-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue

[Steve Clay]

Why we must have parent property access at all? What's the use case and how do 
other langs do it?

Am I right to say there is no "parent property", this would just call the 
parent's [gs]etter using the same underlying property value?

Steve
-- 
http://www.mrclay.org/

On Jan 10, 2013, at 6:15 PM, Nikita Popov  wrote:

> On Sat, Jan 5, 2013 at 4:25 AM, Clint Priest  wrote:
> 
>> Agreed.  Some people may actually be using $parent as a variable name, not
>> difficult to imagine.
>> 
>> So far parent->foo seems to be the answer.
>> 
>> -Clint
> 
> My thoughts on the parent situations, as I'm not yet satisfied with the
> current solution.
> 
> 1) I tried to understand how the engine currently compiles and executes
> object property fetches. I found it to be incredibly complex and I
> certainly don't have the abilities to port this for statics. As such the
> "parent::$foo" syntax is dead unless someone else is going to do the
> necessary engine changes.
> 
> 2) I think the "parent->foo" syntax is nice in concept, but I think that
> it's an absolute no-go as it doesn't fit in with the rest of PHP (and would
> still require some engine changes those complexity I can't really
> estimate). The parent->foo syntax is some off mix between parent::$foo
> (which makes sense) and $parent->foo (which also makes sense). parent->foo
> combines it in an odd way that doesn't look like PHP and adds yet another
> new syntax for something that's going to be a rare case anyway.
> 
> 3) My suggestion is to avoid the engine and syntax related issues of parent
> property access by putting this as a function in the standard library
> instead. What I'm thinking about is a function like get_parent_property()
> which returns the ReflectionProperty for it. Then you could do something
> like this:
> 
> public $foo {
> get { return 'parent is: ' .
> get_parent_property('foo')->getValue(); }
> set($val) { get_parent_property('foo')->setValue($val . '
> something'); }
> }
> 
> I know that this is not an optimal solution, but I would much prefer this
> over some new syntax like "parent->foo". Once (if) static properties have
> better engine support we can switch to the cleaner parent::$foo way. But
> until then I think that this is a good compromise, especially considering
> that accessing the parent property shouldn't be a very common operation, so
> it's okay if it's a bit more verbose.
> 
> This is just a rough idea of what I'd do. The exact way this would work
> still needs further discussion. E.g. one could make passing the property
> name optional and assume the current property as default. Or one could not
> return a ReflectionProperty and instead provide two functions
> get_parent_property and set_parent_property (what about isset and unset in
> that case though?)
> 
> So, what do you think about this?
> 
> Nikita

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

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue

[Nikita Popov]

On Fri, Jan 11, 2013 at 1:03 AM, Stas Malyshev wrote:

> > 3) My suggestion is to avoid the engine and syntax related issues of
> > parent property access by putting this as a function in the standard
> > library instead. What I'm thinking about is a function like
> > get_parent_property() which returns the ReflectionProperty for it. Then
> > you could do something like this:
>
> This is an interesting approach. I like the idea of using the reflection
> instead of inventing an awkward new syntax. However, I'm not sure I can
> see how get_parent_property('foo') works - what exactly is 'foo' here?
> Does it mean this function relies on implied $this?
>

I wrote that without actually checking the Reflection API, I forget that
one has to pass the object too. So my code samples should rather look like
this:

get_parent_property('foo')->getValue($this);
get_parent_property('foo')->setValue($this, ...);

And yes, I know it's long-winded. But on the plus since it's generic,
> does not pollute global space and might also be useful in other contexts.
>

Re the ReflectionProperty::getParentProperty($this, 'foo') suggestion, is
this supposed to already get the value of the property (and there would be
an additional method ReflectionProperty::setParentProperty)?

Even more generic, we just could use existing ReflectionProperty like
> this (this is standard API, no changes needed):
>
> (new ReflectionProperty(get_parent_class(), 'foo'))->setValue($this, $val);
>
> Yes, this is even more long-winded, that's why maybe we should have
> shortcut function for it. Depends on how frequently in practice we
> expect to do it.
>

> > I know that this is not an optimal solution, but I would much prefer
> > this over some new syntax like "parent->foo". Once (if) static
>
> I like this approach more too.
>
> > properties have better engine support we can switch to the cleaner
> > parent::$foo way. But until then I think that this is a good compromise,
>
> I'm afraid we couldn't though since parent::$foo already means something
> else - it's a static property "$foo" of the class that is parent of
> current class. We could redefine it in this specific context, in theory,
> but that would be strange special case and I don't think it would be
> good idea to do that. Our syntax kind of assumes the object has only one
> class and all properties belong to this class, so we don't have a proper
> syntax to express the idea of "same property, but with different scope".
>

I try to see :: as a scope resolution operator rather than a static access
operator. For methods that's how it works (you can call instance methods
with it in a different scope, e.g. parent scope). So doing the same for
properties isn't far off. But yes, I do agree that this would be rather
tricky and could open another big can of worms (like we have with method
calls from incompatible contexts), so it might not actually make sense to
go down that path.


> > This is just a rough idea of what I'd do. The exact way this would work
> > still needs further discussion. E.g. one could make passing the property
> > name optional and assume the current property as default. Or one could
>
> If you assume current property you'd have to store it somewhere to pass
> it and have API for that function to extract it, which sounds like very
> tight coupling for this function. Maybe something like __PROPERTY__
> would be better?
>

The current property can be obtained through
EG(current_execute_data)->function_state.function. This holds the accessor
function and the property can be taken from its name. Though this is
obviously all a bit dirty and is probably not a good idea. Probably better
to let people explicitly pass the property name.

Nikita

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

[Lazare Inepologlou]

Nikita,


2013/1/10 Nikita Popov 

> On Tue, Jan 8, 2013 at 7:03 PM, Steve Clay  wrote:
>
> > On 1/8/13 2:56 AM, Christian Stoller wrote:
> >
> >> But the way 'nullable' properties are defined is not very intuitive and
> >> unclean, in my opinion. Stas has already mentioned that.
> >> `public DateTime $date = NULL;` // this looks like the property is
> >> initialized with null, but it does not show that the property is
> 'nullable'
> >>
> >
> > Much agreed. After instantiation, these shouldn't behave differently:
> >
> > public $foo = null;
> > public Foo $foo = null;
> >
> > Sure, method signatures have special behavior based on a default value,
> > but IMO:
> > 1. those semantics aren't entirely intuitive to begin with
> > 2. property initializers aren't method sigs
> > 3. the semantics would apply only to some properties
> >
> >
> >
> >   public DateTime? $date;
> >>
> >> In C# the question mark after a type is a short hand for a generic
> >> Nullable type.
> >>
> >
> > I like that it's an established practice of doing exactly what we're
> > trying to do.
> >
> > Could we not just make it obvious?:
> >
> > public Foo|null $foo;
> >
>
> I updated the RFC to include the current state regarding default value and
> nullability:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax
>
> One question that still needs to be discussed is what syntax regarding
> parentheses we want to use if this makes it. Currently both set { } and
> set($foo) { } style accessors are supported. Do we want to keep those two
> with the new syntax?
>
> Nikita
>
> PS: I hope I'm not interrupting all those heated annotations discussion too
> much ^^
>



In the RFC, one thing is not clear: How to provide typehints for nullable
properties that actually have accessors.

Will it be like this?

public DateTime $date = null {
  get { ... }
  set { ... }
}




Lazare INEPOLOGLOU
Ingénieur Logiciel

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

[Stas Malyshev]

Hi!


> that statement in the RFC is still true. On this subject, are you
> (personally) okay with the current approach for creating automatic
> accessors (i.e. create PHP code string and compile)?

It might be more efficient to generate the opcodes directly, since they
are always the same and you'd really need to only plug the string into
one place  (or in case of typehints, two places), but I don't have
preference one way or another, depending on which is easier. If we won't
have reentrancy, line numbers, etc. issues then generating a string may
be easier and also more robust if opcodes ever change.

> Just to make sure I got it all right, you are suggesting:
>  * Parentheses must be used on all accessors, so it's set($value) {} and
> get() {} and isset() {} and unset() {} and something like get {} is not
> possible?
>  * Automatic accessors don't have parentheses so they are just set; get;
> isset; unset;
> 
> Is that right? If so, then I think it's a reasonable approach.

Yes, I think this makes it look consistent - albeit at the price of some
added verbosity.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue

[Stas Malyshev]

Hi!

> 1) I tried to understand how the engine currently compiles and executes
> object property fetches. I found it to be incredibly complex and I
> certainly don't have the abilities to port this for statics. As such the
> "parent::$foo" syntax is dead unless someone else is going to do the
> necessary engine changes.

Object property fetches are not that hard, but parent::$foo is static
fetch - which is entirely different beast which uses different opcodes
and works differently. And is not supported by object handlers - mainly
because there's no object :) If we designed it from scratch, we could
probably make a class an object of type Class and probably avoided that
problem, since we could just use standard object handlers for that, but
it is not what currently happens. If somebody feels ambitious he may
explore that direction.

> 2) I think the "parent->foo" syntax is nice in concept, but I think that
> it's an absolute no-go as it doesn't fit in with the rest of PHP (and

Well, it partially does, since ->foo part works exactly like in any
other expression. But parent-> part and the whole dollar-less variable
seems foreign for me too, so I am not happy with this one either.

> would still require some engine changes those complexity I can't really
> estimate). The parent->foo syntax is some off mix between parent::$foo
> (which makes sense) and $parent->foo (which also makes sense).

$parent->foo makes tons of sense, but it means there's an object called
$parent. Now the question is where this one came from?

> 3) My suggestion is to avoid the engine and syntax related issues of
> parent property access by putting this as a function in the standard
> library instead. What I'm thinking about is a function like
> get_parent_property() which returns the ReflectionProperty for it. Then
> you could do something like this:

This is an interesting approach. I like the idea of using the reflection
instead of inventing an awkward new syntax. However, I'm not sure I can
see how get_parent_property('foo') works - what exactly is 'foo' here?
Does it mean this function relies on implied $this? I'm not sure we
should be adding functions that do this. I'd rather have something like:
ReflectionProperty::getParentProperty($this, 'foo')

And yes, I know it's long-winded. But on the plus since it's generic,
does not pollute global space and might also be useful in other contexts.

Even more generic, we just could use existing ReflectionProperty like
this (this is standard API, no changes needed):

(new ReflectionProperty(get_parent_class(), 'foo'))->setValue($this, $val);

Yes, this is even more long-winded, that's why maybe we should have
shortcut function for it. Depends on how frequently in practice we
expect to do it.

> I know that this is not an optimal solution, but I would much prefer
> this over some new syntax like "parent->foo". Once (if) static

I like this approach more too.

> properties have better engine support we can switch to the cleaner
> parent::$foo way. But until then I think that this is a good compromise,

I'm afraid we couldn't though since parent::$foo already means something
else - it's a static property "$foo" of the class that is parent of
current class. We could redefine it in this specific context, in theory,
but that would be strange special case and I don't think it would be
good idea to do that. Our syntax kind of assumes the object has only one
class and all properties belong to this class, so we don't have a proper
syntax to express the idea of "same property, but with different scope".

> This is just a rough idea of what I'd do. The exact way this would work
> still needs further discussion. E.g. one could make passing the property
> name optional and assume the current property as default. Or one could

If you assume current property you'd have to store it somewhere to pass
it and have API for that function to extract it, which sounds like very
tight coupling for this function. Maybe something like __PROPERTY__
would be better?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Add a zend_qsort_r/zend_qsort implementation

[Levi Morrison]

On Thu, Jan 10, 2013 at 2:59 PM, Stas Malyshev  wrote:
>> We could export zend_qsort_r starting in 5.5; I need it ext/standard so
>> it need not be exported, which would be problematic on a stable branch.
>> It's undefined behavior because the comparison function is being called
>> with one extra pointer argument. This is the same technique glibc uses
>> though, so it should be safe. I could not find any measurable
>> performance penalty.
>
> I think this is OK for 5.5, but I'm kind of worried about the function
> parameter mismatch. PHP is run on all kinds of platforms, including
> those where glibc is never heard of :) Are we sure it's safe on all
> platforms to do this?

I urge you to be very careful. I compile PHP on intel compilers and
have seen some performance benefit to doing so. Make sure it is
cross-platform, please.

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

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

[Nikita Popov]

On Thu, Jan 10, 2013 at 11:11 PM, Stas Malyshev wrote:

> Hi!
>
> The proposal is pretty clear, but could you explain this part:
>
> The current accessors proposal will need special handling of the
> typehint in any case (it can't be handled as a normal method typehint).
>
> What special handling is required?
>

I have written that in anticipation of a rewrite of the current automatic
accessor implementation. Currently it creates a string of PHP code and
compiles it as the method body. We were planning to replace this with
handling directly in the object handlers (because automatic accessors just
need to use the "normal" property code rather than the accessor one). In
this case we'd have to handle the typehint explicitly. But I'm not sure
whether we will still do this, so I'm not sure whether that statement in
the RFC is still true. On this subject, are you (personally) okay with the
current approach for creating automatic accessors (i.e. create PHP code
string and compile)?

> One question that still needs to be discussed is what syntax regarding
> > parentheses we want to use if this makes it. Currently both set { } and
> > set($foo) { } style accessors are supported. Do we want to keep those two
> > with the new syntax?
>
> Within this context, I'd prefer getting rid of set {} and only have
> set($param) {}. You don't save that much typing and you do it at the
> cost of additional obscurity and complexity - now every developer and
> every tool that deals with it needs to remember there's hidden $value
> parameter. IMHO not worth it. I can see what "get;" gives you - you can
> say "just do the natural thing". But if you start writing code anyway -
> i.e. if you do {} - then I think it should look like a real function.
>

Just to make sure I got it all right, you are suggesting:
 * Parentheses must be used on all accessors, so it's set($value) {} and
get() {} and isset() {} and unset() {} and something like get {} is not
possible?
 * Automatic accessors don't have parentheses so they are just set; get;
isset; unset;

Is that right? If so, then I think it's a reasonable approach.

Nikita

Re: [PHP-DEV] strtr vs. str_replace runtime

[Christopher Jones]

On 01/09/2013 02:45 PM, Gustavo Lopes wrote:

On Thu, 03 Jan 2013 11:40:31 +0100, Gustavo Lopes  
wrote:


The algorithm behaves very poorly in this case because at each position of the 
text, all the substrings starting there and with size between m and n (where m 
is the size of the smallest pattern and n is the largest) are checked, even if 
there are only
two patterns with size m and n. We could fix this easily by building a set of 
the pattern sizes found and try only with those. The hashing of the substrings 
could also be improved; we don't have to recalculate everything when we advance 
in the text.



Both optimizations (the hash rolling and limiting the substrings hashed on each 
iteration) worked quite well.

But I got much better results with another algorithm [1], so I'm going to merge 
the branch with it [2] instead. I get these results with a 1.7 MB string and 13 
replacement strings, the smallest with 6 characters and 30 iterations (x86-64, 
gcc -O3):

strtr: 0.1387
str_replace: 0.4471

The algorithm doesn't perform as well when the replacement strings are small. 
Adding a replacement for the pattern '_' (1 character) yields:

strtr: 0.6157
str_replace: 0.6230


How does this compare with your baseline results?



But even in this case, it works better than my optimized version of the current 
algorithm.

I plan on merging to 5.4 and 5.5; you may want to review it as introducing 
completely new code carries some risk.


Depending on the improvement, it might be tempting to merge to 5.4 but I would
prefer to see it in 5.5+.  Let's keep 5.4 stable.

Chris




[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.2927
[2] https://github.com/cataphract/php-src/compare/strtr_wu94



--
christopher.jo...@oracle.com  http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html

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

Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

[Yahav Gindi Bar]

Agree, I thought about Those who don't want to annotations  at all. So we can 
add 2 extra options for those who don't want annotations at all and those who 
wish better proposal :)
 PS : I'm with those who do wish annotations.

ב-11 בינו 2013, בשעה 01:07, Ralf Lang  כתב/ה:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
>> 
>> Just a thought - if the main argument is about syntax - we can
>> propose few versions (Without implementing them) and then vote for 
>> 1) No annotations (attributes) at all. 2) Syntax #1 3) Syntax #2 
>> and so on.
>> 
>> What do you think?
> 
> If we come up with two bad ideas, it's not a reason to shred
> annotations altogether. ;)
> 
> Alternative wording:
> 
> 1) Syntax #1
> 2) Syntax #2
> ...
> n) Syntax #n
> n+1) None of these - do nothing until we get better proposals.
> 
> - -- 
> Ralf Lang
> Linux Consultant / Developer
> Tel.: +49-170-6381563
> Mail: l...@b1-systems.de
> B1 Systems GmbH
> Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
> 
> iEYEARECAAYFAlDvSa8ACgkQCs1dsHJ/X7Ct/ACgx2PD/Pk4DDnFGC8QSq75K2J/
> 8i8An0IXRxebk3663Y1rZaoZN+Fr5m6b
> =k2Bt
> -END PGP SIGNATURE-
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue

[Nikita Popov]

On Sat, Jan 5, 2013 at 4:25 AM, Clint Priest  wrote:

> Agreed.  Some people may actually be using $parent as a variable name, not
> difficult to imagine.
>
> So far parent->foo seems to be the answer.
>
> -Clint
>

My thoughts on the parent situations, as I'm not yet satisfied with the
current solution.

1) I tried to understand how the engine currently compiles and executes
object property fetches. I found it to be incredibly complex and I
certainly don't have the abilities to port this for statics. As such the
"parent::$foo" syntax is dead unless someone else is going to do the
necessary engine changes.

2) I think the "parent->foo" syntax is nice in concept, but I think that
it's an absolute no-go as it doesn't fit in with the rest of PHP (and would
still require some engine changes those complexity I can't really
estimate). The parent->foo syntax is some off mix between parent::$foo
(which makes sense) and $parent->foo (which also makes sense). parent->foo
combines it in an odd way that doesn't look like PHP and adds yet another
new syntax for something that's going to be a rare case anyway.

3) My suggestion is to avoid the engine and syntax related issues of parent
property access by putting this as a function in the standard library
instead. What I'm thinking about is a function like get_parent_property()
which returns the ReflectionProperty for it. Then you could do something
like this:

 public $foo {
 get { return 'parent is: ' .
get_parent_property('foo')->getValue(); }
 set($val) { get_parent_property('foo')->setValue($val . '
something'); }
 }

I know that this is not an optimal solution, but I would much prefer this
over some new syntax like "parent->foo". Once (if) static properties have
better engine support we can switch to the cleaner parent::$foo way. But
until then I think that this is a good compromise, especially considering
that accessing the parent property shouldn't be a very common operation, so
it's okay if it's a bit more verbose.

This is just a rough idea of what I'd do. The exact way this would work
still needs further discussion. E.g. one could make passing the property
name optional and assume the current property as default. Or one could not
return a ReflectionProperty and instead provide two functions
get_parent_property and set_parent_property (what about isset and unset in
that case though?)

So, what do you think about this?

Nikita

Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

[Ralf Lang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> 

> 
> Just a thought - if the main argument is about syntax - we can
> propose few versions (Without implementing them) and then vote for 
> 1) No annotations (attributes) at all. 2) Syntax #1 3) Syntax #2 
> and so on.
> 
> What do you think?
> 

If we come up with two bad ideas, it's not a reason to shred
annotations altogether. ;)

Alternative wording:

1) Syntax #1
2) Syntax #2
...
n) Syntax #n
n+1) None of these - do nothing until we get better proposals.

- -- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: l...@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDvSa8ACgkQCs1dsHJ/X7Ct/ACgx2PD/Pk4DDnFGC8QSq75K2J/
8i8An0IXRxebk3663Y1rZaoZN+Fr5m6b
=k2Bt
-END PGP SIGNATURE-

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

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

[Stas Malyshev]

Hi!

The proposal is pretty clear, but could you explain this part:

The current accessors proposal will need special handling of the
typehint in any case (it can't be handled as a normal method typehint).

What special handling is required?

> One question that still needs to be discussed is what syntax regarding
> parentheses we want to use if this makes it. Currently both set { } and
> set($foo) { } style accessors are supported. Do we want to keep those two
> with the new syntax?

Within this context, I'd prefer getting rid of set {} and only have
set($param) {}. You don't save that much typing and you do it at the
cost of additional obscurity and complexity - now every developer and
every tool that deals with it needs to remember there's hidden $value
parameter. IMHO not worth it. I can see what "get;" gives you - you can
say "just do the natural thing". But if you start writing code anyway -
i.e. if you do {} - then I think it should look like a real function.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Add a zend_qsort_r/zend_qsort implementation

[Stas Malyshev]

Hi!

> We could export zend_qsort_r starting in 5.5; I need it ext/standard so 
> it need not be exported, which would be problematic on a stable branch. 
> It's undefined behavior because the comparison function is being called 
> with one extra pointer argument. This is the same technique glibc uses 
> though, so it should be safe. I could not find any measurable 
> performance penalty.

I think this is OK for 5.5, but I'm kind of worried about the function
parameter mismatch. PHP is run on all kinds of platforms, including
those where glibc is never heard of :) Are we sure it's safe on all
platforms to do this?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

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

[Nikita Popov]

On Tue, Jan 8, 2013 at 7:03 PM, Steve Clay  wrote:

> On 1/8/13 2:56 AM, Christian Stoller wrote:
>
>> But the way 'nullable' properties are defined is not very intuitive and
>> unclean, in my opinion. Stas has already mentioned that.
>> `public DateTime $date = NULL;` // this looks like the property is
>> initialized with null, but it does not show that the property is 'nullable'
>>
>
> Much agreed. After instantiation, these shouldn't behave differently:
>
> public $foo = null;
> public Foo $foo = null;
>
> Sure, method signatures have special behavior based on a default value,
> but IMO:
> 1. those semantics aren't entirely intuitive to begin with
> 2. property initializers aren't method sigs
> 3. the semantics would apply only to some properties
>
>
>
>   public DateTime? $date;
>>
>> In C# the question mark after a type is a short hand for a generic
>> Nullable type.
>>
>
> I like that it's an established practice of doing exactly what we're
> trying to do.
>
> Could we not just make it obvious?:
>
> public Foo|null $foo;
>

I updated the RFC to include the current state regarding default value and
nullability:
https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax

One question that still needs to be discussed is what syntax regarding
parentheses we want to use if this makes it. Currently both set { } and
set($foo) { } style accessors are supported. Do we want to keep those two
with the new syntax?

Nikita

PS: I hope I'm not interrupting all those heated annotations discussion too
much ^^

Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

[Yahav Gindi Bar]

On Thu, Jan 10, 2013 at 10:42 PM, Anthony Ferrara wrote:

> Stas,
>
>
> On Thu, Jan 10, 2013 at 3:16 PM, Stas Malyshev  >wrote:
>
> > Hi!
> >
> > > Sure. Here you go. Here are two examples:
> > >
> > > http://www.python.org/dev/peps/pep-0020/
> >
> > This is a nice text, but practical meaning of it is kind of unclear.
> > Even then, applying it to what we have now with annotations, I can see
> > they violate at least #1, #2, #3, #5 and #7 :) And possibly #17 too :)
> > Now, I'm not saying we need to accept exactly such rules, and I see how
> > you may disagree with my application of it - but that's exactly my
> > point. I do not see how having something like this would improve what
> > you want to improve.
> >
>
> It would provide context. You saying that annotations violate #1, #2, #3,
> #5 and #7 would be a *PERFECT* argument. It puts context into what's wrong
> with the proposal, and not some ambiguous saying...
>
>
> > Perl one is more practical, but it is a statement of opinion - even
> > though very influential one of a very smart man. Would you be willing to
> > accept such statement if it says something that you personally disagree
> > with? And out of many different opinion, how we choose one that deserves
> > to be "official", making all other ones "officially wrong"?
>
>
> Absolutely. I want A vision, not necessarily MY vision. I want a vision the
> majority can agree with (considering the current state of the dev teams. As
> far as how we choose, I would suggest using the RFC system.
>
>
> Neither are you. Yet I am not telling people to shut up, and you are.
> > Curious.
>
>
> I said to shut up with the rhetoric, not shut up in general.
>
> Additionally, replies like the following ARE telling people to shut up
> IMHO:
>
> http://marc.info/?l=php-internals&m=135083835232016&w=2
>
> >> Hello, list. I want to propose generics.
>
> > Please no. If you need Java, you know where to find it. Java has a set
> > of great tools, great books, great community. And it's completely free.
> > Anybody who needs Java can just do it. I see no need to turn PHP into
> Java.
>
> That's the type of thing I want to get rid of...
>
> > that we can measure things against. Therefore, there is no such thing as
> > > a "good fit for PHP" outside our own personal opinions. It may seem
> like
> >
> > I believe there is. Each language has a philosophy and internal
> > coherence, or at least it should strive to have it. In fact, PHP is
> > frequently criticized for being lacking on this front, and we do not
> > have anything written down formally, but I think it still exists.
> > Moreover, if it does not, and PHP is nothing but a hodgepodge of
> > somewhat useful tools without any coherent thought and system behind
> > them - it would be very bad for PHP project. And if it does exist, then
> > there are things which align with it, and there are things which do not.
>
>
> s:/philosophy/vision/ and that's basically what I'm asking for. It does
> exist informally as 1000 different versions right now (one or 4 per person
> on this list).
>
> And I do currently believe that PHP development currently IS nothing but a
> hodgepodge (how you describe it). I feel it's been that way since at least
> 5.3 when progress on 6 stalled. Since then, it feels like things became
> completely disjointed. The RFC and voting process was a sign of this
> disjoint environment. I want to fix the underlying problem and give the
> project direction again.
>
>
> > > I'm not saying not to express that you think the direction is wrong.
> > > What I'm saying is to express it in a better way than "PHP is not Java"
> > > and "I don't ever want to see this". Those are terminal statements.
> >
> > I made kilobytes if not megabytes of comments on this topic for the past
> > years. So if you try to latch on one phrase which was a part of bigger
> > response and make it sound as if I never explained what I mean and
> > nobody else did the same, repeatedly, over the years - this is just
> > wrong. I did explain and I keep explaining it. You may not agree but
> > please do not make it sound as if I only actually said what I mean
> > instead of droning on with "PHP is not Java", maybe then you could
> > understand it... I said it many times - the syntax proposed is very
> > complex and hardly comprehensible, it creates a separate sub-language
> > inside PHP incompatible with what the rest of PHP is doing, it is not
> > readable and it is helpful only in very small subset of PHP uses. I am
> > not opposed to the idea in general, but I am opposed to the level of
> > complexity - both syntactical and conceptual - it currently involves.
>
>
> And I appreciate (even if I usually disagree) the content you contribute.
> BUt I can't stand when you go on those terminal remarks (PHP is not Java, I
> never want to see this). They are demoralizing, deflating and do nothing
> but shut people down. That's why even in your large reply I picked out one
> phrase. Because that one phr

[PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

[Anthony Ferrara]

Stas,


On Thu, Jan 10, 2013 at 3:16 PM, Stas Malyshev wrote:

> Hi!
>
> > Sure. Here you go. Here are two examples:
> >
> > http://www.python.org/dev/peps/pep-0020/
>
> This is a nice text, but practical meaning of it is kind of unclear.
> Even then, applying it to what we have now with annotations, I can see
> they violate at least #1, #2, #3, #5 and #7 :) And possibly #17 too :)
> Now, I'm not saying we need to accept exactly such rules, and I see how
> you may disagree with my application of it - but that's exactly my
> point. I do not see how having something like this would improve what
> you want to improve.
>

It would provide context. You saying that annotations violate #1, #2, #3,
#5 and #7 would be a *PERFECT* argument. It puts context into what's wrong
with the proposal, and not some ambiguous saying...


> Perl one is more practical, but it is a statement of opinion - even
> though very influential one of a very smart man. Would you be willing to
> accept such statement if it says something that you personally disagree
> with? And out of many different opinion, how we choose one that deserves
> to be "official", making all other ones "officially wrong"?


Absolutely. I want A vision, not necessarily MY vision. I want a vision the
majority can agree with (considering the current state of the dev teams. As
far as how we choose, I would suggest using the RFC system.


Neither are you. Yet I am not telling people to shut up, and you are.
> Curious.


I said to shut up with the rhetoric, not shut up in general.

Additionally, replies like the following ARE telling people to shut up IMHO:

http://marc.info/?l=php-internals&m=135083835232016&w=2

>> Hello, list. I want to propose generics.

> Please no. If you need Java, you know where to find it. Java has a set
> of great tools, great books, great community. And it's completely free.
> Anybody who needs Java can just do it. I see no need to turn PHP into Java.

That's the type of thing I want to get rid of...

> that we can measure things against. Therefore, there is no such thing as
> > a "good fit for PHP" outside our own personal opinions. It may seem like
>
> I believe there is. Each language has a philosophy and internal
> coherence, or at least it should strive to have it. In fact, PHP is
> frequently criticized for being lacking on this front, and we do not
> have anything written down formally, but I think it still exists.
> Moreover, if it does not, and PHP is nothing but a hodgepodge of
> somewhat useful tools without any coherent thought and system behind
> them - it would be very bad for PHP project. And if it does exist, then
> there are things which align with it, and there are things which do not.


s:/philosophy/vision/ and that's basically what I'm asking for. It does
exist informally as 1000 different versions right now (one or 4 per person
on this list).

And I do currently believe that PHP development currently IS nothing but a
hodgepodge (how you describe it). I feel it's been that way since at least
5.3 when progress on 6 stalled. Since then, it feels like things became
completely disjointed. The RFC and voting process was a sign of this
disjoint environment. I want to fix the underlying problem and give the
project direction again.


> > I'm not saying not to express that you think the direction is wrong.
> > What I'm saying is to express it in a better way than "PHP is not Java"
> > and "I don't ever want to see this". Those are terminal statements.
>
> I made kilobytes if not megabytes of comments on this topic for the past
> years. So if you try to latch on one phrase which was a part of bigger
> response and make it sound as if I never explained what I mean and
> nobody else did the same, repeatedly, over the years - this is just
> wrong. I did explain and I keep explaining it. You may not agree but
> please do not make it sound as if I only actually said what I mean
> instead of droning on with "PHP is not Java", maybe then you could
> understand it... I said it many times - the syntax proposed is very
> complex and hardly comprehensible, it creates a separate sub-language
> inside PHP incompatible with what the rest of PHP is doing, it is not
> readable and it is helpful only in very small subset of PHP uses. I am
> not opposed to the idea in general, but I am opposed to the level of
> complexity - both syntactical and conceptual - it currently involves.


And I appreciate (even if I usually disagree) the content you contribute.
BUt I can't stand when you go on those terminal remarks (PHP is not Java, I
never want to see this). They are demoralizing, deflating and do nothing
but shut people down. That's why even in your large reply I picked out one
phrase. Because that one phrase was more powerful than the rest of your
reply...

Anthony

Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

[Levi Morrison]

>> what is not*. You are not a BDFL. And we don't have a unified vision
>
> Neither are you. Yet I am not telling people to shut up, and you are.
> Curious.

I reiterate that there are other people besides Anthony who are
annoyed by your behavior, Stas. You've voiced your opinion, are you
done now?

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

Re: [PHP-DEV] A remark about PHP's Vision and new things.

[Stas Malyshev]

Hi!

> I strongly suggest to anyone following the (too many) threads about
> annotations to try the C# annotation and see what it allows. It goes

As far as I can see, C# annotations rely on two very important things:
1. Compiler support. Compiler really knows a lot about what annotations do.
2. Extensive library support. Annotations themselves are just passive
metadata, what makes them work is .net framework that uses them.

This means to make annotations as useful in PHP we would have to have
substantial support in the engine (including bytecode caching
provisions, etc.) and some libraries that require very
latest-and-greatest version of PHP.

Another thing is that we're not having some features that are used
extensively in C# annotations, main being named parameters support.

I am saying this not to oppose the idea of annotations or the idea of
looking into C# and other languages (actually, I think anybody who talks
about it should look at least into what C# and Java do with it - and
also what Python does, which is completely different direction, just to
know other options). I'm just saying porting this to PHP may be less
than straightforward.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

[PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

[Stas Malyshev]

Hi!

> Sure. Here you go. Here are two examples:
> 
> http://www.python.org/dev/peps/pep-0020/

This is a nice text, but practical meaning of it is kind of unclear.
Even then, applying it to what we have now with annotations, I can see
they violate at least #1, #2, #3, #5 and #7 :) And possibly #17 too :)
Now, I'm not saying we need to accept exactly such rules, and I see how
you may disagree with my application of it - but that's exactly my
point. I do not see how having something like this would improve what
you want to improve.
Perl one is more practical, but it is a statement of opinion - even
though very influential one of a very smart man. Would you be willing to
accept such statement if it says something that you personally disagree
with? And out of many different opinion, how we choose one that deserves
to be "official", making all other ones "officially wrong"?

> Not so minor correction: *It's about what is a good fit for PHP and what
> is not* should be *It's about what I believe is a good fit for PHP and

You really need an explicit note that I express my opinion? Of course
it's mine, whose else opinion could I express?

> what is not*. You are not a BDFL. And we don't have a unified vision

Neither are you. Yet I am not telling people to shut up, and you are.
Curious.

> that we can measure things against. Therefore, there is no such thing as
> a "good fit for PHP" outside our own personal opinions. It may seem like

I believe there is. Each language has a philosophy and internal
coherence, or at least it should strive to have it. In fact, PHP is
frequently criticized for being lacking on this front, and we do not
have anything written down formally, but I think it still exists.
Moreover, if it does not, and PHP is nothing but a hodgepodge of
somewhat useful tools without any coherent thought and system behind
them - it would be very bad for PHP project. And if it does exist, then
there are things which align with it, and there are things which do not.

> I'm not saying not to express that you think the direction is wrong.
> What I'm saying is to express it in a better way than "PHP is not Java"
> and "I don't ever want to see this". Those are terminal statements.

I made kilobytes if not megabytes of comments on this topic for the past
years. So if you try to latch on one phrase which was a part of bigger
response and make it sound as if I never explained what I mean and
nobody else did the same, repeatedly, over the years - this is just
wrong. I did explain and I keep explaining it. You may not agree but
please do not make it sound as if I only actually said what I mean
instead of droning on with "PHP is not Java", maybe then you could
understand it... I said it many times - the syntax proposed is very
complex and hardly comprehensible, it creates a separate sub-language
inside PHP incompatible with what the rest of PHP is doing, it is not
readable and it is helpful only in very small subset of PHP uses. I am
not opposed to the idea in general, but I am opposed to the level of
complexity - both syntactical and conceptual - it currently involves.

> Instead, if you said "This feature seems to me to be overly complex, and
> that the implementation gains nothing for that complexity", then people
> may learn your point of view. And they may be able to show you the

I said this many times. People just dismiss it saying "baloney, my ORM
needs exactly this level of complexity, and you just don't know first
thing about what real men do with real code". And then come back with
even more complex design.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] strtr vs. str_replace runtime

[Nicolai Scheer]

Hi!


On 9 January 2013 23:45, Gustavo Lopes  wrote:

> On Thu, 03 Jan 2013 11:40:31 +0100, Gustavo Lopes 
> wrote:
>
>  The algorithm behaves very poorly in this case because at each position
>> of the text, all the substrings starting there and with size between m and
>> n (where m is the size of the smallest pattern and n is the largest) are
>> checked, even if there are only two patterns with size m and n. We could
>> fix this easily by building a set of the pattern sizes found and try only
>> with those. The hashing of the substrings could also be improved; we don't
>> have to recalculate everything when we advance in the text.
>>
>>
> Both optimizations (the hash rolling and limiting the substrings hashed on
> each iteration) worked quite well.
>
> But I got much better results with another algorithm [1], so I'm going to
> merge the branch with it [2] instead. I get these results with a 1.7 MB
> string and 13 replacement strings, the smallest with 6 characters and 30
> iterations (x86-64, gcc -O3):
>
> strtr: 0.1387
> str_replace: 0.4471
>

Nice :)


>
> The algorithm doesn't perform as well when the replacement strings are
> small. Adding a replacement for the pattern '_' (1 character) yields:
>
> strtr: 0.6157
> str_replace: 0.6230
>

Even that is way better than before :)


>
> But even in this case, it works better than my optimized version of the
> current algorithm.
>
> I plan on merging to 5.4 and 5.5; you may want to review it as introducing
> completely new code carries some risk.
>
> [1] 
> http://citeseerx.ist.psu.edu/**viewdoc/summary?doi=10.1.1.13.**2927
> [2] https://github.com/cataphract/php-src/compare/strtr_wu94


Does "merging to 5.4" mean I can grab the head of the 5.4 branch afterwards
and try it myself?

Thanks!

Greetings

Nico

[PHP-DEV] PHP5.5.0alpha3 released

[Julien Pauli]

Hi Internals,

PHP 5.5.0alpha3 has been tagged today. This
release contains bug fixes against alpha2, as well as
new features in existent APIs.

The packages can be found at:

http://downloads.php.net/dsp
As you know, you may read the NEWS file in the source tree for full
changelog
of this release.

Please test PHP5.5.0alpha3 carefully, and report any bugs in the bug
system. Alpha 4
will be tagged on January 24th.

Thank you all contributors who pushed code and ideas for this alpha3.

Regards
  David and Julien

Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

[Florin Razvan Patan]

This could be very well be off-topic but I think it is something that
 someone has to say it at some point. Don't worry, there's a vision
 in there, near the end of this, please just have the patience of
 reading this as a part rant, part wish :)

 You all speak about new things, better userland code, gaining new
 features, functionalities, getting a vision but you never speak about
 the core.

 There's a clear need for a change in the core but new features are
 demanded every day...

 Solving the core should be done with a major BC break after 5.5
 and it should improve all the things that need to do be improved
 while preparing the architecture for future changes/additions.

 I think that Symfony2 should be a great example of this being a
 good approach in terms of produced results. If you look at the code
 it will provide both the cleanness and the flexibility needed to do
 great things with it yet it allows it so be simple to pick up and
 learned by new devs.

 Maybe other projects, including PHP, should take this lesson and
 see how they can make themselves better even if in the process
 they'll break all user space.

 For PHP strictly speaking now, I think that after 5.5 there should
 be a pause of two-three months for devs, get a holiday or just
 relax, then, sit with the community at a couple of meetings and
 talk about how PHP 6, 6.1, 6.2 and so on could/should look like.

 I'm not saying it's going to be an easy task, nor a pleasant one,
 but this should be done sooner that later as it's bound to happen
 at some point imho.

 While we might not get cool new things like annotations, named
 parameters or anything else that we, the users of PHP would like,
 we could get:
 - better internals which help adding those missing features faster;
 - make APC easier to maintain if the parser/compiler are easier to
 interact with;
 - get consistency in the whole haystack/needle problem :)
 - possibly get a better extension system so that C extensions are
 easier to write/maintain;
 - those missing things faster / easier to implement in PECL;
 - maybe more :)

 Redoing PHPs internals would help also getting a vision of the
 language, that suddenly every one cries about, while getting cleaner
 code for the core and help to increase the general numbers of core
 contributors for it.

 With such a large user base I still find it extremely surprising
 that php-core is maybe a dozen people or so while projects like
 Symfony/Zend Framework/Typo3/etc have hundreds of contributors.

 Yes! We 'need' new cool stuff in PHP, that maybe will be forgotten
 in two-three years or not, we find new ways to make the userland
 code more easy to write, operate, read and above all faster!

 But you can't build a 70 story skyscraper on top of a foundation
 that's meant to support a five story building.

 If you are going to ask the core devs to accept/do something that
 you deem cool, why not thinking about doing the things better
 all-around first, then add the coolness factor later?

 And yes, annotations are cool but it's' by far a --must-- have or
 something that gets in the way of developing new ideas to the
 point where they just can't exist (as proven by Doctrine Common).



 Have a nice day.

 
 Florin Patan / @dlsniper


On Thu, Jan 10, 2013 at 3:29 PM, Anthony Ferrara  wrote:
> Rasmus,
>
>> Rasmus: "A general purpose scripting language with a focus on web
>> > development"
>> > You: "being simple and practical and focused on the web"
>> >
>> > While they both have "web" in them, they provide very different goals and
>> > metrics with which to gauge contributions by. And that's the entire point
>> > of my call for a single, consistent and official vision...
>>
>> They don't seem different to me, and the first one is the documented
>> statement that has been the first thing people see on http://php.net for
>> years and years. You can add "simple and practical" to mine or add
>> "general purpose" to the Stas one and it doesn't conflict in any way.
>>
>
> There's a difference between a byline and a vision. But even deeper, the
> "vision" that you wrote widens the scope of PHP development into basically
> all possible directions, as long as Web Development is a focus.
>
> Stas's vision on the other hand narrows the scope quite significantly by
> focusing on simple and practical implementations.
>
> Here's an example of the difference. Let's say that an RFC came out to
> introducelist comprehentions PHP. According to your vision, that's
> completely on the table and is welcome. But Stas's stated vision would
> counter that because it's not "simple".
>
> And Stas's stated vision leads to things like this:
> http://news.ycombinator.com/item?id=5034365 It is trivial to misinterpret
> (or perhaps not so mis) it as "we can't do anything complex, because think
> of the new people".
>
> What I'm proposing here is a stated vision that clarifies and sets a
> reasonably narrow vision for what development should do. I'm not saying it
> 

[PHP-DEV] Add a zend_qsort_r/zend_qsort implementation

[Gustavo Lopes]

I need to order an native array. The comparison function needs some 
context to do the comparison.


For test purposes, I defined _GNU_SOURCE and used qsort_r. But since 
this is obviously not acceptable I looked for alternatives.


PHP includes at least two sorting functions:

zend_qsort (in Zend/zend_qsort.c)
php_mergesort (in main/mergesort.c), which is not used anywhere, 
including PECL:

http://lxr.php.net/search?q=&defs=&refs=php_mergesort&path=&hist=&project=PECL&project=PHP_TRUNK

Both take comparison functions with the type
int (*)(void *, void * TSRMLS_DC)

So I *could* pass the context through a global variable, but I'd rather 
not do it. I think it'd be good to have a zend_qsort_r function with a 
different comparison function type:

int (*)(void *, void * TSRMLS_DC, void *)

With this we could implement zend_qsort in terms of zend_qsort_r very 
simply, though with technically undefined behavior:

https://github.com/cataphract/php-src/commit/c6aa2faa83dc8787d7cefcb27faa7f07f4aae6f0

We could export zend_qsort_r starting in 5.5; I need it ext/standard so 
it need not be exported, which would be problematic on a stable branch. 
It's undefined behavior because the comparison function is being called 
with one extra pointer argument. This is the same technique glibc uses 
though, so it should be safe. I could not find any measurable 
performance penalty.


***

A different topic: the current zend_qsort function can be further 
optimized. I got these results (test script below, best of 5 runs) with 
the current implementation:

random: 0.6453
sorted:0.6091
reverse sorted: 0.6203

And bionic's quick sort implementation:
random: 0.5361
sorted:0.5769
reverse sorted: 0.5920

I also tested with musl's smooth sort implementation:
random: 1.3554
sorted:0.2584
reverse sorted: 0.6439

Bionic's implementation also has the advantage that it appears to be 
stable:

print_r(implode(' ', array_keys(array_filter($a, function ($e) {return 
$e === 3;};


prints "4 5 2 1 6" with the current implementation, "1 2 4 5 6" with 
bionic's.


What do you think about replacing the implementation for 5.5?

***

TEST SCRIPT:
echo "random: " . number_format( microtime( true ) - $start, 4 ) . 
"\n";

unset($t1);

$t2 = $a; sort($t2);
$start = microtime( true );
sort($t2);
echo "sorted:" . number_format( microtime( true ) - $start, 4 ) . "\n";
unset($t2);

$t3 = $a; rsort($t3);
$start = microtime( true );
sort($t3);
echo "reverse sorted: " . number_format( microtime( true ) - $start, 4 
) . "\n";


--
Gustavo Lopes

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

Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

[Anthony Ferrara]

Rasmus,

> Rasmus: "A general purpose scripting language with a focus on web
> > development"
> > You: "being simple and practical and focused on the web"
> >
> > While they both have "web" in them, they provide very different goals and
> > metrics with which to gauge contributions by. And that's the entire point
> > of my call for a single, consistent and official vision...
>
> They don't seem different to me, and the first one is the documented
> statement that has been the first thing people see on http://php.net for
> years and years. You can add "simple and practical" to mine or add
> "general purpose" to the Stas one and it doesn't conflict in any way.
>

There's a difference between a byline and a vision. But even deeper, the
"vision" that you wrote widens the scope of PHP development into basically
all possible directions, as long as Web Development is a focus.

Stas's vision on the other hand narrows the scope quite significantly by
focusing on simple and practical implementations.

Here's an example of the difference. Let's say that an RFC came out to
introducelist comprehentions PHP. According to your vision, that's
completely on the table and is welcome. But Stas's stated vision would
counter that because it's not "simple".

And Stas's stated vision leads to things like this:
http://news.ycombinator.com/item?id=5034365 It is trivial to misinterpret
(or perhaps not so mis) it as "we can't do anything complex, because think
of the new people".

What I'm proposing here is a stated vision that clarifies and sets a
reasonably narrow vision for what development should do. I'm not saying it
needs to be a 100% "we can do this but never that", but something to guide
progress rather than the random thoughts of the people who just so happen
be reading the discussion at the time.

Something like: http://www.python.org/dev/peps/pep-0020/

Something to guide discussion that's applicable primarily to PHP...

Anthony

[PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

[Anthony Ferrara]

Stas,

If you mean that there would be some "vision" document that prevents
> disagreement and decides arguments once and for all, are you sure it is
> what you want? It is clear we disagree on many things. Suppose I wrote a
> document that describes how I see PHP should be, and it will be accepted
> as a "vision". Would you then say it is the right thing to do and agree
> with me completely as far as the "vision" document goes? Would you
> expect everybody else to do so? Probably not.
> So while we can have some vague "mission statement", there would always
> be disagreement on specific questions, and only way you can avoid that
> is to exclude some side of the debate. We can have a vision, but not one
> that would be used to avoid disagreement and discussion.


I'm absolutely not talking about avoiding disagreement and discussion. I'm
talking about having a vision that can be used to frame them so that they
are productive. As it stands now, each person has their own mental vision
as to what PHP should be and do. When people discuss a feature, they are
discussing it relative to their own vision. By putting a shared common
vision, it can become easier to see what the common misgivings are, and
make it easier to communicate them.


> > While they both have "web" in them, they provide very different goals
> > and metrics with which to gauge contributions by. And that's the entire
> > point of my call for a single, consistent and official vision...
>
> Can you give me some examples of modern languages like PHP having
> "official visions" like that? I'd really like to understand what kind of
> official vision you have in mind. Some document examples would help.


Sure. Here you go. Here are two examples:

http://www.python.org/dev/peps/pep-0020/

http://www.perl6.org/archive/doc/design/apo/A01.html


> > Again, "PHP is not X" is rhetoric. Pure and simple. You could use that
> > to reject *any* feature that we didn't explicitly invent. Which is the
>
> Maybe I could, but I never did and never intend to, and you know that I
> have supported and participated in discussions of number of features
> that I did not explicitly invent. It is not about me. It is about what
> is a good fit for PHP and what is not. I think some complex features are
> not a good fit for PHP and that's my "vision".


Not so minor correction: *It's about what is a good fit for PHP and what is
not* should be *It's about what I believe is a good fit for PHP and what is
not*. You are not a BDFL. And we don't have a unified vision that we can
measure things against. Therefore, there is no such thing as a "good fit
for PHP" outside our own personal opinions. It may seem like a minor point,
but it's the exact thing I'm sitting here asking for (A unified vision).


> > Yes you do! And quite often you do it in a very good and constructive
> > way. I applaud that. But you also provide it in a very destructive way
> > at times. And that's what I'm asking you to please stop. For example:
>
> I think the direction such changes take PHP is wrong, and I see no
> reason why I need to stop saying that. I think adding such syntax would
> make PHP code look convoluted and would significantly impair ability of
> the developers to understand what's going on. It may be a perfect fit
> for a couple of ORM-like use cases, but I think it's not enough to make
> it part of the general PHP language. I hope we can find common ground
> that can be useful for ORM folks but still not over-complicated and does
> not develop into additional sub-language with some weird syntax driven
> mainly by "which symbol didn't we use yet?" But if it is the only way to
> do it, then I'd rather not.


I'm not saying not to express that you think the direction is wrong. What
I'm saying is to express it in a better way than "PHP is not Java" and "I
don't ever want to see this". Those are terminal statements. There's no way
for people to learn and adjust what they are thinking. Instead, if you said
"This feature seems to me to be overly complex, and that the implementation
gains nothing for that complexity", then people may learn your point of
view. And they may be able to show you the gains. Or they may not, and your
point takes hold even further. But at least it frames a discussion rather
than putting a period in the middle of it...

Anthony

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

[Pierre Joye]

On Thu, Jan 10, 2013 at 11:34 AM, Amaury Bouchard  wrote:

> Sorry, but if something seems not good for PHP, any of us should share his
> thoughts.

"I don't like" or "-1" have nothing to do with thinking or discussing.
That's Anthony's point (could have been slightly more diplomatic but
so it is :)

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] A remark about PHP's Vision and new things.

[Ferenc Kovacs]

On Thu, Jan 10, 2013 at 10:17 AM, Nate Tuganov  wrote:

> Hello,
>
> Well, I've been reading internals for years and never replied. But I think
> this time I have to share my thoughts.
>
> First of all I understand Rasmus and Stas position on holding PHP as simple
> as it is. It's great and in the same way it's wrong. As Anthony mentioned
> PHP evolves, and PHP is being used not only by designers who want to create
> a simple corp site which by the way move to Rails, but mostly by thousands
> of web agencies, developers and senior developers who constantly using
> different languages and technologies. We have Ruby with all the sugar it
> gives, we have Java with all enterprise mess it has. And we have PHP.
>
> I don't think I need to advocate OOP here, and I agree with Rasmus that we
> need to stay simple. But we don't need to copy all those things from Java
> for example, even Java world has Play! Framework which is great and gives
> simpleness to the developer. We all know how annotations are being used by
> Symfony or Doctrine and I don't think we need to create all the mess it has
> in Java world. We all know the problems it give, why not to eliminate it
> and create a new, PHP's vision of things. Right now all discussions are
> being held like we will never implement annotations because we need to copy
> it from Enterprise Java. But we don't need Java annotations, we need our
> own. Constantly decline great futures just because some designer wouldn't
> understand it is wrong by all means.
>
> PHP is great for web development, let's stick to it. Give us a chance to
> create frameworks, which can use Annotations, DI, IoC, Factories,
> Decorators and all others patterns to allow regular designer to create a
> simple site with few lines of code.
>
> --
> Kind Regards,
>
> Ignat Tuganov
> Chief Information Officer
>
> Office Phone: +7 (812) 640-8022
>
> E-Mail \ Gtalk: i...@cloudmill.ru
>
> CloudMill LLC
> 191015, 3 K Furazhnyi Lane, office #317, Saint-Petersburg, Russia
>

hi,

another thing to keep in mind:
most PHP frameworks out there has a faster development cycle and less of an
userbase than us(as every PHP framework user is a PHP user ofc.), so if
they make a bad design decision it is usually easier for them to fix it and
it has less of an impact and they have more people with the ability to fix
up any technical problems, as it is reasonably easy to find somebody with
the neccessary skills and knowledge required to fix the problem.
of course now that we introduced the new release process, hopefully we will
have faster release cycles, and some of the popular frameworks started
planning/introducing LTS releases with longer support cycle.
but still, we have to be careful about what do we introduce to the
language, because we have to support it for at least like minor 3 releases(
we introduce it in 7.2, deprecate it in 7.3 and remove it in 8.0 for
example).
back in the early symfony days using Singletons everywhere seemed like a
good idea, currently the general consensus is that it is an anti-pattern,
and only in a handful of use-cases is it a good idea using it.
similar thing happened with ORMs, first ORM meant pretty much using the
activerecord pattern, now the general consensus seems to be to use the data
mapper pattern instead.
if we too eager to include new hip stuff, it can happen that we will get
stuck with a half-baked solution which we have to support years after that
the cool guys already moved to something else.
the other thing that I mentioned is the difference between the required
skills needed to fix up bad implementations:
there aren't that many people familiar with the php-internals (and this
isn't the easier skill to pick up, as we somehow lack in quality
documentation on the internals part), even less people are familiar with
the parser, ZendEngine, and APC.
just some of the recent examples:

   - traits was a nice RFC, complete patch, has an active author, years of
   discussion, and it still needed a huge amount of work/refact to make it
   play nicely with some edge-cases and with APC. (kudos to Stefan and
   Dmitiry)
   - the finally feature: it was almost completely rewritten after the RFC
   with the initial patch was voted and accepted (kudos to Laruence and Dmitry)
   - introducing generators also needed some love (a few segfaults in
   edge-cases AFAIR and making it work together with finally kudos to Nikita
   and Dmitry).

So I think the current problems are the following:

   - users won't migrate to new php version until some of the top pecl exts
   having issues with the new version (apc was a really obvious showstopper
   for the php5.4 adoptation for example).
   - currently voting is more about wanting the feature or not, and not
   about wanting/accepting the feature with the current implementation. this
   can result in situations when something is accepted and merged, but it has
   to be fixed/maintained, and that sucks when the work happens to require the
   help o

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

[Chris van Dam]

Dear internals,

>There is multiple problems with annotations:
>- It's a language in the language. A new syntax to learn. It's not in the
>code, but without it the code have fat chance to work anymore.
>
>- It's a parser in the parser. More code to maintain inside PHP engine.
>Maybe some performance issues.

My main problem with annotations, in their current form, is that it adds
complexity to PHP
Which the language does not need.

In the 15 years I have been using PHP I never had the need to use
annotations. And the implementations
I've seen so far only add code which is difficult to debug.

Annotations belong in a compiled language and not in PHP.

Just my 2 cents.


Kind regards,

Chris


E-mail disclaimer Nederlands
De informatie verzonden met dit e-mailbericht is vertrouwelijk en kan wettelijk 
voorbehouden zijn. Het is uitsluitend bestemd voor de geadresseerde. Gebruik 
van deze informatie door anderen dan de geadresseerde en zij die gerechtigd 
zijn daarvan kennis te nemen is verboden. Trace staat niet in voor de juiste en 
volledige overbrenging van de inhoud van een verzonden e-mail, noch voor 
tijdige ontvangst daarvan.
E-mail disclaimer English
The information contained in this communication is confidential and may be 
legally privileged. It is intended solely for the use of the individual or 
entity to whom it is addressed and others authorized to receive it. The use of 
it by others is prohibited. Trace is neither liable for the proper and complete 
transmission of the information contained in this communication nor for any 
delay in its receipt.


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

Re: [PHP-DEV] Recommended ignore list for GIT/SVN?

[Ferenc Kovacs]

On Thu, Jan 10, 2013 at 8:29 AM, J. Adams  wrote:

> Is there any official/doctrinal list of file types for a GIT/SVN ignore
> list when working on a PECL extension?  I've been snooping around and found
> the following (from http://stackoverflow.com/**
> questions/85353/best-general-**svn-ignore-pattern)
> but was wondering if there was any ignore list that is gospel for the PHP
> dev community.
>
>
> *.o *.lo *.la #*# .*.rej *.rej
> .*~ *~ .#* .DS_Store thumbs.db
> Thumbs.db *.bak *.class *.exe *.dll
> *.mine *.obj *.ncb *.lib *.log
> *.idb *.pdb *.ilk *.msi* .res *.pch *.suo
> *.exp *.*~ *.~* ~*.* cvs  CVS .CVS .cvs
> release Release debug Debug
> ignore Ignore bin Bin obj  Obj
> *.csproj.user *.user
> *.generated.cs
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
you can check some examples from existing packages (see the svn:ignore from
http://svn.php.net/viewvc/pecl/apc/trunk/ for example) and we also have a
pear package called PECL_Gen for generating skeletons for pecl extensions
(it was intended to replace the ext_skel.utility (
http://php.net/manual/en/internals2.buildsys.skeleton.php) which contains a
moderate ignore list:
http://svn.php.net/viewvc/pecl/PECL_Gen/trunk/Extension.php?view=markup#l2098

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

[Amaury Bouchard]

2013/1/10 Rafael Dohms 

> In my humble opinion, if your only "argument" is a -1, the don't be part of
> the discussion, but rather be a vote when (and if) the RFC goes to a vote.
>
> There are 2 moments to express yourself: the discussion, the vote.
>
> In the discussion phase I believe opinion should be expressed with solid
> concerns. Performance issues, bad syntax, is it relevant or not, etc.
> A simple "i don't like it" does not add, so it can be ommited.
>

«is it relevant or not» => If I can't express my dislike, how can I say
that I think something is not relevant?

Sorry, but if something seems not good for PHP, any of us should share his
thoughts. Because it is pointless to work on RFCs and to write patches if
everybody agreed that the functionality is not needed. Discussions are not
here just to push new functionalities as far as possible, without arguing
if we need them or not, waiting for the vote to be the last safeguard.

Well, it's my humble opinion.



2013/1/10 Tyler Sommer 

> Annotations are already a part of PHP. They are widely used in one of the
> most prolific frameworks, Symfony, and it's ORM "counterpart" Doctrine.
> Both of which are serious drivers of the PHP community. It's
> even potentially spreading to Zend Framework:
>
> http://zend-framework-community.634137.n4.nabble.com/Annotations-own-implementation-or-Doctrine-Commons-td4655427.html
>
> To say "they shouldn't be part of PHP" is fine, but it's too late for that.
> Annotations are already here. Are we going to just ignore this fact and
> hold back what a very significant portion of the community wants to see
> because it conflicts with some ambiguous master plan for PHP?
>

Last summer, I heard a talk from Rasmus. He was presenting what's new in
PHP. I remember there was something (I don't remember what exactly, sorry)
that seems a bit useless. Roughly speaking, Rasmus said that this kind of
functionality will not be used by everybody, but the guys who are writing
frameworks will love it.
This kind of evolution is fine. No problem to add things inside PHP, even
if they will be used by few people, as long as it will not change anything
for the rest of us.

When PHP went OO, I guess everybody agreed. We knew that, from this point,
PHP programming will deeply change, because new extensions will be object
oriented; but it was not a problem. Yes, object programming became the new
proper way to code in PHP, but it was still possible to do without it.
When PHP5 went deeply OO, it was not a problem either. Yet it was the
beginning of new changes. For example, if I want to use SPL, I will surely
have to use objects, interfaces and exceptions. But nobody is forced to do
this.
When traits came in PHP, again it was not a problem. You can use it, but
it's not an obligation. And it doesn't change how everybody should code.

There is multiple problems with annotations:
- It's a language in the language. A new syntax to learn. It's not in the
code, but without it the code have fat chance to work anymore.

- It's a parser in the parser. More code to maintain inside PHP engine.
Maybe some performance issues.

- More important, providing annotations as it is proposed will make them a
core feature of the language. It will be perceived like objects,
exceptions, interfaces or visibility. And the direct impact is that PHP
will be seen as a more complex language. A really. More. Complexe. Language.


Yes, I know that C# has a lot of good ideas. But I also know that C# is not
seen as flexible and "teach-me-how-to-code-I-will-use-you-professionally"
as PHP.

It's true that annotations are already used by frameworks and ORM. But it
is their choices, and usually annotations are one of many possibilities to
configure code-related stuff.
Annotations are not seen as the right way of writing PHP code just because
annotations are used by Symfony and Doctrine. But if you put them inside
the core of PHP, annotations will gain this status. And I don't know what
to say except "I don't like it".


One last thought about the "PHP is not Java" thing. Anthony is bored by
that. OK. But maybe it's not totally pointless.
Many stuff were taken from Java, in the PHP's OO model. OK. The generator
concept came from Python. OK. There is some interresting things in many
other languages (Ruby, Lua). I guess it's OK to take inspiration from them.

When the "yield" keyword appeared, I don't remember anything like "PHP is
not Python". Why? Because it's a cool new feature, but it doesn't change
PHP behaviour.
Annotations are maybe too much for PHP; on the wrong side of the line. Yes,
I know, the line is not defined, but still.

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

[Ryan McCue]

Martin Keckeis wrote:
> The usage statistic is easy explained...
> Long time there was no planned "release cycle" so nobody could plan to
> upgrade (especially hoster and linux distributions, ...)
> 
> Another reason why many people stick with the old version is poor written
> software like WORDPRESS -.-.

Chicken-and-egg problem: we still have ~2/3 of users on PHP 5.2:
http://wordpress.org/about/stats/

WordPress' code quality is improving vastly, but we have to deal with
backwards compatibility for our internal APIs (which is a big reason for
not having switched to PDO yet, e.g., although it looks like that will
land in our next major version) and we can't use the newest features. It
doesn't help that many of the nice things we'd like to use (e.g.
DOMDocument) are disabled in some of the distro packages (Debian/CentOS,
IIRC), but we've dealt with this in the past and we'll continue to do so.

-- 
Ryan McCue


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

Re: [PHP-DEV] A remark about PHP's Vision and new things.

[Pierre Joye]

On Thu, Jan 10, 2013 at 10:17 AM, Nate Tuganov  wrote:

> PHP is great for web development, let's stick to it. Give us a chance to
> create frameworks, which can use Annotations, DI, IoC, Factories,
> Decorators and all others patterns to allow regular designer to create a
> simple site with few lines of code.

That's exactly what annotations are for. Avoid writing the same code
over and over, define behavior using annotation.

I strongly suggest to anyone following the (too many) threads about
annotations to try the C# annotation and see what it allows. It goes
really far and greatly simplify developments and implementations of
web services (by all meaning of this word). And I very strongly
recommend it to anyone who never used or tried annotation, it will
help us to move further and move out of the current rhetoric (both
sides).

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

[PHP-DEV] A remark about PHP's Vision and new things.

[Nate Tuganov]

Hello,

Well, I've been reading internals for years and never replied. But I think
this time I have to share my thoughts.

First of all I understand Rasmus and Stas position on holding PHP as simple
as it is. It's great and in the same way it's wrong. As Anthony mentioned
PHP evolves, and PHP is being used not only by designers who want to create
a simple corp site which by the way move to Rails, but mostly by thousands
of web agencies, developers and senior developers who constantly using
different languages and technologies. We have Ruby with all the sugar it
gives, we have Java with all enterprise mess it has. And we have PHP.

I don't think I need to advocate OOP here, and I agree with Rasmus that we
need to stay simple. But we don't need to copy all those things from Java
for example, even Java world has Play! Framework which is great and gives
simpleness to the developer. We all know how annotations are being used by
Symfony or Doctrine and I don't think we need to create all the mess it has
in Java world. We all know the problems it give, why not to eliminate it
and create a new, PHP's vision of things. Right now all discussions are
being held like we will never implement annotations because we need to copy
it from Enterprise Java. But we don't need Java annotations, we need our
own. Constantly decline great futures just because some designer wouldn't
understand it is wrong by all means.

PHP is great for web development, let's stick to it. Give us a chance to
create frameworks, which can use Annotations, DI, IoC, Factories,
Decorators and all others patterns to allow regular designer to create a
simple site with few lines of code.

-- 
Kind Regards,

Ignat Tuganov
Chief Information Officer

Office Phone: +7 (812) 640-8022

E-Mail \ Gtalk: i...@cloudmill.ru

CloudMill LLC
191015, 3 K Furazhnyi Lane, office #317, Saint-Petersburg, Russia

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

[Lester Caine]

Martin Keckeis wrote:

The usage statistic is easy explained...
Long time there was no planned "release cycle" so nobody could plan to upgrade
(especially hoster and linux distributions, ...)


Please respect site etiquette and don't top post ...

Your view of things is wrong simply because it is the release cycle that has 
caused the situation. The move to 5.3 was stalled because many ISP's found that 
having changed too many older sites were broken and they had to roll back. 
Things are improving, but the current upgrade path is STILL to PHP5.3 despite 
the fact it is now being run down. There is still no well defined upgrade path 
to bring legacy code forward other than 'switch off the warnings', and the move 
to PHP5.3 to 5.4 can only be made by ISP's when their clients code base is all 
upgraded TO 5.3 standards, so that a move to 5.4 does not add to the troubles.



Another reason why many people stick with the old version is poor written 
software like WORDPRESS -.-


That may be the case. What is important here is being able to bring both code 
and more importantly content from older systems to the newer platform. If a site 
has several years of live data and is working for it's target audience what is 
the incentive to spend time and money porting it to a different platform that 
does not add any value. Most end users ARE using 'old version is poor written 
software' but in many cases they have no capability of fixing that problem 
themselves. The project platforms are racing ahead of the platform that the end 
users are restricted to using :(


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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Ivan Enderlin @ Hoa]

Hi,

My answer below.

On 09/01/13 20:57, guilhermebla...@gmail.com wrote:

Pierrick, before update v3 of patch, let's first clarify things that need
to be discussed.
Rasmus, you have no idea how happy you made me for a gentle comment
pointing something we should think before propose a patch instead of on
(sorry for the wording) bitching about the idea.

There're tons of elements that need to be addressed before working on a
patch.

Oh yeah.


The latest annotations RFC is a small subset of what other languages
support.

Oh yeah.



To a more complete feature-wise, it is required to go to a
previous revision: https://wiki.php.net/rfc/annotations?rev=1302087566

[snip]


Let's discuss? Thanks.
What do you think about my proposal: 
http://news.php.net/php.internals/64727 ?


Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


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

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

[Martin Keckeis]

The usage statistic is easy explained...
Long time there was no planned "release cycle" so nobody could plan to
upgrade (especially hoster and linux distributions, ...)

Another reason why many people stick with the old version is poor written
software like WORDPRESS -.-.

I would also like to see a vision like it was for PHP6unicode support,
namespaces, ...

For annotations i cannot "vote", because i won't use them.

Best regards
Martin


2013/1/10 Lester Caine 

> guilhermebla...@gmail.com wrote:
>
>> I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about
>> acceptance of new features.
>> You all claim that PHP is simple, that features include should be widely
>> used and only important functions, classes that have regular and extensive
>> usage would be in.
>>
>
> I'd use the past tense there ...
> And I'll get beaten around the head again.
>
> PHP is a very nicely modular 'framework' on top of which many other views
> of the world have now been built. We DON'T need to load a lot of the recent
> developments ... we don't need to use them. Personally I don't load any
> MySQL related extensions since I don't have MySQL loaded. APC is replaced
> by eaccelerator which continues to work well for me (currently!). I've use
> phpdocumentor since I started with PHP because that was what all of the
> libraries USED internally to model/document the API, and since I used
> Eclipse as my IDE for C/C++ code, PHPEclipse was a natural progression and
> also uses the docblock information to provide in-line type hinting and a
> lot of the information that people are now clamouring to build in to the
> 'language'?
>
> I can understand some of the drives to 'new features', but I know I'm not
> alone in feeling rail-roaded into having to accept changes that are just
> detracting from writing code. Perhaps we can ignore 'e_strict' but the
> fundamental problem doing that is that moving 5.2 based code to 5.5 is
> simply not practical. Setting up a system that will run 5.2 code cleanly on
> a 5.4 configuration is only practical if you have a completely different
> set-up for clean 5.4 code! We NEEDED a better vision 5 years ago :( Now we
> need to manage the fallout and I know I keep banging on about it, but over
> 50% of user land are STILL using 5.2! Only 1.8% have 5.4 running with the
> main movement over the last few months TO 5.3 simply because that is the
> easiest way for ISP's to support their customers. ( http://w3techs.com/**
> technologies/details/pl-php/5/**all)
>
> Bolting more and more facilities into core because a few users have the
> backing to force them in does not help the vast majority of user-land users
> who don't need those facilities. The argument that they need to be in the
> core so that ISP's will provide them probably highlights the whole problem?
> If your application needs some particular 'extension' to work then
> shouldn't that be part of the 'application' rather than the
> 'infrastructure'? Isn't the fact that one can add to PHP your own view of
> the world the whole point here. However it's also the Achilles heel so
> there ARE now large groups of people 'doing their own thing' and pulling
> things in a lot of different ways? Not everybody wants the
> Symphony/Doctrine/ORM view of the world. We are happy with using the
> database engine as the persistence layer, and a good abstraction layer as
> the interface ... code written 10 years ago still works ... or should do :(
>
> --
> 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
>
>

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

[Rafael Dohms]

On Thu, Jan 10, 2013 at 2:39 AM, Adam Harvey  wrote:

>
> So my dilemma is this: how do I voice this (without simply a drive-by
> -1 vote, which isn't really helpful either, and is overly discouraging
> to the people who've put a lot of work in to polish the feature up)
> without being shouted down for being unhelpful or uncivil?
>
>
In my humble opinion, if your only "argument" is a -1, the don't be part of
the discussion, but
rather be a vote when (and if) the RFC goes to a vote.

There are 2 moments to express yourself: the discussion, the vote.

In the discussion phase I believe opinion should be expressed with solid
concerns. Performance issues, bad syntax, is it relevant or not, etc.
A simple "i don't like it" does not add, so it can be ommited.

The voting is where you can simply say: i don't want this regardless of the
syntax
intent or how many unicorns it provides.

That is what i do.


-- 
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://wwwamsterdamphp.nl