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 that
+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 of goo.
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
time is
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 promoting
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 difference between internals and general is akin
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 does
Greg Beaver schreef:
Martin Alterisio wrote:
Consider the following code:
foo.php:
?php
class test {
public static function foo() { echo I'm foo in class test\n; }
public static function foo2() { self::foo(); }
}
?
foo2.php:
?php
namespace test;
function foo() { echo I'm foo in
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
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 case. So
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 leave it
-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
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
-
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:\ is the root directory
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 proposing what the OP
was expecting
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
?php
echo __DIR__;
?
Output:
C:\
Is this
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
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::
?php
interface IHello {
public function sayHello();
}
trait SayHello
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
Jack possesses a trait
a person
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
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?
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_call stuff
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
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
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
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 mature
and well
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
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
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.
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()
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 1
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_path
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 happy to learn
Stanislav Malyshev schreef:
Hi!
This doesn't work at all
The closest you can do is
?php
use Foo::Bar as F;
F::myfunction;
?
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
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
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) down to my
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
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) and being able
Stanislav Malyshev schreef:
Hi!
1. include.php ?php
namespace Test;
class Bar { public static function baz() { return 'namespaced static
method'; } }
function foo() { return 'namespaced function'; }
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
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
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?
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
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
something
[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
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:
?php
namespace foo;
class test {
const my = 1;
static function bar(){}
}
namespace foo::test;
const my = 2;
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
Pierre Joye schreef:
Hi
On Tue, Oct 14, 2008 at 12:52 AM, Jochem Maas [EMAIL PROTECTED] wrote:
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
Steph Fox schreef:
On 10 Oct 2008, at 06:03, Lukas Kahwe Smith wrote:
1) rip them out
+1 ... I concur with Steph's opinion
I'm +1 on this. We simply don't have consensus, and I don't see
anyway we
can have consensus by the time 5.3 has to be frozen. Once
namespaces are in,
Andi Gutmans schreef:
-Original Message-
From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 14, 2008 2:15 PM
To: Steph Fox
Cc: Stas Malyshev; PHP internals
Subject: Re: [PHP-DEV] namespaces and alpha3
err .. you misunderstood me .. Dmitry wasnt happy with his
Greg Beaver schreef:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason
hi Derick,
Derick Rethans schreef:
On Fri, 5 Dec 2008, Lester Caine wrote:
...
Second question.
What is the current situation on translating dates? I've tried several ways
of
using setlocale, but at present I've not been able to get anything other than
English out of the code.
please ignore this if any of the following apply:
1. you name is 'mm w' (I don't care for your response either) - granted this is
reverse psychology.
2. your very busy atm (nothing technical being added here)
3. you abhor off-topic junk
otherwise the following may help to make you smile ...
Op 1/19/10 1:27 AM, Stanislav Malyshev schreef:
Hi!
I wrote a small patch that enables this kind of syntax in PHP:
foo()();
What it means is that if foo() returns callable value (which probably
should be function name or closure) then it would be called. Parameters
and more than two
Dmitry Stogov wrote:
+1
I like this solution and I don't think that BC break is important for many
applications.
Not a lot of them use is_array($GET), and I believe no one use
is_object($_GET).
$get = $_GET may be a problem, but moving from PHP5 to PHP6 won't easy in
any case.
a couple
Antony Dovgal wrote:
On 02/16/2007 01:21 AM, Antony Dovgal wrote:
We also can add a detailed description of what is release candidate,
what's the difference comparing to a release etc. to qa.php.net and
add a link to that page in the block. Actually, I'll try to write
something tomorrow.
Antony Dovgal wrote:
On 02/16/2007 04:00 PM, Jochem Maas wrote:
I would make the whole sentence above ALL CAPS
This text should appear at qa.php.net, so no need for CAPS (which are
difficult to read), we can just use b/b.
indeed - I was merely stressing that you probably cannot highlight
I suspect you could implement the desired functionality
using http://php.net/manual/en/function.stream-wrapper-register.php
although I can't find any info on whether include/require
actually work with registered stream wrappers .. maybe one of the
devs could confirm/deny whether this is possible.
Antony Dovgal wrote:
On 04/27/2007 04:35 PM, elias wrote:
Hi,
why has the support for http arrays (bracket syntax) been removed in
PHP 5.1.3 ? Yes [] not allowed by according RFC, but is that a
reason for an BC break? Is it an accident or harassment?
What are you talking about?
Michael Wallner wrote:
Jochem Maas wrote:
$args = array('foo' = array('bar' = array(1,2,3), 'quz' = array(1,2,3)));
echo '/foo.php?'.http_build_query($args);
foo.php --- 8 ---
var_dump($_GET['foo']);
the var_dump() output used to be a neat nested array, but since 5.1.3
[although I
today there is no spoon.
Michael Wallner wrote:
Jochem Maas wrote:
I'll take your word on it (although I can't be sure exactly what it is that
you expected),
which means the change has been reverted, or the input parsing stuff has
been changed to
recognize escaped square brackets
Richard Lynch wrote:
Maybe I'm just confused (well, I'm always confused...) but if a Class
has multiple children, how the heck would PHP know which child:: to
call?...
the use of the name 'child' is very confusing, I would prefer 'super' or
'static' ...
regardless the concept is actually
Stanislav Malyshev wrote:
You'd probably do something along those lines if it were possible:
((ParentClass) $child)-virtualMethod();
Looks like bad style to me - why not call child's method and it would,
if needed, pass control to parent?
yeah, although I could imagine a situation where
Bart de Boer wrote:
Ken Stanley wrote:
...
That's not right. Accessing the child class would only be possible from
within an instantiated object. Unlike parent::, you will never be able
to use static:: in a purely static context. Imagine there are multiple
child classes which all inherit
Lukas Kahwe Smith wrote:
Jochem Maas wrote:
Pierre wrote:
On 7/6/07, Stefan Priebsch [EMAIL PROTECTED] wrote:
There must be a reason to upgrade to a new PHP version (usually
features, maybe performance increase etc.). But there also must be no
reason not to upgrade. But you all know
Jochem Maas wrote:
Lukas Kahwe Smith wrote:
Jochem Maas wrote:
Pierre wrote:
On 7/6/07, Stefan Priebsch [EMAIL PROTECTED] wrote:
There must be a reason to upgrade to a new PHP version (usually
features, maybe performance increase etc.). But there also must be no
reason not to upgrade
Dmitry Stogov wrote:
This is an implementation of Stas idea.
1) Look for existent class in current namespace
2) Look for existent internal class
3) Try to autoload class from current namespace
both ways have a wtf factor in that class with names
matching 'internal' class names behave
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 the
shruti wrote:
Hello all,
I have an issue with unserializing big objects. My object when serialized to a file creates a file as big as 29 Megs. And when i m trying to unserialize the object, it takes forever somewhere around 33-36 secs(sometimes even more).
My object has one member variable which
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
Pawel Bernat wrote:
?
$cnst = DEBUG;
// what I want to do but can't
if ($dbg = constant($cnst)) {
// do stuff
}
// the only real option, it seems - bit long winded to get round a stupid (IMHO)
if (defined($cnst) ($dbg = constant($cnst))) {
// do stuff
}
What is stupid with
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?
I did
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
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
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
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
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
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 Maas
It's our responsibilities, as contributors, maintainers, and those
merely voicing concerns in open forum to consider all of the masses
(unwashed
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
- 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 able to define function bodies
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
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
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 when speed is
very
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
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 =
1 - 100 of 182 matches
Mail list logo
