I will also note that my phone cut off the part about this post not being
serious.
I, however, have no sense of humor.
On Jul 18, 2012, at 11:17 PM, Ronald Chmara wrote:
> With PHP 6, lets start with a:
> Pure
> Object
> Oriented
> PHP
>
> ...idea, and extend it out, so we can have a:
> Stru
I'll start off by saying that I am, personally, a great fan of OO. Pure OO
languages have always tickled me just right.
But I question the idea that making something pure OO makes it better. And in
PHP, it wouldn't be a mere revamp of the OOP system like php5 did, it would
fundamentally change
With PHP 6, lets start with a:
Pure
Object
Oriented
PHP
...idea, and extend it out, so we can have a:
Structured
Heuristic
Idealistic
Taxonomy
..so we reduce user confusion, and eliminate the vast majority of our
userbase, (thus cutting down on bug reports, of course) so we can
have a:
Heuristic
On Wed, Jul 18, 2012 at 6:53 PM, Laruence wrote:
> Hi:
> I saw you two vote against for this RFC.
>
> could you explain why? then maybe I can improve it.
>
> thanks
>
>
I can't speak for them, but it might have something to do with a lack of
information. I don't recall seeing the discus
On Wed, Jul 18, 2012 at 6:16 PM, Rasmus Lerdorf wrote:
> On 07/18/2012 05:10 PM, David Muir wrote:
> > On 19/07/12 04:49, Rasmus Lerdorf wrote:
> >> On 07/18/2012 01:02 AM, Pierre Joye wrote:
> >>> hi,
> >>>
> >>> On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev
> >>> wrote:
> Hi!
>
> >>
Hi:
I saw you two vote against for this RFC.
could you explain why? then maybe I can improve it.
thanks
On Wed, Jul 18, 2012 at 11:21 PM, Laruence wrote:
> On Wed, Jul 18, 2012 at 11:19 PM, Leigh wrote:
>> I missed the discussion on this one, the RFC examples are very simple. Does
>>
On 07/18/2012 05:10 PM, David Muir wrote:
> On 19/07/12 04:49, Rasmus Lerdorf wrote:
>> On 07/18/2012 01:02 AM, Pierre Joye wrote:
>>> hi,
>>>
>>> On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev
>>> wrote:
Hi!
> See the other answers, clear APIs, no more argument mess, cleanness.
On 19/07/12 04:49, Rasmus Lerdorf wrote:
On 07/18/2012 01:02 AM, Pierre Joye wrote:
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev wrote:
Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
-> to
Em Thu, 19 Jul 2012 01:11:38 +0200, Stas Malyshev
escreveu:
Example:
http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
In this case, NULL, int and string are allowed. This would become much
simpler:
if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
se = TimeZone
Cap it at INT_MAX, yeah, that seems reasonable. A notice seems reasonable
but production servers displaying errors... devs will go mad :)
On Jul 18, 2012 11:39 PM, "Nikita Popov" wrote:
> Hi internals!
>
> When a large floating point number is cast to an integer we currently
> have very low-level
Hi!
> Some deficiencies in zpp have been constrai
> ning the implementation of common scenarios such as 'allow integer or
> NULL'* or the more general 'allow different types for an argument'**.
>
> So I propose the changes in this branch:
>
> https://github.com/cataphract/php-src/compare/zpp_i
> People are forgetting why we have version numbers.
>
> Yes, it's very spectacular to have all the new stuff in a major release, but
> that's not what major versions are for.
> Major versions are for BC breaks. And point releases are for BC-compatible
> new features.
> Therefore in 5.x releases ol
I'd like to see some version of the null-coalescing ternary operator
(recently brought up in a thread started by Rafael Dohms) make it into PHP.
To help it along, may I have RFC karma so I can draft a proposal? My PHP
wiki account name is "outis", e-mail is "ww.ga...@gmail.com".
If there's a bette
Hi internals!
When a large floating point number is cast to an integer we currently
have very low-level C behavior (integer overflow and wraparound):
$ /c/php-5.4.1/php -r 'var_dump((int) 40);'
int(-294967296)
$ /c/php-5.4.1/php -r 'var_dump((int) 60);'
int(1705032704)
As a fun
On Wed, Jul 18, 2012 at 11:05 PM, Gustavo Lopes wrote:
> Some deficiencies in zpp have been constrai
> ning the implementation of common scenarios such as 'allow integer or NULL'*
> or the more general 'allow different types for an argument'**.
>
> So I propose the changes in this branch:
>
> http
On Wed, Jul 18, 2012 at 12:21 PM, Galen Wright-Watson wrote:
>
>
> On Wed, Jul 18, 2012 at 7:20 AM, Anthony Ferrara wrote:
>
>>
>> On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms > >wrote:
>>
>> > [...]
>>
>> >
>> > This is basically because the ternary operator does not do a internal
>> > implicit
It changes the semantics. If the variable is set to a falsey value and ?:
uses an implicit isset, the value of the expression will be the falsey
value.
$config['width'] = ''
$width = $config['width'] ?: 300
# $width == ''
If !empty were used instead of isset, you could preserve semantic
But OOP-like syntax on non-object data is still weird. The question about
data manipulation behavior (is it a pointer like other objects or is it a
scalar like existing array?) is a tough one.
For the user's point of view there is no difference between the passing
semantics of numbers/string pr
Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as 'allow integer or
NULL'* or the more general 'allow different types for an argument'**.
So I propose the changes in this branch:
https://github.com/cataphract/php-src/compare/zpp_improv
Please see
Sure, BC breaks for 6.0, but it worries me. I don't want a Python 3 for PHP
6. Or heck, PHP5 for that matter.
On Jul 18, 2012 9:50 PM, "Stan Vass" wrote:
> Chaos will surely be, if we break PHP5 code. It should work without
>> modification. > On Jul 18, 2012 9:34 PM, "Daniel Macedo" wrote:
>>
>
...er, wrote:
> > use a slightly modified version of the open tag, for example > <*php, etc. This satisfies several desires: we don't want an extra
> > line of boilerplate code like 'use PHP 6' to be required in every
> > source file, we want a PHP 5 file to run without modification, and we
> >
Chaos will surely be, if we break PHP5 code. It should work without
modification. wrote:
People are forgetting why we have version numbers.
Yes, it's very spectacular to have all the new stuff in a major release, but
that's not what major versions are for.
Major versions are for BC breaks. An
I do like the idea of pseudo-objects with methods as a way to create
much cleaner APIs for strings and arrays, but the legacy APIs need to
stick around.
You don't need to break BC to remove legacy APIs in PHP6.
#1. Introduce the new APIs in 5.x and gradually mark the old ones as
deprecated, b
Chaos will surely be, if we break PHP5 code. It should work without
modification. wrote:
> > use a slightly modified version of the open tag, for example > <*php, etc. This satisfies several desires: we don't want an extra
> > line of boilerplate code like 'use PHP 6' to be required in every
> >
> use a slightly modified version of the open tag, for example <*php, etc. This satisfies several desires: we don't want an extra
> line of boilerplate code like 'use PHP 6' to be required in every
> source file, we want a PHP 5 file to run without modification, and we
> want a PHP 6 file to be ab
If there's this big conflict between BC breaks being bad because they
discourage adoption and make old code unusable on the one hand, and
good because they allow many things to be cleaned up and progress to
be made, then why not pursue a three-pronged approach:
1. BC breaks are made wherever it mak
> I think there is something we can do around this...
Reviewing the php array functions it seems to me that a new API would benefit
from some sort of more intuitive organization, possibly around meta concepts
specific to use.
For example, I want to re-order an array (order is a meta-concept in
On Wed, Jul 18, 2012 at 12:09 PM, Andrew Faulds wrote:
> Kris, I'd love to break BC a lot and fix things, but it would seriously
> slow adoption. Fixing *bugs* has stopped people upgrading, imagine how they
> would react to non-bugs being changed.
>
>
I agree with your point. I guess my thinking
On Wed, Jul 18, 2012 at 7:20 AM, Anthony Ferrara wrote:
>
> On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms >wrote:
>
> > [...]
> >
> > This is basically because the ternary operator does not do a internal
> > implicit isset, only an empty.
> >
>
> It does not do an empty. Empty would avoid notice
On Wed, Jul 18, 2012 at 11:32 AM, Hannes Magnusson <
hannes.magnus...@gmail.com> wrote:
> On Wed, Jul 18, 2012 at 7:26 PM, Kris Craig wrote:
> >>
> >> I don't understand why on earth your are mailing the PHP *internal
> >> developer mailinglist* with this matter?
> >>
> >> If you have any improve
Kris, I'd love to break BC a lot and fix things, but it would seriously
slow adoption. Fixing *bugs* has stopped people upgrading, imagine how they
would react to non-bugs being changed.
On Jul 18, 2012 7:21 PM, "Kris Craig" wrote:
>
>
> On Wed, Jul 18, 2012 at 7:27 AM, Andrew Faulds wrote:
>
>>
On 07/18/2012 01:02 AM, Pierre Joye wrote:
> hi,
>
> On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev wrote:
>> Hi!
>>
>>> See the other answers, clear APIs, no more argument mess, cleanness.
>>
>> Cleanness has nothing to do with pseudo-objects.You don't have to use
>> -> to have clean APIs, and u
hi,
On Wed, Jul 18, 2012 at 7:50 PM, Ferenc Kovacs wrote:
> Maybe we could introduce a new namespace for the new api instead of turning
> the new api oop only (or using objects for groupping static stateless
> functions into objects only to hint that they are working with the same
> variable typ
On Wed, Jul 18, 2012 at 7:26 PM, Kris Craig wrote:
>>
>> I don't understand why on earth your are mailing the PHP *internal
>> developer mailinglist* with this matter?
>>
>> If you have any improvement suggestions for the documentations:
>> https://edit.php.net
>>
>> -Hannes
>
>
> I've seen the do
>
>
> I don't understand why on earth your are mailing the PHP *internal
> developer mailinglist* with this matter?
>
> If you have any improvement suggestions for the documentations:
> https://edit.php.net
>
> -Hannes
>
I've seen the docs discussed on this list plenty of times. We do maintain
th
On Wed, Jul 18, 2012 at 7:27 AM, Andrew Faulds wrote:
> To avoid BC breaks we should try to avoid major syntax changes.
Again, why should we be worrying so much about BC breaks on a major version
increment? BC breakage is just a fact of life whenever a major version of
anything comes out. Beca
2012.07.18. 18:55, "Stas Malyshev" ezt írta:
>
> Hi!
>
> > Er, sorry, accidental capslock. This IS a new API. That was an example.
> > I'm not saying just put -> everywhere, I'm saying we can keep array_*
> > and add a new set of -> functions which are well-designed, consistent,
etc.
>
> What "thi
On 07/18/2012 08:48 AM, Joe Orton wrote:
The "state" parameter passed to SQLGetDiagRec() needs to be six bytes
not 5; the attached patch fixes this, from Martin Osvald.
Hi Joe,
Is there any chance you can log this in https://bugs.php.net/
and/or submit a pull request at https://github.com
It's possible, but we have to write too much code just to identify all
possible overloads. If methods are overloaded by their signature, surely
the PHP code will be more clean.
Well, I'm just wondering if it is possible without start a war, I'm not
sure how expensive it could be.
On Wed, Jul 18,
That would be cool, but couldn't you just detect argument types?
On Jul 18, 2012 5:55 PM, "Rafael Kassner" wrote:
> I'm wondering if we could include method overloading. Will be pretty nice
> mixing it with scalar type hinting or scalar values as objects
>
> On Wed, Jul 18, 2012 at 11:27 AM, Andr
Obviously. This is simply the means to provide the new API without breaking
BC. If people think this is acceptable then sure, let's plan an API.
On Jul 18, 2012 5:54 PM, "Stas Malyshev" wrote:
> Hi!
>
> > Er, sorry, accidental capslock. This IS a new API. That was an example.
> > I'm not saying j
I'm wondering if we could include method overloading. Will be pretty nice
mixing it with scalar type hinting or scalar values as objects
On Wed, Jul 18, 2012 at 11:27 AM, Andrew Faulds wrote:
> To avoid BC breaks we should try to avoid major syntax changes. We could
> make new applications "hide"
Hi!
> Er, sorry, accidental capslock. This IS a new API. That was an example.
> I'm not saying just put -> everywhere, I'm saying we can keep array_*
> and add a new set of -> functions which are well-designed, consistent, etc.
What "this"? So far I didn't see any single message discussing anythi
WHAT?
Er, sorry, accidental capslock. This IS a new API. That was an example. I'm
not saying just put -> everywhere, I'm saying we can keep array_* and add a
new set of -> functions which are well-designed, consistent, etc.
On Jul 18, 2012 5:35 PM, "Stas Malyshev" wrote:
> Hi!
>
> > enough but I
hi Stas,
On Wed, Jul 18, 2012 at 6:35 PM, Stas Malyshev wrote:
> Hi!
>
>> enough but I don't know the Zend engine well enough). This way we can
>> have array->key, array->sort(TYPE), etc. for new code to use, instead of
>> the legacy array and string method mess (the latter needs a cleanup more
On Wed, Jul 18, 2012 at 1:19 AM, Kris Craig wrote:
> 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 "onl
On Wed, Jul 18, 2012 at 1:19 AM, Kris Craig wrote:
> 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 "onl
Hi!
> enough but I don't know the Zend engine well enough). This way we can
> have array->key, array->sort(TYPE), etc. for new code to use, instead of
> the legacy array and string method mess (the latter needs a cleanup more
> in particular).
The mess does not exist because we have array_key() i
The "state" parameter passed to SQLGetDiagRec() needs to be six bytes
not 5; the attached patch fixes this, from Martin Osvald.
diff --git a/ext/pdo_odbc/odbc_driver.c b/ext/pdo_odbc/odbc_driver.c
index 84a147b..ca2808c 100755
--- a/ext/pdo_odbc/odbc_driver.c
+++ b/ext/pdo_odbc/odbc_driver.c
@@ -1
It would probably be passed as first param to functions, or passed as
$this, like other methods.
On Jul 18, 2012 4:27 PM, "Amaury Bouchard" wrote:
> Seems a lot like another syntactic sugar.
>
> Like in Lua, where you can write
>obj:method(12)
> instead of
>obj.method(obj, 12)
>
> But OOP
Seems a lot like another syntactic sugar.
Like in Lua, where you can write
obj:method(12)
instead of
obj.method(obj, 12)
But OOP-like syntax on non-object data is still weird. The question about
data manipulation behavior (is it a pointer like other objects or is it a
scalar like existing a
On Wed, Jul 18, 2012 at 11:19 PM, Leigh wrote:
> I missed the discussion on this one, the RFC examples are very simple. Does
> it support aliasing array indices?
>
> For example: (use $matches[0] as $name)
sorry, no, it's only support literal variable for now.
thanks
>
> On Jul 18, 2012 3:55 PM,
I missed the discussion on this one, the RFC examples are very simple. Does
it support aliasing array indices?
For example: (use $matches[0] as $name)
On Jul 18, 2012 3:55 PM, "Laruence" wrote:
> Hi:
> Call for voting for "Allow use T_AS in closure use statement",
> https://wiki.php.net/rfc/
On Wed, Jul 18, 2012 at 10:49 PM, Laruence wrote:
> Hi:
> this is not a new RFC, I proposed it before, but due to my poor
> english and improper examples, it didn't get passed.
thanks phidev's good english, he re-wrote the descriptions.
thanks
>
> This feature introduces list() suppor
Hi:
Call for voting for "Allow use T_AS in closure use statement",
https://wiki.php.net/rfc/useas#voting
any comment will be appreciated.
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.
Sounds great. Python has something similar for tuples, would be good if PHP
had this.
Are there any BC concerns? Don't see why this could break something.
On Jul 18, 2012 3:50 PM, "Laruence" wrote:
> Hi:
> this is not a new RFC, I proposed it before, but due to my poor
> english and improp
Hi:
this is not a new RFC, I proposed it before, but due to my poor
english and improper examples, it didn't get passed.
This feature introduces list() support in foreach constructs(more
info can be found here: https://wiki.php.net/rfc/foreachlist):
what do you think? personall
Sounds good. CoffeeScript (a lightweight language with JS semantics that
compiles to JS) has a existential operator, "?", and this looks similar and
would be very nice. It's not the same thing, of course. It also reminds me
of JavaScript's || behaviour.
On Jul 18, 2012 3:24 PM, "Rafael Dohms" wrot
On Wed, 18 Jul 2012 16:15:44 +0200, Rafael Dohms wrote:
With the syntax improvements for 5.4 and some of the de-referencing
work,
code looks so much sleeker then before, but there is still one use
case
that really bugs me.
Given this code:
$width = (isset($config['width']))? $config['width']
OK, ok. Let me clear some things up here.
We don't want it to make things more object-oriented or whatever. The real
motivation is to give us a chance to make a much cleaner, much nicer array
API without breaking BC. We can keep the legacy array_* and unprefixed
functions, but we can also create "
Sounds good, search engines aren't always super smart.
On Jul 18, 2012 1:20 AM, "Kris Craig" wrote:
> 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 pa
To avoid BC breaks we should try to avoid major syntax changes. We could
make new applications "hide" legacy though, something like "use new;" which
would remove deprecated and legacy functions from the global namespace.
On Jul 18, 2012 12:16 AM, "David Muir" wrote:
> Took the words from my mouth
On Wed, Jul 18, 2012 at 4:20 PM, Anthony Ferrara wrote:
>
> Does this seem like a possible improvement we can work on? Anyone
>> interested in championing the change?
>>
>
> I like it in principle. My only concern is *why* wasn't it done this way
> in the first place... Is there a reason?
>
>
I do
Rafael,
One point of clarity:
On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms wrote:
> Hey Everyone,
>
> With the syntax improvements for 5.4 and some of the de-referencing work,
> code looks so much sleeker then before, but there is still one use case
> that really bugs me.
>
> Given this code:
Hey Everyone,
With the syntax improvements for 5.4 and some of the de-referencing work,
code looks so much sleeker then before, but there is still one use case
that really bugs me.
Given this code:
$width = (isset($config['width']))? $config['width'] : 300;
The code is pretty straight forward,
For a new version to be successful from a marketing perspective, there
has to be such a thing as "good old code."
Just as there are PHP 4 apps that are basically sound and maintainable
code and require only a few reasonable changes to run well in PHP 5,
that needs to be true for the transition to
hi,
On Wed, Jul 18, 2012 at 11:24 AM, Lester Caine wrote:
> Please can we keep a 'legacy' version of PHP stable at some point in time
> ... And let SonofPHP be forked off if that is what people want.
Totally off topic, and as stated earlier, this solution does not break
any existing functions o
Stas Malyshev wrote:
I really do not want to have a semantic discussion here.
>
>This syntax is sexy, allows us to clean our APIs, and is amazingly handy.
I'm sorry, but I can't understand how we can seriously consider making
object call syntax mean two entirely different things, create
pseudo-o
hi,
On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev wrote:
> And no, it does not "allow us to clean our APIs" - I again point out
> using -> has nothing to do with cleaning APIs. Repeating "clean APIs"
> as if it is some magic spell will not make false statement true, and the
> statement that us
Hi!
> I really do not want to have a semantic discussion here.
>
> This syntax is sexy, allows us to clean our APIs, and is amazingly handy.
I'm sorry, but I can't understand how we can seriously consider making
object call syntax mean two entirely different things, create
pseudo-objects that lo
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev wrote:
> Hi!
>
>> See the other answers, clear APIs, no more argument mess, cleanness.
>
> Cleanness has nothing to do with pseudo-objects.You don't have to use
> -> to have clean APIs, and using -> doesn't automatically make your APIs
> clean.
Hi!
> See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects. You don't have to use
-> to have clean APIs, and using -> doesn't automatically make your APIs
clean. Using -> has absolutely nothing to do with API cleanness and
arguments,
hi!
On Tue, Jul 17, 2012 at 10:30 PM, Stas Malyshev wrote:
> 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 a
Hi,
comments inline.
Am 17.07.2012 18:57, schrieb Stas Malyshev:
There's no version 5.4.4-1. The patch was
85a62e9086db7a8ddfcda4ab1279a2439935f8d5 merged but since then there
were other changes to the code. Mike, could you please check if we
have
a regression there?
OK, someone in the bug
74 matches
Mail list logo
