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
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
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!
> 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!
> 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 ReflectionNam
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,
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 say
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.
R
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 req
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'
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,
Refl
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 { ... }
}
pu
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,
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 re
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 DateT
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'
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
> nec
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 p
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 i
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 p
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
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 sol
-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?
>
I
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
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 u
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 proper
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
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 annotation
>> 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?
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. Ex
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!
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
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 rele
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 co
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/
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 t
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
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 :
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
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 performanc
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-pa
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 sh
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 WORDPRE
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 li
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 be
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
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 inste
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
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
49 matches
Mail list logo
