Hello Stanislav,
noone disagrees to any work any company is willing to do. Infact we should
be extremely happy about the work done by some IBM people lately (to stay
with the same company example). At least I am for one really happy! However
hiding in some secret rooms and deciding something
Hello Steph,
for example that would exclude me and I guess others as well.
marcus
Thursday, November 29, 2007, 6:49:34 PM, you wrote:
So, what, exactly, is the fuss all about?
Richard, the problem with a CLA (moral quibbles apart) is it prevents any of
the core contributors doing
Hello Rasmus,
the same applies to me as I pointed out to Richard already (as an example
to Stephs argument). An NDA or CLA usually means that you can talk about
stuff you do that contains patents and all that. Now we are not intersted in
patents at all. And the solutiuon is easy keep your
Hello Philip,
for the future please do not accept any copyright other than
The PHP Group or The PHP documentation Grroup. Thanks.
Otherwise comanies are going to own PHP piece by piece.
marcus
Thursday, November 29, 2007, 9:59:08 PM, you wrote:
On Nov 29, 2007, at 11:26 AM, Steph Fox
Hello Jordan,
have a look at the SPL extension (Standard PHP Library) which introduces
a few things (for instance SplFile). Have a look here: http://php.net/~helly
I do not think we need a string class right now unless you want to provide a
full unicode one that later works with HEAD
Hello Steph,
Wednesday, December 5, 2007, 2:33:47 AM, you wrote:
However, in the global scope (no namespace) it would fail. This is a
bug that is easily fixed. use should allow re-aliasing of global
classes, and I could provide a very easy fix.
This is not a bug - since there you work
Hello Roman, Stas,
even more so you want to have it as close as possible so that one can in
fact get a clue what is going on manually. And if only generators use that
stuff - well it doesn't matter to a generator if it has to write braces or
not. We create syntax for humans - otherwise we would
Hello Nathan,
if their income depends on it, hmm, I wonder, why the hell are they only
complaining? The amount of people being constructive and not actual
developers with a php.net account is close to zero. That is what Jani had in
mind. We have always been open and we have always gladly given
Hello Derick,
what fixes are we talking of, just what is in CVS?
Should we also revisit the stuff we use for http://gcov.php.net ?
marcus
Friday, December 14, 2007, 4:35:08 PM, you wrote:
Hello!
As we all know, PHP 4's general releases will stop being made at the end
of the year. We've
Hello Alexey,
and for that reason we should do it! Can't Wez simply apply this?
marcus
Sunday, December 16, 2007, 3:22:40 PM, you wrote:
On 12/16/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:
I think the problem there is that this syntax wouldn't support external
variables, and without
Hello Stanislav,
I do not see anything broken here. All I see is discussing a patch to
death just because it doesn't do what everybody wants.
marcus
Monday, December 17, 2007, 6:14:22 PM, you wrote:
and for that reason we should do it! Can't Wez simply apply this?
I think we saw
Hello Dharmanna,
your account is activated :-)
marcus
Tuesday, December 18, 2007, 6:01:12 AM, you wrote:
Another reminder for CVS id .
I have been working with Raghubansh Kumar Zoe Slattery. Some of my test
cases have already been committed with the help of Raghubansh. I have been
Hello Stanislav,
and you did it again :-) Not working? What the hell are you talking of?
We can easily make it working with whatever feature set we want. We do not
support any feature ever thought of for everything in PHP. For instance
our object model has no abstract with default body, no MI,
Hello Derick,
to stick with our announced plan, can we release this in 2007?
marcus
Thursday, December 20, 2007, 1:43:18 PM, you wrote:
Hello!
I packed PHP 4.4.8RC1 today, which you can find here:
http://downloads.php.net/derick/
Please test it carefully, and report any bugs in the bug
Hello David, Lukas,
this is all bullshit! In PHP we simply grant the stuff to the PHP project
by putting it under the copyright of 'The PHP Group'. That is all that
should ever be necessary. And to Lukas, you either violated a signed
agreement here by telling us stuff you learned while being
Hello Stanislav,
there is nothing to discuss here, unless you personally keep insisting on.
We have lived pretty damn good without any such thing. And alone the fact
that requiring an NDA to be signed will kick out core developers should be
enough for you to ever know. Unless you prefer to get
Hello Stanislav,
whom are you helping? A potential CLA?
In the meantime *I* only wonder that none of the original PDO inventors has
any clue what is going on - well besides Wez of course who joined efforts
after the first PDO implementation.
Thursday, December 20, 2007, 8:40:31 PM, you wrote:
Hello Stanislav,
since when has anything in PHP core required a CLA? And whay change that now?
marcus
Thursday, December 20, 2007, 6:59:53 PM, you wrote:
this is all bullshit! In PHP we simply grant the stuff to the PHP project
by putting it under the copyright of 'The PHP Group'. That
Hello Solar,
thanks again for offering this. What we require is to have the PHP License
in the code. If you are fine with this we will gladly replace the existing
code with yours. You can of course put more header information in there to
stress out further that it is your code and where it can
Hello Sam,
we actually thought of doing it, yes. And apparently I wanted to do
something but I didn't find any time in the past year to be honest.
marcus
Thursday, December 27, 2007, 7:17:16 PM, you wrote:
I read that type hinting for function return values was going to be
implemented, is
Hello Andrew,
SPL simply allows two things:
a) a stack that hooks into __autoload
b) a default implementation that may be used (with ot without the former)
We try to group functionality into extensions where we seem fit. And by the
time I implemented spl_autoload stuff it made sense to put it
Hello Ryusuke,
generally I like both. But could you provide separate patches?
marcus
Friday, December 28, 2007, 5:45:03 PM, you wrote:
any idea about the possibility of hash conflict?
How about this patch?
http://www.opendogs.org/pub/php-5.3dev-071228a.patch
This patch is PHP 5.3
Hello Johannes,
I agree with Pierre here. How about finally making SPL built in always
like ext/standard?
marcus
Monday, December 31, 2007, 7:31:40 PM, you wrote:
On Dec 30, 2007 6:58 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Andrew,
SPL simply allows two things:
a) a stack
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.
marcus
Friday, January 4, 2008, 5:53:56 PM, you wrote:
On Jan 4,
Hello Gregory,
Saturday, January 5, 2008, 4:25:00 AM, you wrote:
Index: run-tests.php
===
RCS file: /repository/php-src/run-tests.php,v
retrieving revision 1.226.2.37.2.35.2.10
diff -u -r1.226.2.37.2.35.2.10 run-tests.php
---
Hello Stanislav,
tha makesw three then already, how about we ask around again?
Ryusuke, can you please start a new '[RFC] Square brackets shortcut' thread
to collect opinions and pass along the patch for that?
I like the anonymous function patch too. It is clean and simple. Maybe you
want to
Hello Cristian,
Sunday, January 6, 2008, 7:42:58 PM, you wrote:
2008/1/5, Alain Williams [EMAIL PROTECTED]:
1 and 1 should both be acceptable to type hint 'int'.
No way, 1 is an string, not an integer.
Well that is the whole issue here. In PHP 1 is pretty equal to 1 in any
function. It
,
On Sun, 2008-01-06 at 21:24 +0100, Marcus Boerger wrote:
That said I would only agree to type hints if we make them respect existing
PHP conversion rules.
Which we can't really do. Think about Mikko's example:
$b = '5';
function foo( int $a )
{
echo gettype( $a );
}
foo( $b );
echo
12b to be used as 12 even. Oh screw us all :-)
marcus
Sunday, January 6, 2008, 9:53:10 PM, you wrote:
Hi Marcus,
On Jan 6, 2008 9:24 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
That said I would only agree to type hints if we make them respect existing
PHP conversion rules.
That can
like (a) the best.
Regards,
2008/1/6, Marcus Boerger [EMAIL PROTECTED]:
Hello Stanislav,
tha makesw three then already, how about we ask around again?
Ryusuke, can you please start a new '[RFC] Square brackets shortcut' thread
to collect opinions and pass along the patch for that?
I
name.
- Serial number and file informations make the name unique.
- char anon_key_buf[32] is long enough because
`snprintf(anon_key_buf, 32, ZEND_ANON%llu, (unsigned long
long)UINT64_MAX)'
returns 31.
Regards,
2008/1/6, Marcus Boerger [EMAIL PROTECTED]:
Hello Stanislav,
tha makesw
Hello Sam,
and here goes the problem, some people here understand the issue a bit
better than others and some people actually do the work because they can and
are being respected for - just by their experience...
Either way there is a clear functional difference. The old array style
syntax
Hello Antony,
+1 + thanks, it is simply a ppain in th eass to develop with
7) It alone is responsible for at least 10% slowdown.
marcus
Monday, January 21, 2008, 3:38:00 PM, you wrote:
6 reasons why we must to get rid of The Switch ASAP
Hello Tomas,
you're point being? Without the requested change here you would have one
more version, resulting in PHP 5.*, PHP 6.*-unicode, PHP6.*-native.
marcus
Monday, January 21, 2008, 6:22:32 PM, you wrote:
5) this is yet another reincarnation of ze1_compatibility switch.
Which is the
Hello Ditesh,
there are indeed. Both allow to compress the Phar entries. Personally I
prefer bz2 but as said earlier that only wroks with CVS code right now.
marcus
Friday, January 25, 2008, 4:48:57 PM, you wrote:
On Thu, 2008-01-24 at 09:14 -0800, chris# wrote:
I can't help but notice the
Hello chris,
there is no stability issue with gz and 5.2.6 will fix the last issue with
bz2/phar interaction. The actual reason for both being off is that they
reside in pecl and the assumption is that pecl modules are not present by
default. Simply add those two extensions and build again.
Hello Sam,
as others pointed out results in unwanted entries being present. So the
second time you use ifsetor on those entries, you do not get the default
back but rather NULL. Actually in your implementation you never get the
default back.
Please read the archives, all of this has been
Hello Robin,
expected behavior. The static property is inherited to the sub class. As
that subclass repeats the declaration with a different visibility you simply
change the visibility. If the base class had the property defined as private
then the property is private to that specific class and
Hello Steph,
so you mean we do not have to confuse our uses by solution 2a becasue we
only have the minimum subset of zip in phar that ohar actually needs?
marcus
Monday, January 28, 2008, 7:01:42 PM, you wrote:
Hi Marcus,
1. include phar in core
2.a. add ext/zip compatible functions
Hello Robin,
I checked it out in more detail and it is indeed broken as in it is not
consistent:
[EMAIL PROTECTED] PHP_5_3]$ php -r 'class A { protected static $p=1; } class B
extends A { protected static $p=2; } ReflectionClass::Export(B);'
- works == 2 properties
- but should fail because of
Hello Gregory,
My point of view is this action list:
1. include phar in core
2.a. add ext/zip compatible functions and replace ext/zip
2.b. change ext/zip to use zip lib of pahr and add stream support
3. drop ability to disable spl
I have no preference between 2a or 2b. Though
Hello Pierre,
the account is approved (whoever did it, I don't know).
marcus
Tuesday, January 29, 2008, 4:33:29 PM, you wrote:
Hi,
On Jan 17, 2008 12:00 PM, Pierre [EMAIL PROTECTED] wrote:
On Jan 17, 2008 3:36 AM, Mário Soares [EMAIL PROTECTED] wrote:
I posted in the pecl-dev malling
Hello Mike,
not that I have any benchmarks. But I have one thing you might want to
know. You extract a phar and map it to the extracted folder. That is any
operation that would normally end up in the phar then ends up in direct file
access. Doing so would add a tiny overhead for loading the
Hello Robin,
i've verified your account an am giving you access rights bow. Feel free
to commit as soon as you see the 'avail' update. Thanks for the test we've
got so far.
marcus
Wednesday, January 30, 2008, 11:14:41 AM, you wrote:
Contributing test cases (phpts). I have sent some tests
Hello Scott,
actually it was a bug. We, sorry I, did not spot this in earlier versions.
Now saying you rely on a bug in PHP 5 to be able to execute PHP 4 code
simply does not work.
marcus
Wednesday, January 30, 2008, 11:48:50 AM, you wrote:
Hi all,
Static callbacks behave differently
Hello internals, pecls
interesting, when comitting to php-src and pecl the mail goes to pecl :-(
Hello Steph,
since you found the issue, how about you test whether it works correct
now? For development I basically experimented with stuff like this:
php -r '$i=new
Hello Masaki,
unfortunately we cannot use any C99 extension and must stick to C89.
Also I do not really see a reason to use ... in the actual function
definition. The reason for the way the function is written, is to avoid
using emalloc. Now, we can probably live with up to four parameters for
Hello all,
So after the initial uproar on last week's attempts to put parts
of PHP development under the terms of a CLA, a bunch of us actually
spent some time in finding solutions for one way or the other. I
don't want to bother you with more details on the why.
One thing for certain, we want
Crosspost, hopefully silencing this issue for 5.*
AND 6 will have an E_WARNING or even an E_ERROR on this.
helly Fri Feb 1 21:27:55 2008 UTC
Modified files: (Branch: PHP_5_3)
/php-src/ext/standard type.c
/ZendEngine2zend_API.c zend_API.h
Log:
Hello Lukas,
only E_ERROR is fatal and reserved for when the engine cannot continue
execution.
marcus
Friday, February 1, 2008, 11:15:08 PM, you wrote:
On 01.02.2008, at 23:05, Pierre Joye wrote:
2008/2/1 Marcus Boerger [EMAIL PROTECTED]:
Crosspost, hopefully silencing this issue for 5
want too.
marcus
Saturday, February 2, 2008, 12:11:07 AM, you wrote:
Cristian Rodriguez wrote:
2008/2/1, Marcus Boerger [EMAIL PROTECTED]:
- Fix callable/static mess, the following will now all result in a
E_STRICT
. binding a dynamic function as a static callback
. static call
Hello Wez,
keeping the discussion on this list is a major mistake. And it is actually
the reason why everyone outside this list is against it. And whether you
read blogs or not does not interest anybody at all - unless you are going to
comment on every single blog that mentions PHP and CLA. So
Hello Steph,
all we need is to extend the PECL database with a license type field and a
CLA flag. Nothing else is required at that end. But we should still move as
much from php-src/ext to pecl as we can.
marcus
Saturday, February 2, 2008, 6:36:23 PM, you wrote:
If we're going the PECL
Hello Pierre,
amen!, You're noted as no. But other people see a reason and continue to
discuss *please* without you. We will take your vote in as no when it comes
to voting if ever. If you are interested in explanations then I suggest you
read all mails and blogs again until you understand the
Hello Steph,
what I want is php-src as minimum you can depend on. And php-default as
release managers playground. The RM can then say what he thinks is mature
enough to make it into a release.
marcus
Saturday, February 2, 2008, 9:14:12 PM, you wrote:
Hi all,
Just so's Marcus and I don't
Hello Pierre,
basically you are saying that zip would not have been used by anybody if
you hadn't forced us by mail bombardment to include it. So now I am
wondering why you care so much what goes in and what goes out? After all it
is the RMs decision. And we might get asked or not.
marcus
to jump into here
Marcus Boerger wrote:
| I spoke about you as you left no room for discussions. You are not willing
| to compromise in any way, nor are you willing to be productive in any way.
| So there is no way in keeping you in discussions, is there? And no, we are
| no having any
Hello Lukas,
Sunday, February 3, 2008, 10:56:08 AM, you wrote:
On 03.02.2008, at 10:16, Lester Caine wrote:
Steph Fox wrote:
Hi Marcus,
what I want is php-src as minimum you can depend on. And php-
default as
release managers playground. The RM can then say what he thinks is
mature
Hello Lukas,
same here. I proposed php-src with absolute minimum. And php-default as
the release state. Where the RM has the last say in what goes in and what
not.
The rest of the discussion is once again how easy it is to get more than the
default distribution onto hosters machines. But a) I
Hello Ben,
None of this is necessary though. What I proposed was moving extension
development from php-src to PECL an dthen bundle what we see fit into the
distribution just as we do now, whith the RM having the last say what goes
in and what not. In my proposal we would only put stuff into
5, 2008 11:14 PM, Richard Lynch [EMAIL PROTECTED] wrote:
On Fri, February 1, 2008 7:33 pm, Pierre Joye wrote:
On Feb 2, 2008 1:52 AM, Gregory Beaver [EMAIL PROTECTED] wrote:
Rasmus Lerdorf wrote:
Cristian Rodriguez wrote:
2008/2/1, Marcus Boerger [EMAIL PROTECTED]:
- Fix callable
Hello Pierre,
yeah nice idea. I am wondering if you might want to add the cvs tag, too?
E.g.: PHP_TAG = 'PHP_5_3'
marcus
Friday, February 8, 2008, 1:52:27 PM, you wrote:
Hi,
Testing the PHP version can be much easier and faster if the versions
details were exposed via the constants, like
]|
| Jani Taskinen [EMAIL PROTECTED]
|
+ | Marcus Boerger [EMAIL PROTECTED] |
+--+
*/
/* $Id: zend_ini_parser.y,v
Hello Gregory,
hmm, and i thought i was doing it correctly now. So I need to
reinvestigate things. Thanks fo rthe heads up.
marcus
Monday, February 11, 2008, 6:57:09 AM, you wrote:
Gregory Beaver wrote:
Hi Marcus,
FYI, this change:
Hello Felipe,
nice work. The others already talked about the implications. And given
what I can only chime in. Since so far people think it is a ok for 5.3 I
wonder if we should not continue with moving towards the new parameter
parsing API. In the end the best would be to get rid of the old
Hello Felipe,
I do not like readonly, instead I would prefer a version where read and
write have separate visibility. And actually your idea seems to prevent a
second write to the value, using NULL as for detection means. Now what
happens is that a) a property that has a default value will
Hello Jani,
it is a queestion of how easy i can accomplish things. In fact I do not
want to set variables in the ini file first. I want PHP to generate them
for me automatically.
marcus
Monday, February 11, 2008, 12:06:38 PM, you wrote:
On Mon, 2008-02-11 at 10:32 +0100, Marcus Boerger
Hello Pierre,
Monday, February 11, 2008, 10:31:17 PM, you wrote:
Hi Marcus,
Nice addition, it is really handy and it'll help to solve the php.iniS mess :)
On Feb 9, 2008 3:33 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
attached is a patch against 5.3 that brings three feature
additions
Hello Gregory,
It is fixed now.
marcus
Monday, February 11, 2008, 6:57:09 AM, you wrote:
Gregory Beaver wrote:
Hi Marcus,
FYI, this change:
http://cvs.php.net/viewvc.cgi/php-src/ext/spl/spl_directory.c?view=diffr1=1.146r2=1.147
breaks about 20 tests in phar, it's a potentially
we can add those two as consts (Pierre?).
regards
marcus
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 09, 2008 6:33 AM
To: PHP Internals List
Subject: [PHP-DEV] [RFC] Conditional INI support
Hello PHPlers,
attached is a patch
Hello Dmitry,
shouldn't this be like in C/C++ where a non existing value is treated like
an empty string which behaves like false in boolean evaluations?
marcus
Friday, February 15, 2008, 11:25:42 AM, you wrote:
#if defined(PHP_MAJOR_VERSION) PHP_MAJOR_VERSION = 6
extension=unicode.so
Hello Jani,
Friday, February 15, 2008, 10:30:15 AM, you wrote:
b) I think usage of square brackets is not a good idea, because they are
commonly used to divide ini files into sections. Why not to use C
syntax? (#if...)
I'd prefer that syntax too, it would be much clearer than mixing the
Hello Pierre,
cool thx
marcus
Friday, February 15, 2008, 4:10:54 PM, you wrote:
Hi Marcus,
On Wed, Feb 13, 2008 at 5:26 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Also I reduced the number of added values to 'php.zts' and 'php.debug'.
Maybe we can add those two as consts (Pierre
Hello Lars,
thanks for doing the work. I'll apply the patch during next week. And yes
you should emit deprecation messages for use of INI settings that are going
to be dropped in 6.0.
marcus
Saturday, February 16, 2008, 2:14:54 AM, you wrote:
Hi all,
I've heard that E_DEPRECATED is still
.
- Steph
- Original Message -
From: Dmitry Stogov [EMAIL PROTECTED]
To: PHP Internals List internals@lists.php.net
Cc: [EMAIL PROTECTED]; Marcus Boerger [EMAIL PROTECTED]; Andi Gutmans
[EMAIL PROTECTED]; Jani Taskinen [EMAIL PROTECTED]
Sent: Friday, February 15, 2008 2:38 PM
Subject
Hello Felipe,
Tuesday, February 19, 2008, 4:21:20 AM, you wrote:
Hi.
Looking on Feature/Change Request, i have seen curious things, and i
think that them should issue any error message. See above.
---
Bug #39915 - Trying to access the index of an integer should throw a
warning:
Actual
Hello Stefan,
a userland copy'n'paste does not allow to reuse already compiled opcodes.
Traits do at least conceptionally.
marcus
Tuesday, February 19, 2008, 1:09:24 PM, you wrote:
Hi Mark,
If it doesn't affect performance *MUCH* then I'm all for it ! It can
bring better structure for
Hello Rasmus,
Tuesday, February 19, 2008, 2:45:15 AM, you wrote:
Larry Garfield wrote:
You also note that this mechanism has no runtime impact. That's
unfortunate,
because I'd find the ability to add methods to an object at runtime
conditionally based on some other value far more useful
Hello php,
looks good to me. See more detailed thoughts in separate mail resonses.
The biggest issue I see is finding a syntax everyone likes.
Personally I like everything but one tiny piece, that is you do '!method'
to ignore a method from a trait. Since renaming happens in a php array like
class and
nothing more or contain the code to generate output, probably some short,
flat procedural code. Then each of these files would get compiled and
cached. And loaded from those output generating files...
marcus
Tuesday, February 19, 2008, 4:59:19 PM, you wrote:
Marcus Boerger wrote:
Hello
Hello Lukas,
it doesn't work with opcode cashes. So I want at least an E_STRICT here.
And yes I mean what I wrote. That's why I wrote it.
marcus
Tuesday, February 19, 2008, 6:40:08 PM, you wrote:
On 19.02.2008, at 15:32, Marcus Boerger wrote:
In fact I'd love to issue a deprecated message
Hello Lars,
we could even go for include here if we wanted to avoid use as much as
adding a new keyword. Personally I don't mind using keywords for different
stuff as long as it cannot conflict. That is in this case true for both
include and use.
marcus
Tuesday, February 19, 2008, 9:31:29 PM,
Hello Stefan,
so at th eend of the day users will get renaming and will abuse it.
That said I am wondering if at the beginning we might want to do Traits
without aliasing and dropping. If we feel it gets necessary we probbaly
might want to support a syntax like:
'trait_method' = false
Hello Stanislav,
if we go the route of allowing that, then we have to do some protocl
checks. Meaning if a renamed/aliased method will become an implementation of
an abstract method then of course it has to be compatible. The beigger
problem I assume you have in mind as well is that replace
Hello Jochem,
good arguments. And good ideas. I'd favor 'posesses' then.
marcus
Tuesday, February 19, 2008, 9:54:09 PM, you wrote:
firstly, I'd like to reiterate the general sentiment
that Stefans RFC is blinding! (that's a good thing in this context ;-)
Marcus Boerger schreef:
Hello
Hello Stefan,
the biggest issue here is that renaming is still possible. So meanwhile I
think that the best approach would be to only allow a method to be inherited
as private. So instead of hiding a method completely you get it as a private
one. Thus if it collides with an interface you get an
Hello Lukas,
alright,
'foo as bar' is ok to me and does not even add a new keyword.
Ignore or any more keywords are bad and I also think that the correct
would be hide(ing). But as I further more explained it should really be
something that only marks a method as private if at all. That can
Hello Pierre,
Friday, February 22, 2008, 5:14:34 PM, you wrote:
Hi Lukas!
On Fri, Feb 22, 2008 at 4:41 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Hello all,
Let me briefly pick on poor David's (unfortunately I could have picked
any number of posts on any given day just as well)
.
[...]
2008/1/6, Marcus Boerger [EMAIL PROTECTED]:
[...]
I like the anonymous function patch too. It is clean and simple.
Maybe you
want to start a second '[RFC] Anonymous functions' thread with
that patch.
Can you also please add tests for both?
marcus
Best regards,
Marcus
--
PHP
Hello Andi,
I mentioned something along those lines as well. And I guess we both come
from the side that a) we think the feature as such is useful and b) needs to
be implemented in a way that we can use as much of the engine
infrastructure as possible and c) not interfere with the way PHP
Hello Lukas,
Thursday, February 21, 2008, 9:41:10 AM, you wrote:
On 21.02.2008, at 03:26, Andi Gutmans wrote:
a)
I think Traits should be able to act as a self-contained behavior
which can always be expected to work. For example if I want a
Counter behavior I would like that not to
,
2008/1/6, Marcus Boerger [EMAIL PROTECTED]:
Hello Stanislav,
tha makesw three then already, how about we ask around again?
Ryusuke, can you please start a new '[RFC] Square brackets
shortcut' thread
to collect opinions and pass along the patch for that?
I like the anonymous
Hello David,
Wednesday, February 27, 2008, 9:27:16 PM, you wrote:
Greetings, PDO community! My name is David Sceppa and I am a program
manager working at Microsoft on improving SQL Server for PHP data hosting.
Let me first just say that Microsoft is very interested in participating
in the
Hello Lukas,
Monday, February 25, 2008, 5:04:45 PM, Pierre wrote:
On Mon, Feb 25, 2008 at 3:59 PM, Derick Rethans [EMAIL PROTECTED] wrote:
On Sat, 23 Feb 2008, Lukas Kahwe Smith wrote:
Personally I prefer going with a wiki, because I do not have much
affection
with CVS for these kinds
Hello Lars,
I've approved your request but not given you any access rights up front.
I'll do so as you send more patches. Feel free to continue sending them
to me if you want.
Sunday, February 24, 2008, 4:34:21 PM, you wrote:
Continue my work on PHP and the Zend Engine, especially focusing
Hello Stefan,
Thursday, February 28, 2008, 8:30:48 AM, you wrote:
Hi,
Joshua Thompson schrieb:
Andi Gutmans wrote:
The following code shows a few things:
- local properties which can be used in self-contained functionality.
The storage is guaranteed to stay internal and will not clash
Hello Andi,
I agree with Stas about 'local' and actually his reasoning is why I
simply suggested 'private'. That also has the advantage that people already
know what it does.
marcus
Thursday, February 28, 2008, 5:14:17 AM, you wrote:
-Original Message-
From: Stanislav Malyshev
Hello Stanislav,
as much as what you say is true, it forces you to type a lot which is
error prone. So when you want to make a function public then you need to do:
function whatever() {
A::whatever();
}
And actually you have to repeat the protocol and there the fun begins. Not
to begin even
Hello Lukas,
you still cannot ignore basic inheritance or reuse rules. Protocols have
to be respected - E_FATAL, fix your code.
marcus
Wednesday, February 27, 2008, 1:49:58 PM, you wrote:
On 26.02.2008, at 04:19, Gregory Beaver wrote:
My only objection is that this introduces two new
Hello Christian, Stanislav,
Friday, February 29, 2008, 6:44:44 PM, you wrote:
Hi!
1) The current checks are IMHO too strict regarding default values for
parameters: An inheriting class can add default values to a parameter
without breaking the protocol:
class A { function foo($x) { ... } }
1 - 100 of 1702 matches
Mail list logo
