>
> 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/u
> 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\
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 :
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
> }
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,
On 16/03/15 08:51, Marco Pivetta wrote:
> On 16 March 2015 at 08:48, Lester Caine wrote:
>
>> > The problem here is simply that just what error's are enabled and
>> > disabled is getting more difficult to decide? If when moving from a
>> > currently clean environment which has every error display
On 16 March 2015 at 08:48, Lester Caine wrote:
> The problem here is simply that just what error's are enabled and
> disabled is getting more difficult to decide? If when moving from a
> currently clean environment which has every error displayed and only
> shows something when any problem arises
On 16/03/15 03:29, Yasuo Ohgaki wrote:
>
> I agree partly. It does not provide any additional feature.
> However, it gives users ability to detect bugs. It's important gain for
> users also.
>
> Wrong code should be fixed anyway. The RFC could be more old code friendly
> if E_DEPECATED is used.
Hi Stas,
On Mon, Mar 16, 2015 at 7:41 AM, Stanislav Malyshev
wrote:
> > The section about '"Flexible" Interface Implementations' mentions the
> > interface as an 'an acceptable “PHPism”'.
> >
> > This is not just an "acceptable PHPism", it's a "life saving PHPism".
> /.../
> > Getting this chang
Hi!
> The section about '"Flexible" Interface Implementations' mentions the
> interface as an 'an acceptable “PHPism”'.
>
> This is not just an "acceptable PHPism", it's a "life saving PHPism".
/.../
> Getting this change into PHP7 would mean having a major part of the
> framework community havin
Hi Marcio/internals,
I just went through the RFC again (didn't check the discussion since our
last chat about it in Room 11).
The section about '"Flexible" Interface Implementations' mentions the
interface as an 'an acceptable “PHPism”'.
This is not just an "acceptable PHPism", it's a "life savi
Hi
2015-03-13 6:02 GMT-03:00 Patrick ALLAERT :
> Le mer. 11 mars 2015 à 22:44, Marcio Almada a
> écrit :
>
>> 2015-03-11 6:27 GMT-03:00 Lester Caine :
>>
>> > On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote:
>>
>> > Most of the examples being shown are examples of simple bad program
Le ven. 13 mars 2015 à 14:39, Lester Caine a écrit :
> On 13/03/15 09:02, Patrick ALLAERT wrote:
> > It also depends on your perception of E_STRICT. This level has been
> > introduced in 5.0 without being part of E_ALL in order to, among other
> > things, avoid too much pain in the *** while migr
On 13/03/15 09:02, Patrick ALLAERT wrote:
> It also depends on your perception of E_STRICT. This level has been
> introduced in 5.0 without being part of E_ALL in order to, among other
> things, avoid too much pain in the *** while migrating from 4.x to 5.x.
> As of 5.4, E_ALL contains E_STRICT and
Le mer. 11 mars 2015 à 22:44, Marcio Almada a
écrit :
> 2015-03-11 6:27 GMT-03:00 Lester Caine :
>
> > On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote:
>
> > Most of the examples being shown are examples of simple bad programming
> > practice that needs fixing anyway, and I would exp
Le mar. 10 mars 2015 à 21:04, Marcio Almada a
écrit :
>
>
> 2015-03-10 12:31 GMT-03:00 Patrick ALLAERT :
>
>> Hello,
>>
>> Le lun. 2 mars 2015 à 00:03, Marcio Almada a
>> écrit :
>>
>>
>> I'm globally +0.5, however I have some concerns:
>>
>> What about constructors?
>>
>> Children classes may
2015-03-10 12:31 GMT-03:00 Patrick ALLAERT :
> Hello,
>
> Le lun. 2 mars 2015 à 00:03, Marcio Almada a
> écrit :
>
>
> I'm globally +0.5, however I have some concerns:
>
> What about constructors?
>
> Children classes may have a bigger number of arguments for their ctors
> than their parents. Ev
On Tue, 10 Mar 2015, Patrick ALLAERT wrote:
> 2015-03-10 16:02 GMT+01:00 Anthony Ferrara :
> >
> > Can we please come down to a single RFC, with a single vote yes/no?
> > It's easier to understand, easier to manage and has less possibility
> > of gaming.
>
> That is much more stricter than my tho
On 10 March 2015 at 15:02, Anthony Ferrara wrote:
>
> Can we please come down to a single RFC, with a single vote yes/no?
> It's easier to understand, easier to manage and has less possibility
> of gaming.
While I generally agree, in the case where there is a small detail
that needs to be addres
Hi
2015-03-11 6:50 GMT-03:00 Patrick ALLAERT :
> Le mar. 10 mars 2015 à 21:04, Marcio Almada a
> écrit :
>
>>
>>
>> 2015-03-10 12:31 GMT-03:00 Patrick ALLAERT :
>>
>>> Hello,
>>>
>>> Le lun. 2 mars 2015 à 00:03, Marcio Almada a
>>> écrit :
>>>
>>>
>>> I'm globally +0.5, however I have some con
2015-03-11 6:27 GMT-03:00 Lester Caine :
> On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote:
> >>> BTW, the current PHP silent behavior should be considered even more
> >>> > > confusing otherwise we
> >>> > > wouldn't have these measurements:
> >>> > >
> >>> > >
> https://wiki.php.net
On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote:
>>> BTW, the current PHP silent behavior should be considered even more
>>> > > confusing otherwise we
>>> > > wouldn't have these measurements:
>>> > >
>>> > > https://wiki.php.net/rfc/strict_argcount#bc_breaks_on_the_real_world
>> >
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 consisten
Hi Stas,
> Stanislav Malyshev hat am 11. März 2015 um 05:49
> geschrieben:
>
>
> Hi!
>
> > related to the proposed RFC. *But* after some heuristics it was
> > noticeable that most warnings had a common cause. I parsed the output
>
> It doesn't matter if it has common cause or not. If I have a
Hi
2015-03-11 1:49 GMT-03:00 Stanislav Malyshev :
> Hi!
>
> > related to the proposed RFC. *But* after some heuristics it was
> > noticeable that most warnings had a common cause. I parsed the output
>
> It doesn't matter if it has common cause or not. If I have a system of
> Wordpress-like size,
Hi!
> related to the proposed RFC. *But* after some heuristics it was
> noticeable that most warnings had a common cause. I parsed the output
It doesn't matter if it has common cause or not. If I have a system of
Wordpress-like size, I'm bound to get a lot of failures, that's what it
is telling m
Hi,
2015-03-10 21:31 GMT-03:00 Stanislav Malyshev :
> Hi!
>
> >- Even if you already read the RFC in the past, read it again now.
> >- Don't claim **possible** massive BC breaks before read the
> >measurements already done. No matter how seasoned you are with PHP,
> real
> >number
Hi!
>- Even if you already read the RFC in the past, read it again now.
>- Don't claim **possible** massive BC breaks before read the
>measurements already done. No matter how seasoned you are with PHP, real
>numbers matter most than assumptions. Your measurements are welcome too.
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.
I
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 m
Hi,
2015-03-10 12:45 GMT-03:00 Dan Ackroyd :
> On 10 March 2015 at 15:02, Anthony Ferrara wrote:
> >
> > Can we please come down to a single RFC, with a single vote yes/no?
> > It's easier to understand, easier to manage and has less possibility
> > of gaming.
>
>
> While I generally agree, in t
2015-03-10 13:52 GMT-03:00 Anthony Ferrara :
> Dan,
>
> On Tue, Mar 10, 2015 at 11:45 AM, Dan Ackroyd
> wrote:
> > On 10 March 2015 at 15:02, Anthony Ferrara wrote:
> >>
> >> Can we please come down to a single RFC, with a single vote yes/no?
> >> It's easier to understand, easier to manage and
Patrick,
My viewpoint is that options in an RFC are dangerous. I would much
rather have a single RFC, with a single vote (yes/no). I think we
should be discouraging the options as much as possible.
The reason is simple: an RFC should be an encapsulated idea, not a
menu of options. The author shou
Dan,
On Tue, Mar 10, 2015 at 11:45 AM, Dan Ackroyd wrote:
> On 10 March 2015 at 15:02, Anthony Ferrara wrote:
>>
>> Can we please come down to a single RFC, with a single vote yes/no?
>> It's easier to understand, easier to manage and has less possibility
>> of gaming.
>
>
> While I generally ag
Hello,
Le lun. 2 mars 2015 à 00:03, Marcio Almada a écrit :
Hi, internals
>
> I'm moving the "Strict Argument Count" RFC into discussion phase:
>
> RFC: https://wiki.php.net/rfc/strict_argcount
> PR: https://github.com/php/php-src/pull/1108
>
> Many different opinions were collected during resea
2015-03-10 16:02 GMT+01:00 Anthony Ferrara :
> Patrick,
>
> My viewpoint is that options in an RFC are dangerous. I would much
> rather have a single RFC, with a single vote (yes/no). I think we
> should be discouraging the options as much as possible.
>
> The reason is simple: an RFC should be an
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 vo
Hi,
This is a remainder that the voting for the "Strict Argument Count" RFC is
scheduled to start on March 14th, so we still have this week for discussion
and it's still a good time to give feedback.
Thanks,
Márcio
2015-03-01 20:02 GMT-03:00 Marcio Almada :
> Hi, internals
>
> I'm moving the "
Hi,
2015-03-05 20:08 GMT-03:00 Yasuo Ohgaki :
> Hi Marcio,
>
> On Fri, Mar 6, 2015 at 6:36 AM, Marcio Almada
> wrote:
>
>> It would be nothing new or weird. It's just a simple compile time check.
>> We already "inspect" code in many other situations while compiling and a
>> lot of behaviors duri
Hi Marcio,
On Fri, Mar 6, 2015 at 6:36 AM, Marcio Almada wrote:
> It would be nothing new or weird. It's just a simple compile time check.
> We already "inspect" code in many other situations while compiling and a
> lot of behaviors during execution already depend on compile time checks. I
> don
Hi,
2015-03-04 21:51 GMT-03:00 Yasuo Ohgaki :
>
> I don't think we need to deprecate func_get_args(). We may have
>
> function f($a, ...) {
> var_dump(func_get_args());
> }
>
> f(1,2,3);
> ?>
>
> "...$a" packs arguments. Using "..." as variable parameter indication may
> be allowed.
> Strictl
Hi Marcio,
On Thu, Mar 5, 2015 at 4:07 AM, Marcio Almada wrote:
> 2015-03-03 16:48 GMT-03:00 Yasuo Ohgaki :
>
>> Hi Marcio,
>>
>>
> I understand your reasons. Compatibility is important, but detecting
>> function body contents and
>> suppressing errors by engine is too hacky. Raising E_DEPRECAT
Hi,
2015-03-03 16:48 GMT-03:00 Yasuo Ohgaki :
> Hi Marcio,
>
>
I understand your reasons. Compatibility is important, but detecting
> function body contents and
> suppressing errors by engine is too hacky. Raising E_DEPRECATE/E_STRICT by
> function definition seems
> the way to go. IMO.
>
>
Just
Hi Marcio,
On Mon, Mar 2, 2015 at 3:07 PM, Marcio Almada wrote:
> 2015-03-02 1:43 GMT-03:00 Yasuo Ohgaki :
>
>> Hi Marcio,
>>
>> On Mon, Mar 2, 2015 at 8:02 AM, Marcio Almada
>> wrote:
>>
>> I like the idea.
>>
>> /** fn expects a variable-length argument lists */
>> function fn($arg) {
>>
Hi Yasuo,
2015-03-02 1:43 GMT-03:00 Yasuo Ohgaki :
> Hi Marcio,
>
> On Mon, Mar 2, 2015 at 8:02 AM, Marcio Almada
> wrote:
>
> I like the idea.
>
> /** fn expects a variable-length argument lists */
> function fn($arg) {
> $arg = func_get_arg();
> $args = func_get_args();
> }
>
> fn(1);
Hi Marcio,
On Mon, Mar 2, 2015 at 8:02 AM, Marcio Almada wrote:
> I'm moving the "Strict Argument Count" RFC into discussion phase:
>
> RFC: https://wiki.php.net/rfc/strict_argcount
> PR: https://github.com/php/php-src/pull/1108
>
> Many different opinions were collected during research phase an
46 matches
Mail list logo
