On Thu, Jan 10, 2013 at 2:39 AM, Adam Harvey ahar...@php.net 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
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
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
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
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
On Thu, Jan 10, 2013 at 10:17 AM, Nate Tuganov i...@cloudmill.ru 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
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 -.-.
2013/1/10 Rafael Dohms lis...@rafaeldohms.com.br
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
On Thu, Jan 10, 2013 at 8:29 AM, J. Adams zardozro...@gmail.com 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/**
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
On Thu, Jan 10, 2013 at 10:17 AM, Nate Tuganov i...@cloudmill.ru 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
On Thu, Jan 10, 2013 at 11:34 AM, Amaury Bouchard ama...@amaury.net 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
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
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
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
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
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
Hi!
On 9 January 2013 23:45, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Thu, 03 Jan 2013 11:40:31 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt
wrote:
The algorithm behaves very poorly in this case because at each position
of the text, all the substrings starting there and with size
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
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.
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?
--
Stas,
On Thu, Jan 10, 2013 at 3:16 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
On Thu, Jan 10, 2013 at 10:42 PM, Anthony Ferrara ircmax...@gmail.comwrote:
Stas,
On Thu, Jan 10, 2013 at 3:16 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
Sure. Here you go. Here are two examples:
http://www.python.org/dev/peps/pep-0020/
This is a nice text, but
On Tue, Jan 8, 2013 at 7:03 PM, Steve Clay st...@mrclay.org 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
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
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
-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
On Sat, Jan 5, 2013 at 4:25 AM, Clint Priest cpri...@zerocue.com 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
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 l...@b1-systems.de כתב/ה:
On 01/09/2013 02:45 PM, Gustavo Lopes wrote:
On Thu, 03 Jan 2013 11:40:31 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt
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
On Thu, Jan 10, 2013 at 11:11 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
On Thu, Jan 10, 2013 at 2:59 PM, Stas Malyshev smalys...@sugarcrm.com 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
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
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
Nikita,
2013/1/10 Nikita Popov nikita@gmail.com
On Tue, Jan 8, 2013 at 7:03 PM, Steve Clay st...@mrclay.org 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
On Fri, Jan 11, 2013 at 1:03 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
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,
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 { ... }
}
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,
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,
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
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.
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
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 cpri...@zerocue.com wrote:
Oooh, a rewrite? Can we write it in an object oriented language this
time? Please? Pretty Please???
:D
On
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
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
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
Hi Stas,
I think you hit a nail here.
Am 10.01.2013 um 21:36 schrieb Stas Malyshev smalys...@sugarcrm.com:
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
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
49 matches
Mail list logo
