2020-09-22 14:51 GMT, guilhermebla...@gmail.com :
> This should answer your question:
> https://github.com/php/php-src/pull/947#issuecomment-224912697
>
Yes, indeed. "The reason comes due to how namespaces are implemented
in the language, where they only exist at compile time." Pity.
> On Tue,
This should answer your question:
https://github.com/php/php-src/pull/947#issuecomment-224912697
On Tue, Sep 22, 2020 at 7:38 AM Olle Härstedt wrote:
>
> 2020-09-21 21:50 GMT, Rowan Tommins :
> > On 21/09/2020 17:13, Michael Morris wrote:
> >> Next thing to consider - we have the problem of havin
2020-09-21 21:50 GMT, Rowan Tommins :
> On 21/09/2020 17:13, Michael Morris wrote:
>> Next thing to consider - we have the problem of having already used the
>> protected keyword in PHP, and honestly I prefer PHP's interpretation of
>> the
>> word.
>
>
> I think it's actually Java that's the outlie
On 21/09/2020 17:13, Michael Morris wrote:
Next thing to consider - we have the problem of having already used the
protected keyword in PHP, and honestly I prefer PHP's interpretation of the
word.
I think it's actually Java that's the outlier here: PHP's meaning of
"protected" corresponds dir
2020-09-21 16:13 GMT, Michael Morris :
> This sort of thing would be useful. Drupal and Symfony both mark methods in
> their libraries that aren't supposed to be used externally, but people do
> anyway and then they get mad at the framework developers when they decide
> to rearrange what are suppos
This sort of thing would be useful. Drupal and Symfony both mark methods in
their libraries that aren't supposed to be used externally, but people do
anyway and then they get mad at the framework developers when they decide
to rearrange what are supposed to be internal methods.
I wrote a userland
On 17/09/2020 13:28, Olle Härstedt wrote:
We have public, protected and private. Since PHP has no module system, we
have no qualifier to mark a class property as "private for this module".
One solution to this could be to add a new qualifier "internal", to make
properties public within the curren
On Sat, 19 Sep 2020, 09:20 Olle Härstedt, wrote:
>
> On Fri, 18 Sep 2020, 00:13 Mike Schinkel, wrote:
>
>>
>>
>> > On Sep 17, 2020, at 8:28 AM, Olle Härstedt
>> wrote:
>> >
>> > (NB: This idea is NOT about namespace visibility for classes,
>> interfaces or
>> > traits (already discussed here:
>
On Fri, 18 Sep 2020, 00:13 Mike Schinkel, wrote:
>
>
> > On Sep 17, 2020, at 8:28 AM, Olle Härstedt
> wrote:
> >
> > (NB: This idea is NOT about namespace visibility for classes, interfaces
> or
> > traits (already discussed here:
> https://wiki.php.net/rfc/namespace-visibility).
> > It's about
-- Forwarded message -
From: Olle Härstedt
Date: Fri, 18 Sep 2020, 11:23
Subject: Re: [PHP-DEV] Namespace-private class properties
To: Michał Marcin Brzuchalski
On Fri, 18 Sep 2020, 06:15 Michał Marcin Brzuchalski, <
michal.brzuchal...@gmail.com> wrote:
> Hi Olle
> On Sep 17, 2020, at 8:28 AM, Olle Härstedt wrote:
>
> (NB: This idea is NOT about namespace visibility for classes, interfaces or
> traits (already discussed here:
> https://wiki.php.net/rfc/namespace-visibility).
> It's about adding a *new* visibility qualifier, call it "internal", to
> ma
(NB: This idea is NOT about namespace visibility for classes, interfaces or
traits (already discussed here: https://wiki.php.net/rfc/namespace-visibility).
It's about adding a *new* visibility qualifier, call it "internal", to
make properties
private inside a namespace. The purpose is to make compo
Would that be so hard to distinguish in the parser? If it is, I'd be grateful
to know why.
We already have it in now. Changing it for cosmetics would break
existing code, and I have not yet understood for what benefit?
Touching back on what I mentioned earlier about PHP not having an inheren
Hello Christian
2010/8/10 Christian Kaps :
> Hi,
>
> is there any reason why no namespace separator constant exists in PHP. I
> have many cases where I concatenate strings to a namespace. This ends up
> with many class constants like const NS_SEPARATOR = '\\'. A default PHP
> constant would be a
Am 10.08.2010 22:07, schrieb Brian Moon:
> On 8/10/10 3:03 PM, Ferenc Kovacs wrote:
>> like DIRECTORY_SEPARATOR I guess
>>
>> Tyrael
>
> but, DIRECTORY_SEPARATOR is system dependent. The namespace separator
> is not. It is is always \.
>
OK. This is clear.
--
PHP Internals - PHP Runtime Develop
On 8/10/10 3:03 PM, Ferenc Kovacs wrote:
like DIRECTORY_SEPARATOR I guess
Tyrael
but, DIRECTORY_SEPARATOR is system dependent. The namespace separator is
not. It is is always \.
--
Brian.
http://brian.moonspot.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
On Tue, Aug 10, 2010 at 9:59 PM, Daniel Egeberg wrote:
> On Tue, Aug 10, 2010 at 21:56, Christian Kaps
> wrote:
> > Hi,
> >
> > is there any reason why no namespace separator constant exists in PHP. I
> > have many cases where I concatenate strings to a namespace. This ends up
> > with many clas
On Tue, Aug 10, 2010 at 21:56, Christian Kaps wrote:
> Hi,
>
> is there any reason why no namespace separator constant exists in PHP. I
> have many cases where I concatenate strings to a namespace. This ends up
> with many class constants like const NS_SEPARATOR = '\\'. A default PHP
> constant w
Hi,
is there any reason why no namespace separator constant exists in PHP. I
have many cases where I concatenate strings to a namespace. This ends up
with many class constants like const NS_SEPARATOR = '\\'. A default PHP
constant would be a better way to handle such cases.
Greetings,
Christian
Hi,
Em Seg, 2008-11-10 às 15:51 +0100, Timm Friebe escreveu:
> Hi,
> easy one: Two of the namespace tests in Zend/tests don't use the new ns
> separator yet:
>
> http://sitten-polizei.de/php/zend-test-ns-separator.diff
>
> - Timm
Opsss :) Thanks Timm!
--
Regards,
Felipe Pena
--
PHP Int
Hi,
easy one: Two of the namespace tests in Zend/tests don't use the new ns
separator yet:
http://sitten-polizei.de/php/zend-test-ns-separator.diff
- Timm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marshall Greenblatt wrote:
> Hi Stas, and All,
>
> I understand that there is a strong desire for this thread to be dead.
> However, after reading this and all related threads and wiki, I find that
> one item is still unclear, at least to me.
>
> On Mon, Oct 27, 2008 at 6:27 PM, Stanislav Malyshe
Hi!
Well, its not like the person is getting Y when he is expecting X. Both
classes have the same name after all, so there is some relation between
They don't have the same name - two classes can't have the same name.
And "relation" is definitely not enough - you really do not want to get
g
Hi!
ok, they have the same non fully qualified named.
That's why we should have unambiguous resolution mechanism. You propose
to add one ambiguity on top of another.
want to get generic \Exception instead of \My\Very\Specific\Exception
- it would probably break all your error handling.
t
On 05.11.2008, at 21:24, Stanislav Malyshev wrote:
Hi!
Well, its not like the person is getting Y when he is expecting X.
Both classes have the same name after all, so there is some
relation between
They don't have the same name - two classes can't have the same
name. And "relation" is
Lukas Kahwe Smith wrote:
>
> On 05.11.2008, at 01:05, Stanislav Malyshev wrote:
>
>> Hi!
>>
>>> or in other words give the user the ability to specify when he wants
>>> the
>>> fallback to global and not doing a fallback to global per default.
>>> That way
>>
>> This would be quite complex thing si
On 05.11.2008, at 01:05, Stanislav Malyshev wrote:
Hi!
or in other words give the user the ability to specify when he
wants the
fallback to global and not doing a fallback to global per default.
That way
This would be quite complex thing since this way you can't be sure
which class get
Note that I say "try internal" because the only purpose behind allowing
this is to make it easier to use PHP's built-in functionality. Any
userspace stuff should be specifically \prefixed or imported via use.
And (yes) we need import for functions.
Greg
P.S. my mail server has been down for
Hi!
or in other words give the user the ability to specify when he wants the
fallback to global and not doing a fallback to global per default. That way
This would be quite complex thing since this way you can't be sure which
class gets loaded when you say, e.g., Exception - and thus, if you
Hello Gregory,
Tuesday, November 4, 2008, 5:15:35 PM, you wrote:
> Christian Schneider wrote:
>> Lukas Kahwe Smith wrote:
>>> one could also do
>>> 1) ns
>>> 2) global
>>> 3) autoload
>>
>> I'm in favour of this (if it avoids performance problems) as I don't see
>> a problem with giving global p
Hello Lukas,
Wednesday, November 5, 2008, 12:32:19 AM, you wrote:
> On 05.11.2008, at 00:12, Marcus Boerger wrote:
>>> classes:
>>> 1) try ns::class
>>> 2) autoload ns::class
>>> 3) fail
>>
>> Since we can stack autoload we could provide a c-level autoload
>> function
>> that does the default
On 05.11.2008, at 00:12, Marcus Boerger wrote:
classes:
1) try ns::class
2) autoload ns::class
3) fail
Since we can stack autoload we could provide a c-level autoload
function
that does the default lookup.
function global_autoload($name) {
if (($p = strrpos($name, '\\')) !== false) {
$
2008/11/4 Andrey Hristov <[EMAIL PROTECTED]>
> Ryan Panning wrote:
>
> use 'NsA\NsB\NsC\func_c()';
>>
>
> OMG That looks UGLY1
>
This is exactly the kind of comment that is both useless and pointless.
Could you please make sure that you have a valid point with a subject,
arguments, e
As you pointed out, there is no autoload for functions, so people are
accustomed to ensuring that all functions are loaded before usage. Am I
missing something?
Yes - you're missing the possibility of overriding, AKA naming collisions
between internal and userspace funcs/consts.
- Steph
-
On 04.11.2008, at 18:59, Gregory Beaver wrote:
#2 means we want to be able to access stuff like strlen() and
array_map() without any monkey business.
functions/constants:
1) ns\func or ns\const
2) internal func\const
3) FAILBOAT
Right, for the most part people will want access to intern
Ryan Panning wrote:
use 'NsA\NsB\NsC\func_c()';
OMG That looks UGLY1
$obj = new NsA\NsB\ClassB;
$obj->methodB();
func_c();
?>
Best,
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Steph Fox wrote:
IT will break the code from everybody who doesn'T expect such a flag
exists and the average application user won't know and jsut see errors
which "randomly" occur.
Erm, how is that going to happen?
This is basically a tighter setting that can *optionally* be used and
should *
Hi Greg,
By doing the resolution I've suggested (and Stas, incidentally, was the
first to suggest this):
classes:
1) ns\class
2) autoload ns\class
3) FAILBOAT
functions/constants:
1) ns\func or ns\const
2) internal func\const
3) FAILBOAT
We get the best of #1 and the best of #2, and it makes
Hi Stefan,
Dev writes a script, uses autoload, overrides global class.
> Distributed to user, that has ns.lookup=On as you propose, user borks
> his
> install, lacks the file containing the class, gets the global class ->
> obscure error messages because of nonexisting methods in places
> unr
Lukas Kahwe Smith wrote:
>
> On 04.11.2008, at 17:15, Gregory Beaver wrote:
>
>> In other words, it is perfectly all right to have a different name
>> resolution for classes than we have for functions and constants because
>> of this different expectation. It is dangerous to fallback for classes
On Tue, 2008-11-04 at 16:48 +, Steph Fox wrote:
> >> What am I missing?
> >
> > That INI is the worst we could do. Because it prevents from writing
> > portable code.
>
> This particular INI doesn't prevent anyone writing portable code. It simply
> gives the option of a 'tighter' development
First, I want to say thanks for determining the best separator. Even
though it's not what everyone would like, it's what would work best.
Second, sorry for starting a new thread. To me, continuing the
resolution discussion in the "namespace separator and whining" isn't the
correct place.
Thi
On Tuesday 04 November 2008 18:27:43 Steph Fox wrote:
> Hi Stefan,
>
> > Dev writes a script, uses autoload, overrides global class.
> > Distributed to user, that has ns.lookup=On as you propose, user borks his
> > install, lacks the file containing the class, gets the global class ->
> > obscure e
Hi Stefan,
Dev writes a script, uses autoload, overrides global class.
Distributed to user, that has ns.lookup=On as you propose, user borks his
install, lacks the file containing the class, gets the global class ->
obscure error messages because of nonexisting methods in places unrelated
to
t
On Tuesday 04 November 2008 17:44:50 Steph Fox wrote:
> We could have an INI_SYSTEM switch.
>
> ns.lookup=Off
>
> means you _have_ to prefix because otherwise resolution will fail with a
> fatal error, but
>
> ns.lookup=On
>
> means that anything not prefixed and not local goes through the full
> l
IT will break the code from everybody who doesn'T expect such a flag
exists and the average application user won't know and jsut see errors
which "randomly" occur.
Erm, how is that going to happen?
This is basically a tighter setting that can *optionally* be used and should
*always* be used in
What am I missing?
That INI is the worst we could do. Because it prevents from writing
portable code.
This particular INI doesn't prevent anyone writing portable code. It simply
gives the option of a 'tighter' development mode.
- Steph
--
PHP Internals - PHP Runtime Development Mailing Li
Hello Steph,
Tuesday, November 4, 2008, 5:44:50 PM, you wrote:
> Hi Greg, all,
>> For this reason, the only resolution that we should be considering is:
>>
>> classes:
>> 1) try ns::class
>> 2) autoload ns::class
>> 3) fail
>>
>> functions/constants:
>> 1) try ns::function/ns::const
>> 2) try in
Hi Greg, all,
For this reason, the only resolution that we should be considering is:
classes:
1) try ns::class
2) autoload ns::class
3) fail
functions/constants:
1) try ns::function/ns::const
2) try internal function/const
3) fail.
I see this as giving priority to library authors rather than
On 04.11.2008, at 17:15, Gregory Beaver wrote:
In other words, it is perfectly all right to have a different name
resolution for classes than we have for functions and constants
because
of this different expectation. It is dangerous to fallback for
classes
prior to autoload, but it is not
Christian Schneider wrote:
> Lukas Kahwe Smith wrote:
>> one could also do
>> 1) ns
>> 2) global
>> 3) autoload
>
> I'm in favour of this (if it avoids performance problems) as I don't see
> a problem with giving global priority over autoload.
Hi,
This is the current name resolution. The proble
Hello Internals,
with many thanks to Greg we now have settled on \ as the namespace
separator. The next topic on the agenda is name resolution:
http://wiki.php.net/rfc/namespaceresolution
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
Lukas Kahwe Smith wrote:
> one could also do
> 1) ns
> 2) global
> 3) autoload
I'm in favour of this (if it avoids performance problems) as I don't see
a problem with giving global priority over autoload.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
On 31.10.2008, at 19:02, Lukas Kahwe Smith wrote:
Hi
I have tried to collect the various opinions on resolution order
into a single RFC:
http://wiki.php.net/rfc/namespaceresolution
Proactive damage control:
I have also included some discussion on how the removable of
function/constants w
Hi
I have tried to collect the various opinions on resolution order into
a single RFC:
http://wiki.php.net/rfc/namespaceresolution
Proactive damage control:
I have also included some discussion on how the removable of function/
constants would affect the question of namespace resolution orde
Hi!
What, if any, performance penalty should we expect with the proposed
namespace changes when executing existing code that does not use
namespaces? Do we need to change existing namespace-free code in order
If you don't use namespaces, none I guess (well, compiling would be a
little slow
Hello Greg,
thanks for finalizing this.
marcus
Sunday, October 26, 2008, 4:37:37 PM, you wrote:
> Hi all,
> Let me make this brief: there will be lots of complaining about the
> namespace separator.
> Stop. Now.
> It serves no possible useful purpose. If you want to discuss why this
> wa
Hello marius,
typical slashdot php artical. 'PHP is the worst crap ever - god bless
perl' The issue in this case is a confused user. See other mails to
do it right and an archive of thousands of mails discussing the topic (and
no, I am not kidding about that amount). And I have more personal
Hi Stas, and All,
I understand that there is a strong desire for this thread to be dead.
However, after reading this and all related threads and wiki, I find that
one item is still unclear, at least to me.
On Mon, Oct 27, 2008 at 6:27 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>
> And how
Josh Davis wrote:
> 2008/10/27 Stanislav Malyshev <[EMAIL PROTECTED]>:
>
>> 1) check for namespaced\classname
>> 2) try to autoload namespaced\classname
>> 3) fail
>
> Ok, that makes some sense wrt your position, which I originally
> interpreted as namespace/internal/autoload.
>
> You want to fo
On 27.10.2008, at 23:27, Stanislav Malyshev wrote:
this is how PHP got its huge userbase. we let people grow with
their needs.
And how exactly it serves the needs of people by secretly making
their applications orders of magnitude slower, and then saying "oh,
that's because you failed to
Hi!
just the same reason as you can use a constant without initialization.
out of the box PHP does not try to be a teacher. it lets you write you
Constant without initialization doesn't lead to any problems. This one
does.
this is how PHP got its huge userbase. we let people grow with the
On 27.10.2008, at 23:01, Stanislav Malyshev wrote:
Hi!
this seems like a very good idea to me. this way things default to
"just work" (which imho is the PHP spirit), while its brain dead
easy to detect misuse.
They not "just work" - they "work" in a wrong way (not usable in any
practic
Hi!
this seems like a very good idea to me. this way things default to "just
work" (which imho is the PHP spirit), while its brain dead easy to
detect misuse.
They not "just work" - they "work" in a wrong way (not usable in any
practical application). And E_NOTICE is a non-solution here - i
On 27.10.2008, at 22:27, Sean Coates wrote:
You want to force users to use the full name at all times. IOW, you
want to sacrifice convenience for performance.
(chiming in because it seems that we're overlooking something
obvious here)
If it comes down to this, I'd prefer to see an E_NOTI
You want to force users to use the full name at all times. IOW, you
want to sacrifice convenience for performance.
(chiming in because it seems that we're overlooking something obvious
here)
If it comes down to this, I'd prefer to see an E_NOTICE for the "bad
performance" use, though I do
2008/10/27 Stanislav Malyshev <[EMAIL PROTECTED]>:
> 1) check for namespaced\classname
> 2) try to autoload namespaced\classname
> 3) fail
Ok, that makes some sense wrt your position, which I originally
interpreted as namespace/internal/autoload.
You want to force users to use the full name at a
Hi!
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) check for internal classname
How would you reorder those?
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) fail
...but didn't you say "one time is enough"? According to your own
log
2008/10/27 Stanislav Malyshev <[EMAIL PROTECTED]>:
>> Then, if we assume that most people will use the global namespace
>> without prefixing it, what would be the best resolution order for
>> them? (you didn't mention it in your previous message)
>
> Using the prefixed names.
I'm sorry but I stil
Hi!
Then, if we assume that most people will use the global namespace
without prefixing it, what would be the best resolution order for
them? (you didn't mention it in your previous message)
Using the prefixed names.
People who care about performance are supposed to profile their
code... I g
2008/10/27 Stanislav Malyshev <[EMAIL PROTECTED]>:
> Actually, one time is enough, as it can bring an application from
> essentially zero disk accesses (with bytecode caching) to multiple disk
> accesses (to traverse full include path to exhaust all autoloading
> capabilities).
So we're talking a
It doesn't take a lot to kill an application if using internal class causes
__autoload to run for a non-existing user class.
Neither caches not optimizations can avoid that, as you can't have something
cached which doesn't exist.
In my autoloader for example, an existing user class is resolve
Hi!
- you use an internal class many, many times (as the overhead from a
handful of invocations would be negligible)
Actually, one time is enough, as it can bring an application from
essentially zero disk accesses (with bytecode caching) to multiple disk
accesses (to traverse full include pa
2008/10/27 Rodrigo Saboya <[EMAIL PROTECTED]>:
> I agree with Stas. It's better to force people to actually reference their
> classes/functions/constants correctly and get better performance than
> getting unclear slowdowns.
If I'm not mistaken, you only experience any noticeable slowdown if
all o
Stanislav Malyshev wrote:
Hi!
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) check for internal classname
That's the wrong way to do it - it means every time you mention the
internal class name without prefixing it with \ you get exhaustive
autoloading search a
Hi!
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) check for internal classname
That's the wrong way to do it - it means every time you mention the
internal class name without prefixing it with \ you get exhaustive
autoloading search and nothing tells you about
Hannes Magnusson schrieb:
> What exactly are you expecting other then the various wiki entries
> and README.namespaces in CVS?
Right, various sources of information that are not neccessarily in
sync and/or up to date.
--
Sebastian Bergmann http://sebastian-bergmann.de
On Mon, Oct 27, 2008 at 15:09, Sebastian Bergmann
<[EMAIL PROTECTED]> wrote:
> Lukas Kahwe Smith schrieb:
>> Now the people that were not able to attend this IRC meeting can
>> either accept that there was a sufficient number of people to make
>> a final decision on something that everybody (obviou
Greg Beaver schrieb:
>> It was mentioned on IRC that internal functions have to be
>> prefixed with \ when used in a namespaced file. Without a fallback.
>
> This is not true, and the unit tests demonstrate that
Thank you for clearing this up.
> 1) check for namespaced\functionname
> 2) check
Greg Beaver schrieb:
> I stand by my obvious public intent with the multiple emails, RFCs and
> patches I have sent.
Just to make it clear: I appreciate your effort and work on namespaces,
but AFAICS there is no single/complete RFC, only bits and pieces
(problems with the current implementation
Lukas Kahwe Smith schrieb:
> Now the people that were not able to attend this IRC meeting can
> either accept that there was a sufficient number of people to make
> a final decision on something that everybody (obviously also people
> who did not attend the meeting) had plenty of time to make the
William A. Rowe, Jr. wrote:
> Greg Beaver wrote:
>
>> Hi all,
>>
>> Let me make this brief: there will be lots of complaining about the
>> namespace separator.
>>
>> Stop. Now.
>>
>
> And if you had the common decency not to change the thread-id and subject
> some on this list might respec
Now you can read the funny comments
http://developers.slashdot.org/developers/08/10/26/1610259.shtml
another thing about it is that if you search for namespace separator on google
it gives you php related discussions
so it must be something important
http://www.google.com/search?q=namespace sepa
William A. Rowe, Jr. wrote:
> Greg Beaver wrote:
>> Hi all,
>>
>> Let me make this brief: there will be lots of complaining about the
>> namespace separator.
>>
>> Stop. Now.
>
> And if you had the common decency not to change the thread-id and subject
> some on this list might respect the spirit
Greg Beaver wrote:
> Hi all,
>
> Let me make this brief: there will be lots of complaining about the
> namespace separator.
>
> Stop. Now.
And if you had the common decency not to change the thread-id and subject
some on this list might respect the spirit of your plea.
--
PHP Internals - PHP
Yes, it does not mean that I was able to actually attend the meeting.
Because... oh wait. It wasn't important to you.
OK OK I'm not going to push this publicly. Just pointing out that most of
us
keep irc logs.
Preaching by example.
I didn't want to push this publicly, Pierre. Remember tha
Hi,
I'm not sure what's the hell is going on with you and Step,
OK, Pierre. You got us. Greg and I have been secret lovers for the last 5
years and we've been planning to take over php.net the whole of that time.
but if we
can't answer to any of your mails without being accused of personal
hi Greg,
On Sun, Oct 26, 2008 at 3:01 PM, Greg Beaver <[EMAIL PROTECTED]> wrote:
> Go ahead and attack my character if you feel it serves some purpose and
> benefits PHP. I on the other hand will continue to post actual
> solutions, patches and discuss them.
I'm not sure what's the hell is goin
On Sun, Oct 26, 2008 at 2:37 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> Hey Pierre,
>
>>> You were actually online throughout it, and were notified that it was
>>> happening at the start. In fact you were the first person to blog the
>>> outcome of the meeting.
>>
>> "I'm" always online, bot/proxy.
Pierre Joye wrote:
> @Greg and Steph: Private discussions are bad. Or are you trying to say
> that this list can't be used as a discussion platform (even heated)?
> If we like to have a developer only list, let do it, but keep things
> in the public area, that's the only way to keep our decision p
On Sun, Oct 26, 2008 at 22:19, Pierre Joye <[EMAIL PROTECTED]> wrote:
> To make my point more clear: I respect the decision even if I'm not
> completely happy about it
As do I. So lets kill this thread, unless you want the cool slashdot
guys to post more FUD referencing this thread.
-Hannes
--
On Sun, Oct 26, 2008 at 2:24 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> Hi Pierre,
>
>> Excuse me but while the idea to have an online meeting was great,
>> sending a mail to ask to attend an online meeting 24 hours before and
>> on a Friday was not a wised choice. I would have participated too if
On 26.10.2008, at 22:19, Pierre Joye wrote:
To make my point more clear: I respect the decision even if I'm not
completely happy about it (that's what we call a compromise). But my
comment to Greg and Steph was about the danger of abusing of private
discussions not about having held this meetin
Hi Pierre,
Excuse me but while the idea to have an online meeting was great,
sending a mail to ask to attend an online meeting 24 hours before and
on a Friday was not a wised choice. I would have participated too if
it was during this week or the next weekend.
You were actually online througho
On Sun, Oct 26, 2008 at 2:11 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> As was evident from the discussions in the past weeks, a lot of people
> commented, most of which did not spend the necessary time to actually
> understand the issues at hand. Given that it did indeed make it impossible
On 26.10.2008, at 21:59, Pierre Joye wrote:
Hi Lukas,
On Sun, Oct 26, 2008 at 11:28 AM, Lukas Kahwe Smith <[EMAIL PROTECTED]
> wrote:
Sebastian, you have not participated in the discussion so far. Now
you post
a rumor you picked up on IRC into an already heated situation. You
do know
full
Hi Lukas,
On Sun, Oct 26, 2008 at 11:28 AM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> Sebastian, you have not participated in the discussion so far. Now you post
> a rumor you picked up on IRC into an already heated situation. You do know
> full well that it does not require you to point out
Sebastian Bergmann wrote:
> Greg Beaver wrote:
>> The decision is made, now I suggest everyone get busy actually trying
>> it out.
>
> How are we supposed to try it out? There is no updated implementation
> yet, and I would rather discuss a specification instead.
As Steph pointed out, I toiled
And I must agree with Sebastian: How do you test something that isn't even
implemented yet? :D
You apply the 'rough draft' patch against PHP_5_3 :D
http://pear.php.net/~greg/backslash.sep.patch.txt
As referenced in the original rfc for the backslash approach cited at
http://wiki.php.net/rfc/n
Lukas Kahwe Smith wrote:
On 26.10.2008, at 19:07, Sebastian Bergmann wrote:
Greg Beaver wrote:
The decision is made, now I suggest everyone get busy actually trying
it out.
How are we supposed to try it out? There is no updated implementation
yet, and I would rather discuss a specification in
1 - 100 of 352 matches
Mail list logo
