Re: [PHP-DEV] Re: Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")
> > Then why not put the base class in the namespace of which it is a base class > for? > Locations source PHP file is the same as in namespace. App/RestException.php App/RestException/NotFound.php App/RestException/BadRequest.php I did refactoring code, without group use: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")
> On 24 Jul 2015, at 2:33 am, "S.A.N" wrote:
>
> 2015-07-23 18:10 GMT+03:00 Marcio Almada :
>> Hi, you replied to the wrong thread ;)
>>
>> 2015-07-22 19:38 GMT-03:00 S.A.N :
>>> I am satisfied, the possibility of group declarations, but the that lack:
>>>
>>> >>
>>> use App\RestException\ // name "RestException", not imported to
>>> current namespace :(
>>> {
>>>Gone,
>>>NotFound,
>>>BadRequest
>>> };
>>>
>>> ?>
>>>
>>> Unfortunately have to write so:
>>>
>>> >>
>>> use App\RestException;
>>> use App\RestException\{Gone, NotFound, BadRequest};
>>>
>>> ?>
>>>
>>> It looks ugly and very strange.
>>
>> There is nothing strange on it (except, possibly, the trailing `\`
>> which was discussed to death and voted).
>>
>> Even if we had no trailing '\' it wouldn't make any sense to import
>> "App\RestException" when "use App\RestException{Gone, NotFound,
>> BadRequest};" is used.
>>
>>> My proposition, the imported end name, if end of without slash.
>>>
>>> Like this:
>>>
>>> >>
>>> use App\RestException
>>> {
>>>Gone,
>>>NotFound,
>>>BadRequest
>>> };
>>>
>>> echo RestException::class; // App\RestException
>>>
>>> ?>
>>
>> Importing from within a namespace is not the same thing as importing a
>> class. I'd be against it.
>>
>> My 2 cents: why do you have "RestException" with "Exception" suffix
>> and then don't have the same suffix on the other exception names? This
>> unpredictable exception hierarchy is the "ugly" part and subtle
>> alternative syntax won't make it better, IMMO.
>>
>> Marcio
>
> RestException is the base class for classes Gone, NotFound, BadRequest...
> He needed to catch all RestExceptions class.
>
> We do not use suffixes for names of exception classes, simple clear
> named classes of exceptions, this is our agreement.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Then why not put the base class in the namespace of which it is a base class
for?
Cheers,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")
2015-07-23 18:10 GMT+03:00 Marcio Almada :
> Hi, you replied to the wrong thread ;)
>
> 2015-07-22 19:38 GMT-03:00 S.A.N :
>> I am satisfied, the possibility of group declarations, but the that lack:
>>
>> >
>> use App\RestException\ // name "RestException", not imported to
>> current namespace :(
>> {
>> Gone,
>> NotFound,
>> BadRequest
>> };
>>
>> ?>
>>
>> Unfortunately have to write so:
>>
>> >
>> use App\RestException;
>> use App\RestException\{Gone, NotFound, BadRequest};
>>
>> ?>
>>
>> It looks ugly and very strange.
>
> There is nothing strange on it (except, possibly, the trailing `\`
> which was discussed to death and voted).
>
> Even if we had no trailing '\' it wouldn't make any sense to import
> "App\RestException" when "use App\RestException{Gone, NotFound,
> BadRequest};" is used.
>
>> My proposition, the imported end name, if end of without slash.
>>
>> Like this:
>>
>> >
>> use App\RestException
>> {
>> Gone,
>> NotFound,
>> BadRequest
>> };
>>
>> echo RestException::class; // App\RestException
>>
>> ?>
>
> Importing from within a namespace is not the same thing as importing a
> class. I'd be against it.
>
> My 2 cents: why do you have "RestException" with "Exception" suffix
> and then don't have the same suffix on the other exception names? This
> unpredictable exception hierarchy is the "ugly" part and subtle
> alternative syntax won't make it better, IMMO.
>
> Marcio
RestException is the base class for classes Gone, NotFound, BadRequest...
He needed to catch all RestExceptions class.
We do not use suffixes for names of exception classes, simple clear
named classes of exceptions, this is our agreement.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")
Hi, you replied to the wrong thread ;)
2015-07-22 19:38 GMT-03:00 S.A.N :
> I am satisfied, the possibility of group declarations, but the that lack:
>
>
> use App\RestException\ // name "RestException", not imported to
> current namespace :(
> {
> Gone,
> NotFound,
> BadRequest
> };
>
> ?>
>
> Unfortunately have to write so:
>
>
> use App\RestException;
> use App\RestException\{Gone, NotFound, BadRequest};
>
> ?>
>
> It looks ugly and very strange.
There is nothing strange on it (except, possibly, the trailing `\`
which was discussed to death and voted).
Even if we had no trailing '\' it wouldn't make any sense to import
"App\RestException" when "use App\RestException{Gone, NotFound,
BadRequest};" is used.
> My proposition, the imported end name, if end of without slash.
>
> Like this:
>
>
> use App\RestException
> {
> Gone,
> NotFound,
> BadRequest
> };
>
> echo RestException::class; // App\RestException
>
> ?>
Importing from within a namespace is not the same thing as importing a
class. I'd be against it.
My 2 cents: why do you have "RestException" with "Exception" suffix
and then don't have the same suffix on the other exception names? This
unpredictable exception hierarchy is the "ugly" part and subtle
alternative syntax won't make it better, IMMO.
Marcio
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")
I am satisfied, the possibility of group declarations, but the that lack: Unfortunately have to write so: It looks ugly and very strange. My proposition, the imported end name, if end of without slash. Like this: 2015-03-11 11:08 GMT+02:00 Patrick ALLAERT : > Le mar. 10 mars 2015 à 19:29, Marcio Almada a > écrit : > >> Hi, >> >> 2015-03-10 11:39 GMT-03:00 Patrick ALLAERT : >> >> Hello, >>> >>> Le ven. 6 mars 2015 à 00:44, Marcio Almada a >>> écrit : You are right about this. I'll setup a yes/no vote + a vote to decide between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me this is just a detail but maybe it's very important to others, so better to let each voter decide upon it. >>> >>> In case of language changes, shouldn't the 2/3 of majority be required at >>> any levels? >>> >>> >> I don't think it's possible. What would happen if the yes/no vote passes >> but the secondary vote doesn't reach 2/3 for some option? This would be a >> weird situation. >> > > Pretty simple actually: it would simply not pass because it wouldn't gather > enough support. > > Discuss the options, see what gather the most support and the better > reasonings and then suggest that the RFC "yes" vote means A, B or C while > summarizing the reasons of the choice for it in the RFC itself. > > A language change vote requiring 2/3 majority on a Yes/No and a simple > majority in an option basically means not requiring 2/3 at all, but 50% > (with 2 options) at most! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")
Le mar. 10 mars 2015 à 19:29, Marcio Almada a écrit : > Hi, > > 2015-03-10 11:39 GMT-03:00 Patrick ALLAERT : > > Hello, >> >> Le ven. 6 mars 2015 à 00:44, Marcio Almada a >> écrit : >>> >>> You are right about this. I'll setup a yes/no vote + a vote to decide >>> between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me >>> this >>> is just a detail but maybe it's very important to others, so better to >>> let >>> each voter decide upon it. >>> >> >> In case of language changes, shouldn't the 2/3 of majority be required at >> any levels? >> >> > I don't think it's possible. What would happen if the yes/no vote passes > but the secondary vote doesn't reach 2/3 for some option? This would be a > weird situation. > Pretty simple actually: it would simply not pass because it wouldn't gather enough support. Discuss the options, see what gather the most support and the better reasonings and then suggest that the RFC "yes" vote means A, B or C while summarizing the reasons of the choice for it in the RFC itself. A language change vote requiring 2/3 majority on a Yes/No and a simple majority in an option basically means not requiring 2/3 at all, but 50% (with 2 options) at most!
Re: [PHP-DEV] Re: Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")
On 3/10/15 1:29 PM, Marcio Almada wrote: I think we should do some effort to discuss and discard as much options as possible so we can have max 2 options or maybe eliminate the secondary voting at all (which is the perfect scenario IMMO), but this requires a good absolute number of opinions. If for some reason more than a binary question is necessary, at least go for instant-runoff style voting as that can represent "if not X, then Y is at least tolerable" better than any mechanism currently in use in Internals. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")
Hi, 2015-03-10 11:39 GMT-03:00 Patrick ALLAERT : > Hello, > > Le ven. 6 mars 2015 à 00:44, Marcio Almada a > écrit : >> >> You are right about this. I'll setup a yes/no vote + a vote to decide >> between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me this >> is just a detail but maybe it's very important to others, so better to let >> each voter decide upon it. >> > > In case of language changes, shouldn't the 2/3 of majority be required at > any levels? > > I don't think it's possible. What would happen if the yes/no vote passes but the secondary vote doesn't reach 2/3 for some option? This would be a weird situation. > In situations like: > > Main feature: No/Yes > Option: A, B or C > > My gut feeling is that it would be better to rally a 2/3 majority of > people behind one of: > No / Yes (A) / Yes (B) / Yes (C) > in order to not dilute the importance of language changes. > > It would prevent accepting an important change where a lot of people > agrees on a general idea but have strong opinions/arguments on > implementation/details. > > Cheers, > Patrick > I think we should do some effort to discuss and discard as much options as possible so we can have max 2 options or maybe eliminate the secondary voting at all (which is the perfect scenario IMMO), but this requires a good absolute number of opinions.
