Hi,
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
> > I would like to propose that namespaces, functions, and classes become
> > case-sensitive (constants are already case-sensitive). Actually, I never
> > understood why they are case-insensitive. Even if the per
Hi all,
On Sun, Dec 21, 2014 at 7:01 AM, F & N Laupretre
wrote:
> I don't know if this was discussed before. So, tell me what you think
> before
> I write an RFC.
>
>
>
> I would like to propose that namespaces, functions, and classes become
> case-sensitive (constants are already case-sensitive
On Dec 26, 2014 4:58 AM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > At the very least that sounds like a less intrusive step, as methods and
> > classes are usually already written "correctly".
>
> To me, it sounds like needless nuisance - the code works, but wastes
> time to produce warnings that
Hi!
> At the very least that sounds like a less intrusive step, as methods and
> classes are usually already written "correctly".
To me, it sounds like needless nuisance - the code works, but wastes
time to produce warnings that nobody reads. If your have a code that
relies on autoloaders and cas
On Dec 25, 2014 7:08 PM, "Nikita Popov" wrote:
> May I recommend to only target class and class-like names for an initial
RFC? Those have the strongest argument in favor of case-sensitivity given
how current autoloader implementations work - essentially the
case-insensitivity doesn't properly wor
On Thu, Dec 25, 2014 at 4:40 AM, François Laupretre
wrote:
> > > De : Pierre Joye [mailto:pierre@gmail.com]
> >
> > > Anyone dying while waiting to see PHP having case sensitive symbols
> > > handling should go ahead with a RFC.
>
> For those interested, I just created a PR to raise an E_STRI
On Thu, Dec 25, 2014 at 10:18:13PM +1100, Pierre Joye wrote:
> Forgot reply all? :)
Yes - thanks. Reformatted:
On Thu, Dec 25, 2014 at 09:53:11PM +1100, Pierre Joye wrote:
> I do not see a reason why some code having ran out of the box for more
> than a decade should be changed for 7 for purely
On Thu, Dec 25, 2014 at 9:05 PM, Alain Williams wrote:
> On Thu, Dec 25, 2014 at 04:40:09AM +0100, François Laupretre wrote:
>
>> > He will also have to deal with
>> > file ops while being at it. Should they remain case insensitive? Do
>> > manual checks to match the path actually being requested
On Thu, Dec 25, 2014 at 04:40:09AM +0100, François Laupretre wrote:
> > He will also have to deal with
> > file ops while being at it. Should they remain case insensitive? Do
> > manual checks to match the path actually being requested (ie. possible
> > on windows using meta info), or keep everyth
Hi François,
On Thu, Dec 25, 2014 at 2:40 PM, François Laupretre
wrote:
>> > De : Pierre Joye [mailto:pierre@gmail.com]
>>
>> > Anyone dying while waiting to see PHP having case sensitive symbols
>> > handling should go ahead with a RFC.
>
> For those interested, I just created a PR to raise
> > De : Pierre Joye [mailto:pierre@gmail.com]
>
> > Anyone dying while waiting to see PHP having case sensitive symbols
> > handling should go ahead with a RFC.
For those interested, I just created a PR to raise an E_STRICT message on class
and function/method case mismatch :
https://githu
> De : Pierre Joye [mailto:pierre@gmail.com]
> Anyone dying while waiting to see PHP having case sensitive symbols
> handling should go ahead with a RFC. He will also have to deal with
> file ops while being at it. Should they remain case insensitive? Do
> manual checks to match the path actua
On Tue, Dec 23, 2014 at 9:00 AM, Maxime Veber wrote:
> Even if i'm a php developer since a while, i never new or see usage of the
> case-insensitive "feature". IMO that's something a bit terrible and people
> do not use it but make mistakes that PHP "automatically fix". This behavior
> is very wei
Even if i'm a php developer since a while, i never new or see usage of the
case-insensitive "feature". IMO that's something a bit terrible and people
do not use it but *make mistakes* that PHP "automatically fix". This
behavior is very weird and comes with bad code quality.
Of course this is a BCB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 20/12/2014 23:01, F & N Laupretre a écrit :
> Hi,
>
>
>
> I don't know if this was discussed before. So, tell me what you
> think before I write an RFC.
>
>
>
> I would like to propose that namespaces, functions, and classes
> become case-sens
On Tue, Dec 23, 2014 at 2:17 AM, Ferenc Kovacs wrote:
> On Sat, Dec 20, 2014 at 11:01 PM, F & N Laupretre
> wrote:
>
>> Hi,
>>
>>
>>
>> I don't know if this was discussed before. So, tell me what you think
>> before
>> I write an RFC.
>>
>>
>>
>> I would like to propose that namespaces, functions
On Mon, Dec 22, 2014 at 11:40:33PM -0200, guilhermebla...@gmail.com wrote:
> +1 for adding E_DEPRECATED and removing support in PHP 8.
+1
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliam
+1 for adding E_DEPRECATED and removing support in PHP 8.
On Mon, Dec 22, 2014 at 11:17 PM, Ferenc Kovacs wrote:
> On Sat, Dec 20, 2014 at 11:01 PM, F & N Laupretre
> wrote:
>
> > Hi,
> >
> >
> >
> > I don't know if this was discussed before. So, tell me what you think
> > before
> > I write an
On Sat, Dec 20, 2014 at 11:01 PM, F & N Laupretre
wrote:
> Hi,
>
>
>
> I don't know if this was discussed before. So, tell me what you think
> before
> I write an RFC.
>
>
>
> I would like to propose that namespaces, functions, and classes become
> case-sensitive (constants are already case-sensi
Hi all,
On Mon, Dec 22, 2014 at 8:33 AM, David Muir wrote:
> +1 on E_STRICT warning for case mismatch on class names. Also +1 on
> eventual case sensitivity for userland class names. Not convinced the rest
> is worth it.
>
> The insensitivity makes code brittle. Sometimes the same code will run
On Dec 22, 2014 4:33 PM, "F & N Laupretre" wrote:
> With all due respect, I don't like the idea that you know better than me
what's important or not.
I should put the "I am not saying .." outlined. Also no matter how we look
at it, there are actually a good amount of things that we must solve or
On Mon, Dec 22, 2014 at 10:18:29AM +0100, Lester Caine wrote:
> If the core functionality remains ASCII based then there is no need to drop
> case insensitivity, but if there is a move to better multi-lingual support,
> then it may be necessary for compatibility with Unicode?
This issue is about
> De : Pierre Joye [mailto:pierre@gmail.com]
>
> In my opinion the pains introduced by such a change does not match
> with any possible gains. Many areas affect the request time badly
> (IOs, mem, etc), I do not see case insensitivity as one
Right. It is not a question of performance, as the
: Xinchen Hui
To: Pierre Joye
Cc: Mike Dugan , Andrea Faulds , Marco Pivetta
, PHP internals , David Muir
, Paul Dragoonis ,
"nf.laupre...@yahoo.fr" , Kevin Israel
Sent: Mon, 22 Dec 2014 6:25 AM
Subject: Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Mon, Dec 22, 2014 a
On Mon, Dec 22, 2014 at 12:35 PM, Pierre Joye wrote:
> On Mon, Dec 22, 2014 at 3:05 PM, Mike Dugan wrote:
>> Development should also be a consideration, I see a lot of developers using
>> Windows for local development (even on the irc channels). These are the same
>> ones who are, in my experie
On Mon, Dec 22, 2014 at 3:05 PM, Mike Dugan wrote:
> Development should also be a consideration, I see a lot of developers using
> Windows for local development (even on the irc channels). These are the same
> ones who are, in my experience, less likely to be aware of solutions like
> Vagrant j
Development should also be a consideration, I see a lot of developers using
Windows for local development (even on the irc channels). These are the same
ones who are, in my experience, less likely to be aware of solutions like
Vagrant just as much as the subtleties of case sensitivity across ope
> On 22 Dec 2014, at 03:58, Pierre Joye wrote:
>
>
> On Dec 22, 2014 8:03 AM, "Marco Pivetta" wrote:
> >
> > On 22 December 2014 at 01:52, Andrea Faulds wrote:
> >
> > >
> > > > On 22 Dec 2014, at 00:50, Marco Pivetta wrote:
>
> > Except that nobody I know of runs production on a case-inse
On Dec 22, 2014 8:03 AM, "Marco Pivetta" wrote:
>
> On 22 December 2014 at 01:52, Andrea Faulds wrote:
>
> >
> > > On 22 Dec 2014, at 00:50, Marco Pivetta wrote:
> Except that nobody I know of runs production on a case-insensitive
> filesystem.
I know a lot, really a lot.
On 22 December 2014 at 01:52, Andrea Faulds wrote:
>
> > On 22 Dec 2014, at 00:50, Marco Pivetta wrote:
> >
> > On 22 December 2014 at 01:43, Andrea Faulds wrote:
> >
> >> Hey,
> >>
> >>> On 21 Dec 2014, at 23:33, David Muir wrote:
> >>>
> >>> The insensitivity makes code brittle. Sometimes th
> On 22 Dec 2014, at 00:50, Marco Pivetta wrote:
>
> On 22 December 2014 at 01:43, Andrea Faulds wrote:
>
>> Hey,
>>
>>> On 21 Dec 2014, at 23:33, David Muir wrote:
>>>
>>> The insensitivity makes code brittle. Sometimes the same code will run
>> fine, and other times it breaks depending on
On 22 December 2014 at 01:43, Andrea Faulds wrote:
> Hey,
>
> > On 21 Dec 2014, at 23:33, David Muir wrote:
> >
> > The insensitivity makes code brittle. Sometimes the same code will run
> fine, and other times it breaks depending on what lines triggered the auto
> loader. If you instantiate a F
Hey,
> On 21 Dec 2014, at 23:33, David Muir wrote:
>
> The insensitivity makes code brittle. Sometimes the same code will run fine,
> and other times it breaks depending on what lines triggered the auto loader.
> If you instantiate a Foo instance first, then instantiate a new foo, the code
>
> On 21 Dec 2014, at 10:32 am, Kevin Israel wrote:
>
>> On 12/20/2014 05:16 PM, Paul Dragoonis wrote:
>> It's too big of a BC change firstly.
>>
>> Secondly it has no language benefit or developer benefit.
>
> Are you sure? Autoloading schemes such as PSR-4 derive pathnames from
> class names
On 20 December 2014 22:44:24 GMT, Alain Williams wrote:
>Fixing this would require a lot of work as well as some way of
>determining what
>character encoding the source file was written in ... different
>includes might
>have different encodings.
>
>We recently talked about a way of specifying sour
On Sun, Dec 21, 2014 at 04:20:13PM +1100, Pierre Joye wrote:
> I have hard time to see the benefits of breaking so many codes for that.
Has anyone done any benchmarking on the overhead of the internal/hidden convert
to lower case of function/... names ?
--
Alain Williams
Linux/GNU Consultant -
On Sun, Dec 21, 2014 at 9:01 AM, F & N Laupretre wrote:
> Hi,
>
>
>
> I don't know if this was discussed before. So, tell me what you think before
> I write an RFC.
>
>
>
> I would like to propose that namespaces, functions, and classes become
> case-sensitive (constants are already case-sensitive
Hi!
> is not recommended at all. Keeping not recommended spec forever is not
> a good idea. IMHO. Using strtolower() all over place in the Engine to keep
There's a huge difference between "not recommended" and breaking the
code. Using if() without braces, or inconsistent indentation - is not
reco
I just read Nikita's RFC on deprecated features for PHP 7.
Couldn't we go this way and use his process ? add to his list the fact that
functions, classes, and namespaces can be declared and used/called with
case-sensitivity mismatches ? This would become clearly known by
everyone. Then, as any ot
> De : Andrea Faulds [mailto:a...@ajf.me]
> I’d thought of doing this before, but the backwards-compatibility cost is too
> high.
It is a BC break, I agree, but would the impact on PHP community be so high ? I
have never seen any PHP code which would rely on function/class names
case-insensitivi
Hi all,
On Sun, Dec 21, 2014 at 7:01 AM, F & N Laupretre
wrote:
> I would like to propose that namespaces, functions, and classes become
> case-sensitive (constants are already case-sensitive). Actually, I never
> understood why they are case-insensitive. Even if the performance gain is
> neglig
On 12/20/2014 05:16 PM, Paul Dragoonis wrote:
> It's too big of a BC change firstly.
>
> Secondly it has no language benefit or developer benefit.
Are you sure? Autoloading schemes such as PSR-4 derive pathnames from
class names without converting them to lowercase. If case mismatches go
undetect
Hey Alain,
> On 20 Dec 2014, at 22:52, Alain Williams wrote:
>
> On Sat, Dec 20, 2014 at 10:45:39PM +, Andrea Faulds wrote:
>
>> I would like to see more case uniformity, but I think this is the less
>> practical direction. Instead of making everything case-sensitive, we should
>> make ev
On Sat, Dec 20, 2014 at 10:45:39PM +, Andrea Faulds wrote:
> I would like to see more case uniformity, but I think this is the less
> practical direction. Instead of making everything case-sensitive, we should
> make everything case-insensitive, which would break far less stuff, and is a
>
Hey François, (I assume there’s a ç, I apologise if not)
> On 20 Dec 2014, at 22:01, F & N Laupretre wrote:
>
> I don't know if this was discussed before. So, tell me what you think before
> I write an RFC.
Ah, this subject has come up before, I think. :)
> I would like to propose that namespa
On Sat, Dec 20, 2014 at 11:01:23PM +0100, F & N Laupretre wrote:
> Hi,
>
>
>
> I don't know if this was discussed before. So, tell me what you think before
> I write an RFC.
>
>
>
> I would like to propose that namespaces, functions, and classes become
> case-sensitive (constants are alread
Hi Francois,
It's too big of a BC change firstly.
Secondly it has no language benefit or developer benefit.
The only benefit is case correctness which is a nice to have. Making sure
existing code works is a must have.
Cheers,
Paul
On 20 Dec 2014 22:01, "F & N Laupretre" wrote:
> Hi,
>
>
>
>
47 matches
Mail list logo
