That would be nice and all, but I'd rather we add methods to arrays.
On Jul 17, 2012 1:26 AM, "David Muir" wrote:
> On 14/07/12 01:33, Anthony Ferrara wrote:
>
>> Hey all,
>>
>> I know that 6.0 was originally supposed to be the unicode conversion of
>> the
>> engine. However it appears that all p
hi,
On Mon, Jul 16, 2012 at 10:19 PM, Ángel González wrote:
> About supporting POSIX classes, that could be cool. But you then need a way
> to enumerate them. Note that isalpha() will be provided by the C
> library, so you
> can't count on having its data. It's possible that PCRE, which we bundl
hi,
On Sat, Jul 14, 2012 at 11:29 PM, Brandon Wamboldt
wrote:
> FYI, data URIs are only supported in IE8 or higher, IE7 and below do not
> support them.
That's fine, not like it is a mission critical feature anyway.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.or
Hi,
On 07/17/2012 05:40 AM, Nicholas Curtis wrote:
> Great Idea, would love to see current standard library in a legacy
> namespace and a new standard library implemented as methods of
> primitive types.
The idea to separate old and new behaviour has some charm.
> $string = "Hello, World";
> ec
>
> you have to change existing code (if I understand your syntax
> correctly)
I think the idea here is to put functions likes floor and round in a legacy
namespace of sorts, so they are not accessible in the global namespace.
Then you have an .ini directive that imports the legacy namespace in
hi,
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes wrote:
> Let's ignore empty arguments like "make[s] PHP feel modern". That aside, the
> main argument advanced in this message makes no sense.
This idea has been proposed many times in the past and it is actually
a very good proposal, for array
I think strings are even more important, they have an even messier API than
arrays.
On Jul 17, 2012 11:07 AM, "Pierre Joye" wrote:
> hi,
>
> On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes
> wrote:
>
> > Let's ignore empty arguments like "make[s] PHP feel modern". That aside,
> the
> > main argum
On Tue, 17 Jul 2012 12:07:09 +0200, Pierre Joye wrote:
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes
wrote:
Adding method call
syntax to arrays hardly makes PHP more object oriented. Syntax is
unimportant. There's no substantial difference between
array_slice($arr,
...) and $arr->slice(...
hi Gustavo,
On Tue, Jul 17, 2012 at 12:21 PM, Gustavo Lopes wrote:
> There isn't a difference in terms of making PHP more object oriented, which
> was the main advantage advanced by the OP. I'm all for redesigning
> strings/arrays APIs (presented as an afterthought by the OP), but for that
> the
I might not have made it clear, but the main reasons I want it are:
- Chance to clean up array/string/etc APIs
- Looks nicer IMO, slightly clearer what functions do and affect
On Jul 17, 2012 11:21 AM, "Gustavo Lopes" wrote:
> On Tue, 17 Jul 2012 12:07:09 +0200, Pierre Joye wrote:
>
> On Tue, J
Pierre Joye wrote:
This idea has been proposed many times in the past and it is actually
a very good proposal, for array, string or other types.
The only reason why it is not yet implemented is the technical
complexity to do it. We need pseudo objects and the likes, and it is
really not somethin
2012/7/16 Ángel González :
>> 1a) If you want to support character classes, you can do it with pcre:
>> http://www.php.net/manual/en/regexp.reference.character-classes.php
> That's more or less what I have thought.
> If it's a string surrounded by square brackets, it's a character class,
> else
>
> Basically, the current function library is moved to the legacy
> namespace. The default setting is import the functions of the legacy
> namespace into the root namespace for BC. But with that setting
> turned off all the existing functions go away to be replaced with a
> designed API, instead o
I like this idea a lot. I use PHP at work, and run everything on dedicated
servers so I'd definitely prefer to run a pure PHP6 setup. Hosting
providers on the other hand can over PHP5 support via an extension.
+1
On Tue, Jul 17, 2012 at 9:51 AM, Leigh wrote:
> > Basically, the current function
Hi Marian,
since last week current master snaps can be found here
http://windows.php.net/downloads/snaps/master/
Cheers
anatoliy
Am Di, 19.06.2012, 20:16 schrieb Marian Kostadinov:
> Hello Anatoliy,
> https://bugs.php.net/patch-display.php?bug_id=61998&patch=bug61998.patch&revision=latest
>
> s
This is an excellent idea. Full BC yet without legacy cruft. Old code runs
on legacy support extensions, new code doesn't need it.
On Jul 17, 2012 1:51 PM, "Leigh" wrote:
> > Basically, the current function library is moved to the legacy
> > namespace. The default setting is import the functions
On 07/17/2012 03:07 AM, Pierre Joye wrote:
> hi,
>
> On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes wrote:
>
>> Let's ignore empty arguments like "make[s] PHP feel modern". That aside, the
>> main argument advanced in this message makes no sense.
>
> This idea has been proposed many times in th
I dislike this idea from the ground up.
While I think having a legacy implementation is definitely worth while, it
needs to be in core. So PHP6 would introduce the new syntax, and include
the legacy functionality in as close to 100% backwards compatible way as
possible. From there, we'd only remov
вторник, 17 июля 2012 г. пользователь писал:
>
> internals Digest 17 Jul 2012 10:31:01 - Issue 2723
>
> Topics (messages 61317 through 61343):
>
> Re: RFC Proposal - Attributes read/write visibility
> 61317 by: Amaury Bouchard
> 61318 by: Daniel Macedo
> 61319 by: Amaur
Aren't certain modules included in the PHP core distribution, like the
mysqli extension that you enable using --with-mysqli?
Could we not include the PHP5 namespace as an extension with the PHP
distribution, and have it enabled by default, but provide a
--disable-legacy-namespace option?
Then in
Hi,
please can someone look into this issue. It seems that in version
5.4.4-1 the bug was fixed, but in newer versions this issue still
exists. So please can someone merge the patch with the newer versions?
https://bugs.php.net/bug.php?id=55544
Cheers,
Christian
--
PHP Internals - PHP Runti
Well, being able to disable the fallback would allow developers to eagerly
discover features that are going to be dropped (and it doesn't need to be a
soft failure).
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 17 July 2012 16:14, Brandon Wamboldt wrote:
> Aren't ce
I agree, and it allows developers who don't need/want PHP5 compatibility to
just disable the legacy namespace, reducing cruft and allowing them to
prepare for future versions of PHP.
Developers or hosting providers who need to support PHP5 can just
compile/install PHP with default settings which w
> While I think having a legacy implementation is definitely worth while, it
> needs to be in core. So PHP6 would introduce the new syntax, and include the
> legacy functionality in as close to 100% backwards compatible way as
> possible. From there, we'd only remove the legacy functionality from c
Whilst weak typing has its benefits, I think typing is a little too weak in
places. IMO "" should not be equal to 0 or coercable to 0. But of course
"0" should equal 0.
On Jul 17, 2012 3:04 PM, "Rasmus Lerdorf" wrote:
> On 07/17/2012 03:07 AM, Pierre Joye wrote:
> > hi,
> >
> > On Tue, Jul 17, 20
On 07/17/2012 08:06 AM, Andrew Faulds wrote:
> Whilst weak typing has its benefits, I think typing is a little too weak
> in places. IMO "" should not be equal to 0 or coercable to 0. But of
> course "0" should equal 0.
Which has nothing to do with this thread.
>
> On Jul 17, 2012 3:04 PM, "Rasm
Hi,
Some of the things I want to see in PHP 6:
New designed Standard Library:
* Clearly defined conventions for organization, naming and error handling.
* Use Namespaces and groups functions by their purpose ("net", "strings",
"arrays",…)
* Promote SPL functionality ("spl_autoload_register", Da
I'd really like to see full unicode support as well, scalar values as
objects with methods ($intVar->abs()), and the ability to import all
classes/functions from a namespace.
On Tue, Jul 17, 2012 at 11:37 AM, Leigh wrote:
> > While I think having a legacy implementation is definitely worth while
The problem, of course, is changing and removing things can break BC. I'd
love to remove list() too, but that would break code relying on it.
On Jul 17, 2012 4:23 PM, "Christoph Hochstrasser" <
christoph.hochstras...@gmail.com> wrote:
> Hi,
>
> Some of the things I want to see in PHP 6:
>
> New de
I thought list() was a syntax, not standard lib, feature? Like array() (or
am I thinking of isset()?)
On Jul 17, 2012 4:48 PM, "Dan Cryer" wrote:
> The problem, of course, is changing and removing things can break BC. I'd
>> love to remove list() too, but that would break code relying on it.
>
>
>
> The problem, of course, is changing and removing things can break BC. I'd
> love to remove list() too, but that would break code relying on it.
Isn't that kind of the point of the whole discussion? This is talking about
completely rewriting the standard library for PHP 6, but providing a lega
You're correct, list() is a language construct. Is it still possible to add
that in via an extension somehow?
On Tue, Jul 17, 2012 at 1:00 PM, Andrew Faulds wrote:
> I thought list() was a syntax, not standard lib, feature? Like array() (or
> am I thinking of isset()?)
> On Jul 17, 2012 4:48 PM,
On 17/07/12 13:34, Alex Aulbach wrote:
>> That's more or less what I have thought.
>> If it's a string surrounded by square brackets, it's a character class,
>> else
>> treat as a literal list of characters.
>> ] and - can be provided with the old trick of provide "] as first
>> character",
>> "mak
On 07/17/2012 07:25 AM, Christian Kaps wrote:
Hi,
please can someone look into this issue. It seems that in version 5.4.4-1 the
bug was fixed, but in newer versions this issue still exists. So please can
someone merge the patch with the newer versions?
https://bugs.php.net/bug.php?id=55544
On 07/17/2012 06:22 AM, Anatoliy Belsky wrote:
Hi Marian,
since last week current master snaps can be found here
http://windows.php.net/downloads/snaps/master/
Cheers
anatoliy
How does that really relate to http://windows.php.net/snapshots/ ?
Are you going to make the links on http://windo
Hi!
> please can someone look into this issue. It seems that in version
> 5.4.4-1 the bug was fixed, but in newer versions this issue still
> exists. So please can someone merge the patch with the newer versions?
>
> https://bugs.php.net/bug.php?id=55544
There's no version 5.4.4-1. The patch w
Hi!
> This idea has been proposed many times in the past and it is actually
> a very good proposal, for array, string or other types.
If we have "$array->foo()", we should also have "class foo extends
array" which allows to override foo() in array. This will require some
serious changes, which ne
On 17.07.2012, at 21:03, Stas Malyshev wrote:
> Hi!
>
>> This idea has been proposed many times in the past and it is actually
>> a very good proposal, for array, string or other types.
>
> If we have "$array->foo()", we should also have "class foo extends
> array" which allows to override foo(
Hi!
> I am for making array a proper class with methods.
>
> "Legacy" functions can be implemented as wrappers around it:
>
> function array_push(&$array, $value)
> {
> $array->push($value);
> }
The problem there is that array has different semantics than object. Not
complet
On 17.07.2012, at 21:50, Stas Malyshev wrote:
> Hi!
>
>> I am for making array a proper class with methods.
>>
>> "Legacy" functions can be implemented as wrappers around it:
>>
>>function array_push(&$array, $value)
>>{
>>$array->push($value);
>>}
>
> The problem there is
Hi!
> Options are: * "5-to-6" tool, similar to python's "2-to-3" converter,
> which will fix code.
Do you know any practical way of how such tool could work?
> * introduce some kind of per-file declare() option, which would
> enable pass-by-reference semantics of arrays/strings/etc. in 5.5
> whi
On 17.07.2012, at 23:01, Stas Malyshev wrote:
> Hi!
>
>> Options are: * "5-to-6" tool, similar to python's "2-to-3" converter,
>> which will fix code.
>
> Do you know any practical way of how such tool could work?
That would be: tokenizer + static analysis (with type inference) + replacing
so
Hi!
> That would be: tokenizer + static analysis (with type inference) + replacing
> some of the tokens.
> Not a trivial task, but definitely doable.
So what would this tool do with this code?
$a = getFirstArrayName();
$b = getSecondArrayName();
$$a = $$b;
$b[1] = 0;
Or this:
include 'a.inc';
On 17.07.2012, at 23:20, Stas Malyshev wrote:
> Hi!
>
>> That would be: tokenizer + static analysis (with type inference) + replacing
>> some of the tokens.
>> Not a trivial task, but definitely doable.
>
> So what would this tool do with this code?
>
> $a = getFirstArrayName();
> $b = getSec
2012/7/17 Ángel González :
> Those could be in the flag. The / are not really needed, they are an
> additional syntax over regex provided by PHP (and the character can be a
> different
makes it a little bit like Perl. I see this as a "standard". So for me
a regex is with delimiters, even if the l
hi,
On Tue, Jul 17, 2012 at 7:03 PM, Stas Malyshev wrote:
> I disagree - I do not think we need pseudo-objects. If the only point of
> the exercise is to convert a call of array_pop to $array->pop, it's not
> worth it. It'd just make the language more messy - you wouldn't know
> what -> means an
Hi!
> Having pure object would be not efficient enough and brings its lot of
> caveats. Also it is important to keep in mind that this idea does not
> apply only to array but to other types as well.
Same for other types. Just adding -> doesn't make the code
object-oriented. And just bolting -> on
On Tue, Jul 17, 2012 at 8:48 AM, Dan Cryer wrote:
> >
> > The problem, of course, is changing and removing things can break BC. I'd
> > love to remove list() too, but that would break code relying on it.
>
>
> Isn't that kind of the point of the whole discussion? This is talking about
> completel
On Tue, Jul 17, 2012 at 3:43 PM, Kris Craig wrote:
>
>
> On Tue, Jul 17, 2012 at 8:48 AM, Dan Cryer wrote:
>
>> >
>> > The problem, of course, is changing and removing things can break BC.
>> I'd
>> > love to remove list() too, but that would break code relying on it.
>>
>>
>> Isn't that kind of
Took the words from my mouth. Removing legacy support is a terrible idea
for PHP6. It makes it impossible to write forwards compatible code that
currently runs in PHP5. Even having it optional is a bad idea IMO since
it will fragment PHP hosting. Some will be able to run PHP6 only (no
legacy),
I just noticed something that I hadn't really thought about before. I
couldn't remember the name of the function for parsing INI files so I did a
quick search. It took me straight to the page for php.ini directives. I
had to select "online documentation" from the dropdown and try again, this
tim
51 matches
Mail list logo
