hi,
I just wanted to say about 'include' ... er no actually
I have this little thing with constant() which I asked about
on php-generals and the response from a couple of regulars
suggest it might be a bug, or more correctly, an inconsistency.
Jason Barnett wrote also:
tested with PHP 5.0.5-dev
Pawel Bernat wrote:
What is stupid with validating name before using it?
its inconsistent to trigger an E_WARNING when doing:
echo constant('CNST');
when:
echo CNST;
only triggers an E_NOTICE.
(assuming, in both cases that CNST is not defined).
IMHO it should at most trigger an E_NOTICE.
Derick Rethans wrote:
On Fri, 1 Jul 2005, Jochem Maas wrote:
echo constant('CNST');
when:
echo CNST;
only triggers an E_NOTICE.
(assuming, in both cases that CNST is not defined).
IMHO it should at most trigger an E_NOTICE.
Did you compare the output of the two statements
Derick Rethans wrote:
On Thu, 4 Aug 2005, Pasha Zubkov wrote:
Derick Rethans wrote:
It's a CVS problem - it doesn't resolve repository links with upd, only
on checkout.
Maybe sputid question, but why PHP stil use CVS instead of SVN?
How do you want to convert 1100 users instantly withou
Dear Internals,
class FooBar { public function foo() throws Exception {} }
function fooFoo() throws Exception {}
this came up on php-generals and I wondered if anyone had time/cared
to comment if it (as it does to me) seems like a good idea and/or whether it is
technically feasable. My t
Marcus Boerger wrote:
Hello Jochem,
lookup the archieves. We have long ago decided agains that.
I'll take your word on it. :-) (shame on me for not searching harder
before asking)
thanks for replying.
marcus
Friday, August 5, 2005, 2:26:04 PM, you wrote:
Dear Internals,
class Foo
Tobias Schlitt wrote:
Hi Johannes Schlueter!
On 08/08/05 14:50 you wrote:
The throw an Exception when SPL disabled and an InvalidArgumentException
when it is enabled.
That's senseless when writing applications that shall be version
independant. Just sticking to Exception should be fine.
Andi Gutmans wrote:
My the way, the performance argument wouldn't work because even if this
would be supported, we'd have to first "try" and load the class to make
sure we can actually check the instanceof, and only if the class doesn't
load then we would return false. So you won't save that st
for what its worth - brilliant :-)
aftering reading the remarks about perl6 (love the idea of
you guys winning that 'race' :-) I did a little reading, seems
perl6 is aimed to target Parrot... I remember there was discussion
about this for php, don't know if the idea died a lonely death or
was jus
)
personally I think its fantastic that you all are looking far ahead and
trying to plan/decide/figure out where its all going - especially in such an
open manner - I still think php is great, and trust it will become greater still
(not just the version number ;-)
Kinds Regards,
Jochem Maa
Andi Gutmans wrote:
Well $proxy would automagically support the interfaces of the aggregated
objects. And if there's a method you want to proxy to one rather the
other you could fine tune that. Anything more than that would be getting
into an OOP pissing contest which I don't feel like getting
Christian Schneider wrote:
Jochem Maas wrote:
I would see this as a optional addition to the syntax of interfaces...
i.e. everything works as before but you can add default function bodies
which would behave as if it was defined in each class that implements
the given interface.
if this is a
ly applicable to php - but hey it's what I know :-)
thanks for taking the time to answer (hope you all don't
mind to much)
kinds regards,
Jochem
Zeev
At 12:44 25/08/2005, Jochem Maas wrote:
in a totally non-academic and impure way I have always thought that it
would
be nice to be
Marcus Boerger wrote:
Hello Christian,
Thursday, August 25, 2005, 12:17:25 PM, you wrote:
Jochem Maas wrote:
I would see this as a optional addition to the syntax of interfaces...
i.e. everything works as before but you can add default function bodies
which would behave as if it was
Ilia Alshanetsky wrote:
IMHO this is a bad idea, if you really wanted to support NULL in a
particular case you, as a developer could do:
php -r '$n=NULL; foreach((array)$n as $v);'
Making NULL usage transparent where array is expects will lead to
difficult to debug code.
hi :-)
the warning fo
Jani Taskinen wrote:
On Thu, 27 Oct 2005, Jochem Maas wrote:
advanced code should be checking vars properly before using them and,
well,
for any given foreach loop there is often enough an 'if
(!count($array))'-like
statement to take care of the 'empty' case. and in cases
Mike Hall wrote:
Every developer at my company has experience this problem too, at one
point or another. We get it with Apache 1.3 and PHP 5.x. We've been
unable to figure it out. I thought I had it tied down to the gzip
output compression at one stage. But then it suddenly started working
ok
this is a php4-only problem right?
(or is the little test below insufficient to test the stated problem?)
THIS:
--
php -r '
class A { public $b; function __construct(B $b) { $this->b = $b;
$b->setA($this); } }
class B { public $a; function setA(A $a) { $this->a = $a; } }
$y
Stefan Esser wrote:
Hello,
with MD5 and SHA1 more or less broken, I have hacked together sha256() and
sha256_file(),
because people want a secure hashing function in plain PHP without the need for
3rd party
libraries like mhash.
assuming this is true then the built in session handler is pret
Rasmus Lerdorf wrote:
Derick Rethans wrote:
On Tue, 15 Nov 2005, Andrei Zmievski wrote:
Perhaps, but I would maintain that passing "123abc" and having it
interpreted
as 123 is still wrong.
Yeah, I lean that way too, although trailing whitespace should be
supported IMO.
I don't like ha
why does the engine care about the visibility of interface methods I declare?
I understand the argument that interface methods only have 'meaning' when
applied
as public methods of objects - but thats rather academic and personally I can
think of useful ways to abuse interfaces using protected me
Matthias Pigulla wrote:
why does the engine care about the visibility of interface
methods I declare?
I understand the argument that interface methods only have
'meaning' when applied as public methods of objects - but
thats rather academic and personally I can think of useful
ways to abuse in
Andi Gutmans wrote:
Please read the archives where discussions took place.
As you stated it would be "abusing" the notion of what interfaces ar
Take a look at abstract classes. That might help you.
Andi,
I read pretty much everything but the account requests on internals
(and have done sinc
I suggest a little more damage control is needed...
Steph Fox wrote:
Guys and guyess,
...
4. instanceof, is_a(), is_subclass_of(), catch
==
In PHP 5.0, is_a() was deprecated and replaced by the "instanceof" operator.
There were some issues with t
Note: this post contains a 'complaint' but its not aimed
at any one in particular, especially not Rasmus as he doesn't give
the impression of being much of an OO proponent at heart, and because
he repeatly seems to err on the side of practicality and caution
(as opposed to correctness for correctn
Christian Schneider wrote:
Jochem Maas wrote:
so I can only assume that the ability to declare ctor signatures have
been left in because they do no harm regardless of whether it is
'correct'.
If I remember correctly then one reason to have constructor signatures
is for object
Stanislav Malyshev wrote:
EK>>This might be from implementation/engine point of view, but from user's
EK>>perspective goto is much more limited. It can only happen within one
EK>>function.
That's good. PHP is a limited language - you can not do many things in PHP
that you can do in C, for examp
hi Stanislav,
Stanislav Malyshev wrote:
LS>>How is that different from "goto"?
I start to suspect you just skip what I am writing. Didn't I explain that
exception does not allow to jump to random points and goto does?
LS>>And if you can jump through 80% if your code via an exception while y
Sara Golemon wrote:
...
Your take is spot-on. This isn't an extension of functionality, just a
"numbered breaks with a name" which is something I've heard requested
from several corners (including @zend.com) as a "wouldn't it be nice..."
I wonder if the need for labelled breaks/continues
thanks for the explanation Sara, :-), as always your manner and ideas
are an example to the 'php core', 'we' (they) are lucky to have you :-)
Sara Golemon wrote:
what happens when I want to place a 'goto' label just before a while
or foreach
loop (upon which I haven't put a label)? I ask because
are you using ph4 or php5?
are you setting $this->this yourself or 'is it just there'?
Alan Pinstein wrote:
Hi all-
I've been trying to avoid circular references in some data import
scripts and finally figured out how to do it. However, I wanted to ask
you guys to make sure that what I'm do
Andi - your email client seems to be leaking :-)
Andi Gutmans wrote:
Hi Alan,
Generally speaking, if you create a circular reference (whether by
reference or by value), then you will have a "memory leak" until the end
of the request. This is not only true for objects (and circular
references
at the memory usage
of my script grows and grows (upto about 100Mb) - I figure it could do it
alot more efficiently, having some ammunition regarding how to tackle
such an issue (in general terms) would be a great benefit - given the
generic nature of the problem I believe many more developers
internals,
it may be a badly worded (and inappropriately directed) post BUT I can
categorically
say that php5+ does have problems with displaying errors under certain
circumstances - you see nothing anywhere regardless of ini/log/display settings.
I have had such issues since php.5.0.3beta, I ha
Daine Mamacos wrote:
I think I know what this is due to.
I have an autoloader in places for classes.
It seems that when a class is autoloaded, no matter what you do, it won't
bother throwing an error when it loads a class. It however just stops
processing. FULL STOP.
If the error is in the localf
Alan Pinstein wrote:
Your last post also indicates, that because the destructors are only
called
after script termination, the scope of an object is global, always.
Is this true?
This isn't true, at least empirically. Destructors are called when the
GC frees the object.
For many objects,
Stanislav Malyshev wrote:
>> Rest assured that this is not the bad kind of 'more complex' I believe
>
> I'm afraid I must disagree. The feature that was missing was to know the
> true calling class name. That was implemented. You can build from it,
> there's no need to add further complication to
Stanislav Malyshev wrote:
>> +1 for putting namespaces on the backburner and taking the time to
>> get it 100% right ...
>
> What's "100% right"? Any proposals (besides braces)?
I'll take a guess that you put alot of effort into the namespace implementation,
that's the only reason I can think of
+1 for putting namespaces on the backburner and taking the time to
get it 100% right ...
Stanislav Malyshev wrote:
>> some people like a "misguided" implementation of namespaces. The idea
>> of namespaces is to prevent collisions in USER land code, not turning
>> internal PHP classes into a pile o
Stanislav Malyshev wrote:
>> based on the reactions it has been recieving I would disagree. that is
>> not to say
>> that completing the baking process would not result in a wonderful
>> functional addition
>> to the language. I'm just advocating putting it on the backburner
>> until the cooking
>>
Stanislav Malyshev wrote:
>> You would now have to go through all ten autoloaders before you can
>> decide that no userspace class DateTime exists in any namespace, and
>> thus the PHP internal class DateTime may be used.
>
> Even one autoloader is bad enough to not even have to consider the case
Jani Taskinen wrote:
> On Thu, 2007-12-13 at 10:00 +0100, Derick Rethans wrote:
>> To to get back to the point of the noise on the lists - it's getting out
>> of hand, and I am afraid that if we don't solve this any time soon, the
>> lists will be useless for any sort of decent discussion and pro
Richard Quadling wrote:
> On 13/12/2007, Jochem Maas <[EMAIL PROTECTED]> wrote:
>> 1. most people reading the internals list already subscribed to general
>> 2. general is in no way suitable for the kind of discussion currently
>> occuring on internals - the diffe
Brian Moon schreef:
> Rashmi Badan wrote:
>> The test was trying to load mod_php between graceful restarts, i.e start
>> apache without mod_php, then modify the config file to load it and do a
>> graceful restart. This clearly fails because mod_php loads only on the
>> second load within apache. It
Greg Beaver schreef:
> Martin Alterisio wrote:
>> Consider the following code:
>>
>> foo.php:
>> > class test {
>> public static function foo() { echo "I'm foo in class test\n"; }
>> public static function foo2() { self::foo(); }
>> }
>> ?>
>>
>> foo2.php:
>> > namespace test;
>> function foo()
am I the only one to consider E_FATAL (as generated for class typehints) makes
type hinting useless - given that there is no compile stage at which to catch
typehint related mistakes. which means there is no way to trap the issue and
offer some useful/user-friendly feedback to the user (in practice
Tomi Kaistila schreef:
>> Broken record perhaps? I am getting a bit tired of this "just use Java
>> argument", it's perhaps even a bit arrogant. From what I read there is
>> plenty of people that want type hints for static types - there's a few
>> patches out there, it doesn't slow down the general
Stanislav Malyshev schreef:
>> In a way this is true, but I look at it this way. Some languages are
>> strictly typed, some are dynamically typed. PHP can have the best of
>> both worlds by having optional strict typing where desired, as well as
>
> I do not believe trying to both eat cake and lea
-1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tomas Kuliavas schreef:
me, I'm all for dropping unicode.semantics - Antony makes strong points
and it can only help the quality of the product if exceptions and switchable
functionality is kept to a minimum. from a developers POV the same is true,
additionally 'forcing' unicode on the mass
Marcus Boerger schreef:
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
Pierre Joye schreef:
On Jan 30, 2008 3:00 PM, Antony Dovgal <[EMAIL PROTECTED]> wrote:
On 30.01.2008 16:41, Dmitry Stogov wrote:
The final nowdoc patches are attached.
I'm going to commit them on Thursday in case of no objections.
So the current syntax is
$var = <<<'TEXT'
text
'TEXT';
am I r
ehl lhe schreef:
hi steph,
well, i'm trying to use apache's mod vhost_alias, which doesn't allow to use
e.g.
php_admin_value open_basedir /some/path/%2
...which means that %2 is usually replaced with a part of the requested URI,
but that does not work, such variables like %2 are interpreded
ehl lhe schreef:
I've run into the same thing in the past, ended up moving to virtual machines
in order
to circumvent ... BUT ... I found something which can apparently work in this
particular
case. have a google for 'mod_macro' ... from what I read it will do what you
want and it'll
save you
-1
Pierre Joye schreef:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other
Pierre Joye schreef:
Hi Jochen,
On Feb 12, 2008 12:22 PM, Jochem Maas <[EMAIL PROTECTED]> wrote:
Sebastian Bergmann schreef:
Jochem Maas schrieb:
Output:
C:\
Is this intended?
Yes, or what would you expect?
possibly 'C:' ?
Is "C:" not the volume whereas "C:
Sebastian Bergmann schreef:
Jochem Maas schrieb:
Output:
C:\
Is this intended?
Yes, or what would you expect?
possibly 'C:' ?
Is "C:" not the volume whereas "C:\" is the root directory on the
volume?
this is what I thought, kind of, but I was just propo
Pierre Joye schreef:
Hi Edward,
On Feb 12, 2008 4:30 AM, Edward Z. Yang <[EMAIL PROTECTED]> wrote:
Hello all, I was documenting the __DIR__ patch, and I ran across some
curious behavior when the PHP file was in the Windows filesystem root:
C:\test.php
Output:
C:\
Is this intended?
Yes, or
I think Lars has a point ... maybe set_include_path() could
be given a second parameter instead to mitigate the need for seperate funcs?:
set_include_path('foo', INCPATH_OVERRIDE); // default
set_include_path('foo', INCPATH_APPEND);
set_include_path('foo', INCPATH_PREPEND);
Strojny schreef:
Hi
Lukas Kahwe Smith schreef:
On 14.02.2008, at 10:07, Lars Strojny wrote:
Hi Jochem,
Am Donnerstag, den 14.02.2008, 00:56 +0100 schrieb Jochem Maas:
I think Lars has a point ... maybe set_include_path() could
be given a second parameter instead to mitigate the need for seperate
funcs
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 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 f
Hi,
Lars Strojny schreef:
Hi,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
To underpin this relationship, it is possible to declare that a Trait
implements an interface like this::
trait SayHello implements IHello {
public function sayHello() {
echo 'He
Lars Strojny schreef:
Hi Jochem,
Am Mittwoch, den 20.02.2008, 00:06 +0100 schrieb Jochem Maas:
[...]
if a trait would could contain all the methods required to implement
an interface and a class uses it (the trait) and implements the
relevant interface would it (the interface) be satified
John Campbell schreef:
On Tue, Feb 19, 2008 at 3:54 PM, Jochem Maas <[EMAIL PROTECTED]> wrote:
how about 'possesses' or 'exhibits' - both these words are closer to the
natural language usage of 'trait' with regard to a subject.
John exhibits a trait
J
Hi,
I had a thought about recursion (and self referencing) inside trait defined
functions and the possible issues that might occur due to explicit/implicit
conflict resolution and or aliasing/renaming (i'm not completely
following what the status quo is regarding conflict resolution and/or
aliasi
Etienne Kneuss schreef:
Hello,
On Sat, Jun 21, 2008 at 2:51 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
Hi!
So, I really would like to revert that foward_static_call stuff and
implement the parent:: patch instead, while it's still possible.
thoughts?
Didn't we discuss that already? Ad
Etienne Kneuss schreef:
Hello,
On Mon, Jun 23, 2008 at 12:44 AM, Jochem Maas <[EMAIL PROTECTED]> wrote:
Etienne Kneuss schreef:
Hello,
On Sat, Jun 21, 2008 at 2:51 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
Hi!
So, I really would like to revert that foward_static_ca
Greg Beaver schreef:
Derick Rethans wrote:
..
The real WTF comes into play when you have a static method that resolves
to the same name as a namespaced function, something that absolutely
must be worked out prior to PHP 5.3's release. I know a few ideas are
percolating about on this one fr
Derick Rethans schreef:
On Thu, 10 Jul 2008, Gergely Hodicska wrote:
exceptions thrown during autoload are ignored.
And one more thing, this is in the manual:
"Note: Exceptions thrown in __autoload function cannot be caught in the catch
block and results in a fatal error."
I think your explan
Lukas Kahwe Smith schreef:
On 10.07.2008, at 14:43, Richard Krehbiel wrote:
Here's the big part: I was thinking that a semantic change to persistent
sockets might make it easier for scripts to work "correctly" without
bothering them too much. The change is this: If a script doesn't
"fclose
to Greg and his cohorts a hearty bravo!
Phar is a really great addition, I'm very impressed with
the finesse of the initial implementation ... it's quite
rare to see [imho] a new feature appear in such a mature
and well thought out manner, good work 'smith. :)
I have a few questions, some of the
Scott MacVicar schreef:
On 12 Jul 2008, at 12:36, Jochem Maas wrote:
to Greg and his cohorts a hearty bravo!
Phar is a really great addition, I'm very impressed with
the finesse of the initial implementation ... it's quite
rare to see [imho] a new feature appear in such a matur
hello people,
I believe there is something wrong (or inconsitent) with the way __autoload()
behaves. at the least the current docs don't reflect what I'm seeing.
1. the docs state:
"Exceptions thrown in __autoload function cannot be caught in the catch
block and results in a fatal erro
Hi Marcus,
Marcus Boerger schreef:
Hello Jochem,
seems like we have quite some nice additions to the manual here in this
thread. Now to the real issue, Exceptions don't bubble up.
The thing is under quite a few circumstances the Exceptions do bubble up,
and there is another issue with __au
David Zülke schreef:
Am 17.07.2008 um 11:36 schrieb Mario Brandt:
I made a test on my console (cmd.exe)
ENV: WinXP SP 3 all updates, PHP 5.2.6 / PHP 5.2.6 non thread safe (NTS)
Intel Celeron 2.4 GHz 1 GB DDR Ram
It showed that the non thread safe is faster than the thread safe
version.
And
Marcus Boerger schreef:
Hello Jochem,
...
I just posted another mail to internals in which I attempt to detail the
__autoload behaviour 'issues' ... it includes something that wants to be a
test suite when it grows up ... it might help someone to investage/determine
what __autoload() does/sh
Thank you everyone for you replies, apparently I know a little
more than I thought in general and also a little more than this
morning. :-)
rgds,
Jochem
Andi Gutmans schreef:
There are some things I mention in this blog entry re: why I think
...
--
PHP Internals - PHP Runtime Development Mail
redirecting to generals mailing list ...
Diogo Neves schreef:
php -r 'class B { private static function a() {} public function
__callStatic($method, $parms) { echo $method, "\n"; } } $a = new B;
$a::a();'
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in Command line
code on line
Jani Taskinen schreef:
Hannes Magnusson wrote:
On Thu, Sep 4, 2008 at 22:43, Jani Taskinen <[EMAIL PROTECTED]> wrote:
Johannes Schlüter kirjoitti:
...
php.ini-recommended, 5.3:
;
; Paths and Directories ;
;
; UNIX: "/path1:/path2"
;include_p
Lukas Kahwe Smith schreef:
On 31.08.2008, at 15:37, Lukas Kahwe Smith wrote:
Hello all,
All the recent discussions about namespaces, have left many of us
wondering if our implementation is rock solid or not. However the
discussions were not really well organized. This is why I am thankful
In an attempt to do some testing of 5.3 I have being trying to compile it on my
Mac (MacOSX10.5)
with the same configure line[1] as I use for my 'current' version (5.2.6), this
is turning
out to be impossible because (so far) of a missing file
ext/iconv/php_have_ibm_iconv.h
the configure line
Alexey Zakhlestin schreef:
On Mon, Sep 8, 2008 at 12:11 AM, Jochem Maas <[EMAIL PROTECTED]> wrote:
if anyone knows of some details info on how to
keep multiple installs of
php around (including apache modules) and being able to switch between them
with minimal fuss then
I be very ha
Stanislav Malyshev schreef:
Hi!
This doesn't work at all
The closest you can do is
That's the right way to go. If you want functions in global space, put
them there. If not, then use namespace syntax. BTW, what is so bad in
F::myfunction that it makes it absolutely useless?
because it r
Elizabeth M Smith schreef:
Stanislav Malyshev wrote:
Hi!
Personally I don't see the point of of having functions in namespaces if
you can't "use" them in a global scope.
You mean, if you can do foo() it has a point but if it's F::foo() it
doesn't? Then I think your point was purely cosmetical
Stanislav Malyshev schreef:
Hi!
for the same reason you would want it with classes?? because you can
do it with classes, no? and that seems acceptable to you, no? then
functions
should have the same privilege.
Functions and classes are rather different things. Class represents, as
you know
Antony Dovgal schreef:
On 08.09.2008 00:11, Jochem Maas wrote:
--with-xmlrpc
This extension requires iconv.
aha. well at least that allows me to build 5.3alpha2 with all
the extensions I require to
I have to admit there is a mess with iconv.
I'm glad it's not (just)
Stanislav Malyshev schreef:
Hi!
Hi,
I'm not going to do this offlist with you,
guns are dangerous yet they are sold by the bucket load. either don't
sell guns or let people decide how to use them, don't sell'em then
dictate
that they can't pull the trigger.
I think it would really help i
Karl Pflästerer schreef:
Jochem Maas <[EMAIL PROTECTED]> writes:
Alexey Zakhlestin schreef:
On Mon, Sep 8, 2008 at 12:11 AM, Jochem Maas <[EMAIL PROTECTED]> wrote:
if anyone knows of some details info on how to
keep multiple installs of
php around (including apache modules) an
Stanislav Malyshev schreef:
Hi!
1. include.php
I would advise you to avoid calling your classes and namespaces by the
same name, for the sake of clarity - especially if you are going to have
identically named static f
Steph Fox schreef:
Seems like a winner. Just a whole ton of BC though for those using #
for comments.
Yep, so forget it. Or were you doing a Jani? ;)
It seems to hav escaped everyone that Greg's latest proposal doesn't change
the namespace seperator token, instead it comes with a new concept
Steph Fox schreef:
Hi Jochem,
It seems to hav escaped everyone that Greg's latest proposal doesn't
change
the namespace seperator token, instead it comes with a new concept of
namespace
member [token].
No, that didn't escape me at all.
oh, good!
I was responding to the OP.
To be clear
Dmitry Stogov schreef:
Hi Greg,
Greg Beaver wrote:
...
I really don't see a reason to change namespace syntax into a less
intuitive way.
I don't think the current implementation is intuitive, the ambiguity issues,
(and possibly the name resolution order, although I can't grok what the cu
hi Dmirty,
I really don't see a reason to change namespace syntax into a less
intuitive way.
I don't think the current implementation is intuitive, the ambiguity
issues,
(and possibly the name resolution order, although I can't grok what the
current
state of that is) are rather large WTFs.
Dmitry Stogov schreef:
Lukas Kahwe Smith wrote:
On 22.09.2008, at 16:37, Dmitry Stogov wrote:
Returning to the original debate, if you really believe this conflict is
not an issue, then why was the first user note published last December a
note about this conflict?
http://us3.php.net/manual/
Stanislav Malyshev schreef:
Hi!
On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:
1. Allow braces for namespaces. So, the syntax for namespaces will
hi Dmirty,
I really don't see a reason to change namespace syntax into a less
intuitive way.
I don't think the current implementation is intuitive, the ambiguity
issues,
(and possibly the name resolution order, although I can't grok what the
current
state of that is) are rather large WTFs.
Lester Caine schreef:
Jochem Maas wrote:
in the long run functions and constants will be added to namespaces
... and then
the ambiguity issues will have to be dealt with. I believe Greg's
namespace member
concept will be required even if the syntax is/must/should/will
changed to
some
[EMAIL PROTECTED]: nothing of technical importance in this email, but it might
make you feel better :-) ... even Stas!]]
Kevin Waterson schreef:
This one time, at band camp, "jvlad" <[EMAIL PROTECTED]> wrote:
everything that jvlad wrote was way too vague for me to understand
so I couldn't pos
Derick Rethans schreef:
> On Fri, 19 Sep 2008, Greg Beaver wrote:
>
>> Hi all,
>>
>> There is a problem in the namespace implementation. This code demonstrates
>> the issue:
>>
>> code.inc:
>> > namespace foo;
>> class test {
>> const my = 1;
>> static function bar(){}
>> }
>>
>> namespace foo::t
Lukas Kahwe Smith schreef:
>
> On 07.10.2008, at 20:18, Lester Caine wrote:
>
>> What is the correct procedure to create a new driver, or rather clone
>> the existing php_interbase so that we can build a proper Firebird
>> version that actually uses the fbclient.dll rather than sharing the
>> now
1 - 100 of 192 matches
Mail list logo
