2011/6/17 Stas Malyshev smalyshev@sugarcrm.com:
[snip]
- Make primitive type names reserved words (in case we ever want some form
of scalar typing or anything else with scalar types). Using them as
identifiers would return parse error for now. May have BC implications.
I am not sure it is a good idea to make them reserved words without a
clear reason for doing so.
I'm sure some projects have defined classes with those keywords in
some namespace (to ensure they wouldn't conflict with possible PHP
built-in stuff) like in:
namespace \Types {
class Int {
// ...
}
class Float {
// ...
}
class String {
// ...
}
// ...
}
Developer may have taken care of defining them in a specific
namespace, would it be possible to not break their application while
making them reserved keywords in the global namespace only?
I would be +1 if this could be done for the global namespace only.
However, -1 if this would break the usage of classes like \Types\Int,
\Types\String, ... would break.
Please, rethink your vote taking this into account. I don't think it
is required to hurry up on that decision while we still don't have a
clear proposition for scalar type hinting.
Cheers,
Patrick
[snip]
There's going to be a ton of code in the wild that will break if primitive
types become reserved words.
On Sun, Jul 10, 2011 at 11:41 AM, Patrick ALLAERT patrickallaert@php.netwrote:
2011/6/17 Stas Malyshev smalyshev@sugarcrm.com:
[snip]
- Make primitive type names reserved words (in case we ever want some
form
of scalar typing or anything else with scalar types). Using them as
identifiers would return parse error for now. May have BC implications.I am not sure it is a good idea to make them reserved words without a
clear reason for doing so.I'm sure some projects have defined classes with those keywords in
some namespace (to ensure they wouldn't conflict with possible PHP
built-in stuff) like in:namespace \Types {
class Int {
// ...
}
class Float {
// ...
}
class String {
// ...
}
// ...
}Developer may have taken care of defining them in a specific
namespace, would it be possible to not break their application while
making them reserved keywords in the global namespace only?I would be +1 if this could be done for the global namespace only.
However, -1 if this would break the usage of classes like \Types\Int,
\Types\String, ... would break.Please, rethink your vote taking this into account. I don't think it
is required to hurry up on that decision while we still don't have a
clear proposition for scalar type hinting.Cheers,
Patrick[snip]
Well, I generally think that PHP should be less strict about reserved
keywords. The number
of reserved keywords increases with every further release of PHP. For
example PHP 5.4
introduces "trait" and "insteadof". PHP 5.3 introduced even more. Every new
keyword PHP
introduces both breaks old code and reduces the naming possibilities for
classes and methods.
I don't think that it's possible to refrain from adding further keywords.
The language grows and
with it the list of keywords.
But I do think that it should be possible to prevent these additions from
breaking old code or
restricting userland naming.
E.g. Writing
class Evaluator {
public function eval() {
}
}
Does in no way create an ambiguity with the eval language construct PHP
implements.
But still PHP doesn't allow writing the above code. It would make sense to
allow the
use of the keyword in such situations. Actually PHP already does this in one
place:
The token after T_OPJECT_OPERATOR is never interpreted as a keyword. I.e.
one can
write $this->eval() (and define a magic __call method for 'eval').
I don't know whether this is actually possible, but I've at least already
seen a patch
(http://pear.php.net/~greg/smarter_lexer.patch.txt) for the methodname case
linked
from a feature request (https://bugs.php.net/bug.php?id=28261).
MfG Nikita
Hi!
I don't know whether this is actually possible, but I've at least
already seen a patch
(http://pear.php.net/~greg/smarter_lexer.patch.txt) for the methodname
case linked
from a feature request (https://bugs.php.net/bug.php?id=28261).
If this patch indeed works, I don't see why we couldn't add it. Needs to
be extensively checked, but if it works - why not?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
E.g. Writing
class Evaluator {
public function eval() {}}
Does in no way create an ambiguity with the eval language construct PHP
implements.
For a method this is correct. But for a normal function this is
different:
<?php
function eval() {
}
eval(); // will call the language construct
?>
And i consider it "strange" to allow different names for functions and
methods. And yes I'm aware that
$eval = 'eval'; $eval();
would call the function.
I fear consistency issues.
johannes
E.g. Writing
class Evaluator {
public function eval() {}}
Does in no way create an ambiguity with the eval language construct
PHP implements.For a method this is correct. But for a normal function this is
different:<?php
function eval() {
}
eval(); // will call the language construct
?>
But what about this?
namespace Foo
{
function eval($name)
{
echo $name;
}
eval('matthew');
}
The manual doesn't really differentiate between language constructs and
functions, and as such, I can see somebody reading the namespace section
of the manual and feeling this should be valid -- but currently, it
results in a parse error.
It seems to me we need a context-sensitive lexer.
And i consider it "strange" to allow different names for functions and
methods. And yes I'm aware that
$eval = 'eval'; $eval();
would call the function.I fear consistency issues.
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Hi!
I'm sure some projects have defined classes with those keywords in
some namespace (to ensure they wouldn't conflict with possible PHP
built-in stuff) like in:namespace \Types {
class Int {
// ...
}
class Float {
// ...
}
class String {
// ...
}
// ...
}
We probably can do it so String is OK, but string is not. But yes, if we
ever have scalar typing, it would conflict with such types I imagine.
But this may be a problem for whoever would venture to create that
patch, if it ever happens.
Developer may have taken care of defining them in a specific
namespace, would it be possible to not break their application while
making them reserved keywords in the global namespace only?
I don't think there's such thing in PHP as namespaced keywords. Keywords
are processed by the language parser, which knows next to nothing of
namespaces.
We could, maybe, prohibit creation of classes with names identical to
type names, which is different from making it reserved word, and on that
stage we know the full class name.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Developer may have taken care of defining them in a specific
namespace, would it be possible to not break their application while
making them reserved keywords in the global namespace only?I don't think there's such thing in PHP as namespaced keywords. Keywords
are processed by the language parser, which knows next to nothing of
namespaces.
We could, maybe, prohibit creation of classes with names identical to
type names, which is different from making it reserved word, and on that
stage we know the full class name.
I think that's a bad idea. The point of namespaces is to allow us to
override classes (and functions, and constants) within that namespace.
If I can't do this:
namespace Foo
{
class String
{
}
}
then I'd consider the implementation too restrictive.
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
On Mon, Jul 11, 2011 at 5:08 PM, Matthew Weier O'Phinney
weierophinney@php.net wrote:
Developer may have taken care of defining them in a specific
namespace, would it be possible to not break their application while
making them reserved keywords in the global namespace only?I don't think there's such thing in PHP as namespaced keywords. Keywords
are processed by the language parser, which knows next to nothing of
namespaces.
We could, maybe, prohibit creation of classes with names identical to
type names, which is different from making it reserved word, and on that
stage we know the full class name.I think that's a bad idea. The point of namespaces is to allow us to
override classes (and functions, and constants) within that namespace.
If I can't do this:namespace Foo
{
class String
{
}
}then I'd consider the implementation too restrictive.
the parser is a little bit dumb, and the namespaces isn't really first
class citizens in php AFAIK, so it's not a deliberate restriction imo,
just a technical, which could be solved.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
2011/7/11 Ferenc Kovacs tyra3l@gmail.com:
On Mon, Jul 11, 2011 at 5:08 PM, Matthew Weier O'Phinney
[snip]
I think that's a bad idea. The point of namespaces is to allow us to
override classes (and functions, and constants) within that namespace.
If I can't do this:namespace Foo
{
class String
{
}
}then I'd consider the implementation too restrictive.
This is exactly my concern.
the parser is a little bit dumb, and the namespaces isn't really first
class citizens in php AFAIK, so it's not a deliberate restriction imo,
just a technical, which could be solved.
The parser being dumb wouldn't be a reason to make code which works
fine on 5.3, break on 5.4 and then again working on 5.5 because of
words being keyworded for the sake of "a future implementation" which
doesn't explain whether it would break that kind of namespaced
classes.
Regards,
Patrick
Hi!
I'm sure some projects have defined classes with those keywords in
some namespace (to ensure they wouldn't conflict with possible PHP
built-in stuff) like in:namespace \Types {
class Int {
// ...
}
class Float {
// ...
}
class String {
// ...
}
// ...
}We probably can do it so String is OK, but string is not.
Are you suggesting to make class names case sensitive now? I don't think
that that's what you meant, but it clearly shows that the "probably can"
is "cannot" in your sentence above.
cheers,
Derick
hi,
As I could agree on this fact, I can't find any existing project
having int(eger), float&co as class, namespaced or not. Do you have
any example at hand?
Cheers,
2011/6/17 Stas Malyshev smalyshev@sugarcrm.com:
[snip]
- Make primitive type names reserved words (in case we ever want some form
of scalar typing or anything else with scalar types). Using them as
identifiers would return parse error for now. May have BC implications.I am not sure it is a good idea to make them reserved words without a
clear reason for doing so.I'm sure some projects have defined classes with those keywords in
some namespace (to ensure they wouldn't conflict with possible PHP
built-in stuff) like in:namespace \Types {
class Int {
// ...
}
class Float {
// ...
}
class String {
// ...
}
// ...
}Developer may have taken care of defining them in a specific
namespace, would it be possible to not break their application while
making them reserved keywords in the global namespace only?I would be +1 if this could be done for the global namespace only.
However, -1 if this would break the usage of classes like \Types\Int,
\Types\String, ... would break.Please, rethink your vote taking this into account. I don't think it
is required to hurry up on that decision while we still don't have a
clear proposition for scalar type hinting.Cheers,
Patrick[snip]
--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
As I could agree on this fact, I can't find any existing project
having int(eger), float&co as class, namespaced or not. Do you have
any example at hand?Cheers,
not too many though.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
ZF and ODM do it and inside namespace. We should be sure that these
cases still work, as NS exists for this exact purpose.
Cheers,
hi,
As I could agree on this fact, I can't find any existing project
having int(eger), float&co as class, namespaced or not. Do you have
any example at hand?Cheers,
not too many though.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Zitat von Ferenc Kovacs tyra3l@gmail.com:
hi,
As I could agree on this fact, I can't find any existing project
having int(eger), float&co as class, namespaced or not. Do you have
any example at hand?Cheers,
not too many though.
Try that for String and it reveals a different picture. Horde 3 used
that too FWIW.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
Zitat von Ferenc Kovacs tyra3l@gmail.com:
On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye pierre.php@gmail.com
wrote:hi,
As I could agree on this fact, I can't find any existing project
having int(eger), float&co as class, namespaced or not. Do you have
any example at hand?Cheers,
not too many though.
Try that for String and it reveals a different picture. Horde 3 used that
too FWIW.Jan.
Even the php5 versions of Horde? That's rather bad given the so strong
and loud warnings we gave about using common names w/o namespace, by
the time of the date problem.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Zitat von Pierre Joye pierre.php@gmail.com:
Zitat von Ferenc Kovacs tyra3l@gmail.com:
On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye pierre.php@gmail.com
wrote:hi,
As I could agree on this fact, I can't find any existing project
having int(eger), float&co as class, namespaced or not. Do you have
any example at hand?Cheers,
not too many though.
Try that for String and it reveals a different picture. Horde 3 used that
too FWIW.Jan.
Even the php5 versions of Horde? That's rather bad given the so strong
and loud warnings we gave about using common names w/o namespace, by
the time of the date problem.
No, of course not. That's why I didn't voice an opinion, I just found
it worth mentioning. Horde 3 users can stick with PHP 5.3, while Horde
4 users are not affected at all.
It's still used in a lot of other code though, see the github search.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
hi,
As of now I do not think we should allow this change, whether the RFC
is accepted or not does not matter as it will badly break BC. Unless
there is a patch allowing this change without affecting existing code
(main point being namespaced code working smoothly), this RFC should
be rejected.
Cheers,
2011/6/17 Stas Malyshev smalyshev@sugarcrm.com:
[snip]
- Make primitive type names reserved words (in case we ever want some form
of scalar typing or anything else with scalar types). Using them as
identifiers would return parse error for now. May have BC implications.I am not sure it is a good idea to make them reserved words without a
clear reason for doing so.I'm sure some projects have defined classes with those keywords in
some namespace (to ensure they wouldn't conflict with possible PHP
built-in stuff) like in:namespace \Types {
class Int {
// ...
}
class Float {
// ...
}
class String {
// ...
}
// ...
}Developer may have taken care of defining them in a specific
namespace, would it be possible to not break their application while
making them reserved keywords in the global namespace only?I would be +1 if this could be done for the global namespace only.
However, -1 if this would break the usage of classes like \Types\Int,
\Types\String, ... would break.Please, rethink your vote taking this into account. I don't think it
is required to hurry up on that decision while we still don't have a
clear proposition for scalar type hinting.Cheers,
Patrick[snip]
--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
Hi,
As of now I do not think we should allow this change, whether the RFC
is accepted or not does not matter as it will badly break BC. Unless
there is a patch allowing this change without affecting existing code
(main point being namespaced code working smoothly), this RFC should
be rejected.
With these new elements, I agree the fact that the RFC should be
rejected. But maybe we can add new magic methods, such as: __toBool(),
__toInt(), __toFloat() etc. User can use int(), float() etc. if he
needs/wants to, and we are always able to do same things (e.g. adding
future features).
Moreover, PHP has a dynamic typing system. Having tokens as reserved
keywords appears obviously logical to me, but why having type names as
reserved keywords? Sounds like we do not assume our “type position”.
That's why adding magic methods looks like a better way to solve this
problem.
Thougs?
Best regards.
PS: I cannot change my vote on https://wiki.php.net/todo/php54/vote, is
it a known issue?
2011/6/17 Stas Malyshevsmalyshev@sugarcrm.com:
[snip]
- Make primitive type names reserved words (in case we ever want some form
of scalar typing or anything else with scalar types). Using them as
identifiers would return parse error for now. May have BC implications.
I am not sure it is a good idea to make them reserved words without a
clear reason for doing so.I'm sure some projects have defined classes with those keywords in
some namespace (to ensure they wouldn't conflict with possible PHP
built-in stuff) like in:namespace \Types {
class Int {
// ...
}
class Float {
// ...
}
class String {
// ...
}
// ...
}Developer may have taken care of defining them in a specific
namespace, would it be possible to not break their application while
making them reserved keywords in the global namespace only?I would be +1 if this could be done for the global namespace only.
However, -1 if this would break the usage of classes like \Types\Int,
\Types\String, ... would break.Please, rethink your vote taking this into account. I don't think it
is required to hurry up on that decision while we still don't have a
clear proposition for scalar type hinting.Cheers,
Patrick[snip]
--
--
Ivan Enderlin
Developer of Hoa Framework
http://hoa.42/ or http://hoa-project.net/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
PS: I cannot change my vote on https://wiki.php.net/todo/php54/vote, is it a
known issue?
if you don't have @php.net account, or 'voting' group membership in
the wiki, then you cannot vote, or change your vote.
this change was made yesterday to fix the issue that the technical
restriction for the voting in the wiki isn't in pair with our accepted
voting RFC.
Ferenc Kovács
@Tyr43l - http://tyrael.hu
PS: I cannot change my vote on https://wiki.php.net/todo/php54/vote, is it a
known issue?if you don't have @php.net account, or 'voting' group membership in
the wiki, then you cannot vote, or change your vote.
this change was made yesterday to fix the issue that the technical
restriction for the voting in the wiki isn't in pair with our accepted
voting RFC.
And how can I join the “voting” group :-) ?
--
Ivan Enderlin
Developer of Hoa Framework
http://hoa.42/ or http://hoa-project.net/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
Hi,
As of now I do not think we should allow this change, whether the RFC is
accepted or not does not matter as it will badly break BC. Unless there
is a patch allowing this change without affecting existing code (main
point being namespaced code working smoothly), this RFC should be
rejected.
I agree with that. Perhaps the first step is to raise an E_NOTICE or
E_STRICT and in the next major release, the E_PARSE.
Cheers,
Bruno
hi,
As of now I do not think we should allow this change, whether the RFC
is accepted or not does not matter as it will badly break BC. Unless
there is a patch allowing this change without affecting existing code
(main point being namespaced code working smoothly), this RFC should
be rejected.Cheers,
I think this change has too much of an impact on backward compatibility.
As long as we don't have a concrete implementation, I think we should
let string, int not be reserved words. Argumentes were already presented.
ps.: Pierre you might want to consider changing your vote in the wiki
hi,
As of now I do not think we should allow this change, whether the RFC
is accepted or not does not matter as it will badly break BC. Unless
there is a patch allowing this change without affecting existing code
(main point being namespaced code working smoothly), this RFC should
be rejected.Cheers,
I think this change has too much of an impact on backward compatibility.
As long as we don't have a concrete implementation, I think we should
let string, int not be reserved words. Argumentes were already presented.ps.: Pierre you might want to consider changing your vote in the wiki
This thread is an excellent example why attempting to reach consensus
by discussing things is important.
Voting should be considered as an desperate last resort, not the
primary mechanism.
http://producingoss.com/en/consensus-democracy.html has several very
related points.
-Hannes
Hi!
This thread is an excellent example why attempting to reach consensus
by discussing things is important.
Voting should be considered as an desperate last resort, not the
primary mechanism.http://producingoss.com/en/consensus-democracy.html has several very
related points.
That was the idea, but the problem is people ignore discussions on the
list and only wake up when vote is to be closed soon :)
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi,
As of now I do not think we should allow this change, whether the RFC
is accepted or not does not matter as it will badly break BC. Unless
there is a patch allowing this change without affecting existing code
(main point being namespaced code working smoothly), this RFC should
be rejected.Cheers,
I think this change has too much of an impact on backward compatibility.
As long as we don't have a concrete implementation, I think we should
let string, int not be reserved words. Argumentes were already presented.ps.: Pierre you might want to consider changing your vote in the wiki
This thread is an excellent example why attempting to reach consensus
by discussing things is important.
Voting should be considered as an desperate last resort, not the
primary mechanism.http://producingoss.com/en/consensus-democracy.html has several very
related points.
And each topic deserves its own thread, whereas this [original] thread lumped 10 separate topics together.
Regards,
Philip
hi Hannes,
On Wed, Jul 13, 2011 at 6:35 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
hi,
As of now I do not think we should allow this change, whether the RFC
is accepted or not does not matter as it will badly break BC. Unless
there is a patch allowing this change without affecting existing code
(main point being namespaced code working smoothly), this RFC should
be rejected.Cheers,
I think this change has too much of an impact on backward compatibility.
As long as we don't have a concrete implementation, I think we should
let string, int not be reserved words. Argumentes were already presented.ps.: Pierre you might want to consider changing your vote in the wiki
This thread is an excellent example why attempting to reach consensus
by discussing things is important.
Voting should be considered as an desperate last resort, not the
primary mechanism.http://producingoss.com/en/consensus-democracy.html has several very
related points.
I disagree and this exact issue shows that the voting and controlling
is actually working well, very well. As it is covered by the two
recently adopted RFCs.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I disagree and this exact issue shows that the voting and controlling
is actually working well, very well. As it is covered by the two
recently adopted RFCs.
I'm not sure how you come to the conclusion that it is working well.
This particular change is clearly not feasible for 5.4, yet the votes
are 37-19 for doing it right now.
-Rasmus
I disagree and this exact issue shows that the voting and controlling
is actually working well, very well. As it is covered by the two
recently adopted RFCs.I'm not sure how you come to the conclusion that it is working well.
This particular change is clearly not feasible for 5.4, yet the votes
are 37-19 for doing it right now.
Maybe read my reply in this exact thread?
I said that due the BC problem, discovered or discussed later, forces
us to reject this RFC.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I disagree and this exact issue shows that the voting and controlling
is actually working well, very well. As it is covered by the two
recently adopted RFCs.I'm not sure how you come to the conclusion that it is working well.
This particular change is clearly not feasible for 5.4, yet the votes
are 37-19 for doing it right now.Maybe read my reply in this exact thread?
I said that due the BC problem, discovered or discussed later, forces
us to reject this RFC.
What do you mean discovered or discussed later? Anybody who bothered to
read the RFC should have seen the BC problem. It's not like it was
hiding in small letters somewhere.
And most of the other votes are unanimous which make them rather
pointless as well.
-Rasmus
I disagree and this exact issue shows that the voting and controlling
is actually working well, very well. As it is covered by the two
recently adopted RFCs.I'm not sure how you come to the conclusion that it is working well.
This particular change is clearly not feasible for 5.4, yet the votes
are 37-19 for doing it right now.Maybe read my reply in this exact thread?
I said that due the BC problem, discovered or discussed later, forces
us to reject this RFC.What do you mean discovered or discussed later? Anybody who bothered to
read the RFC should have seen the BC problem. It's not like it was
hiding in small letters somewhere.
We have some issues here. One is that I can't find the RFC for this
proposal. Many of these votes are made out of the 5.4 todos instead of
having clear and obvious (as you wish) RFCs. That was a mistake. But
that's a new thing, we are learning.
However, while making these primitives keywords sounded like a good
and easy step, not being able to use them inside a namespace is a not
acceptable BC break. It was also not obvious that NS won't be
supported.
And most of the other votes are unanimous which make them rather
pointless as well.
Are you saying that widely approved thing are pointless or we could
have foreseen the results for each of them? Better to have a vote and
got a massive support than nothing and sit in the middle of nowhere
forever.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Are you saying that widely approved thing are pointless or we could
have foreseen the results for each of them? Better to have a vote and
got a massive support than nothing and sit in the middle of nowhere
forever.
I'm saying that many of these in the past were handled by a, "Hey guys,
any objections to adding E_STRICT to E_ALL in 5.4?" email which would
get a couple of, "go for it" replies and no objections, followed by the
change being committed. To me the voting is only needed when we have
trouble reaching a quick consensus and not for every little thing.
-Rasmus
Are you saying that widely approved thing are pointless or we could
have foreseen the results for each of them? Better to have a vote and
got a massive support than nothing and sit in the middle of nowhere
forever.I'm saying that many of these in the past were handled by a, "Hey guys,
any objections to addingE_STRICTtoE_ALLin 5.4?" email which would
get a couple of, "go for it" replies and no objections, followed by the
change being committed. To me the voting is only needed when we have
trouble reaching a quick consensus and not for every little thing.
Yes, got it, they were rhetorical questions :). However doing it this
way spares us time in the long run. While one or another proposal
could get large and immediate adoption, it makes the whole thing
clearer for the developers not following internals@ daily or to our
users.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Are you saying that widely approved thing are pointless or we could
have foreseen the results for each of them? Better to have a vote and
got a massive support than nothing and sit in the middle of nowhere
forever.I'm saying that many of these in the past were handled by a, "Hey guys,
any objections to addingE_STRICTtoE_ALLin 5.4?" email which would
get a couple of, "go for it" replies and no objections, followed by the
change being committed. To me the voting is only needed when we have
trouble reaching a quick consensus and not for every little thing.Yes, got it, they were rhetorical questions :). However doing it this
way spares us time in the long run. While one or another proposal
could get large and immediate adoption, it makes the whole thing
clearer for the developers not following internals@ daily or to our
users.
Right, but these folks that don't follow the discussions are the same 37
people who voted for the Primitives change. How is that helpful?
I think a vote should be a big deal. Anything that comes up for a vote
should have a healthy discussion and an extremely well-fleshed out RFC
which includes both sides of the argument culled from the healthy
discussion. And the voting page should heavily encourage people to
actually read the RFC in its entirety before voting.
-Rasmus
Right, but these folks that don't follow the discussions are the same 37
people who voted for the Primitives change. How is that helpful?
Many of the votes there are not from developers. We have explained
what happened earlier this week. I don't think it is necessary to
discuss this problem again here as it is fixed (Tyrael implemented the
voting ACL and is now used).
I think a vote should be a big deal. Anything that comes up for a vote
should have a healthy discussion and an extremely well-fleshed out RFC
which includes both sides of the argument culled from the healthy
discussion. And the voting page should heavily encourage people to
actually read the RFC in its entirety before voting.
Fully agreed and that's what the voting RFC says as well. And why I
said that simple todos should not have been submitted to votes except
those requiring RFC due to their complexity or whatever else.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
ah forgot to mention that indeed not all todos should have be done via
a RFC, that would not help us, not at all. But the primitive one, for
example, must have one.
Are you saying that widely approved thing are pointless or we could
have foreseen the results for each of them? Better to have a vote and
got a massive support than nothing and sit in the middle of nowhere
forever.I'm saying that many of these in the past were handled by a, "Hey guys,
any objections to addingE_STRICTtoE_ALLin 5.4?" email which would
get a couple of, "go for it" replies and no objections, followed by the
change being committed. To me the voting is only needed when we have
trouble reaching a quick consensus and not for every little thing.-Rasmus
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org