As someone that has long clamoured for namespaces in PHP, I have to say
that this proposal by Dmitry is exactly what I others have been hoping
for in PHP. Thanks, Dmitry, for creating this patch. I'm sure there
are going to be some peculiarities that need to be sorted out, but I
can't wait
Hi all,
DateTime equality (not identity) appears to be broken. I've created a
ticket for this issue (http://bugs.php.net/bug.php?id=40691), which
keeps getting marked as bogus by Ilia. This may be a more appropriate
issue to raise on list, as I seem to be having both a very hard time
making my
Hi all,
DateTime equality (not identity) appears to be broken. I've created a
ticket for this issue (http://bugs.php.net/bug.php?id=40691), which
keeps getting marked as bogus by Ilia. This may be a more appropriate
issue to raise on list, as I seem to be having both a very hard time
making my
I think there is far more
demand for a fast stable PHP then for syntatic sugar features which
seem extremely useful, but in the end prove to carry too much baggage.
Nothing has been proven either way.. at least not publicly.. unless I
just missed it.
I haven't talked to a single
Brian Moon wrote:
Unfortunately namespaces are not only syntactic sugar, but dire
necessity
for PHP if it wants to be taken as a serious langauage and defend it's
position against other arising 'web scripting' alternatives.
It seems the list of things that PHP needs to be taken as a serious
Sascha Schumann wrote:
They are not helpful for various reasons. e.g. if you need
to ask whether a session was started, your architecture is
broken (a central place needs to manage sessions; that single
place must know whether a session has been started).
I haven't looked in any
Stefan Esser wrote:
Hi,
I haven't looked in any detail at these functions, but wouldn't you be
able to prevent fixation by inquiring whether a particular session was
already started? -- rather than PHP's current (IMHO flawed) behavior
where a new session is simply started with whatever session
Stefan Esser wrote:
Hi,
Sorry, perhaps this is just a vocabulary misunderstanding on my part.
I thought fixation was explicitly providing the user with a fake but
known session id (e.g. '1'), whereas hijacking is taking a valid id
from another user.
yeah... Well you call it fake session id.
Dan Kalowsky wrote:
On Tue, 26 Apr 2005, Hans Lellelid wrote:
I see your point, but I would still argue that being able to create an
arbitrary, non-server-supplied session id is far more powerful --
primarly because it is not susceptible to session garbage collection
on the server (i.e
Hi Zeev,
Zeev Suraski wrote:
At 19:47 29/03/2005, Hans L wrote:
Hi,
This may not be the right place for this question, but what I'm
looking to understand is the reasoning behind what seems to be the
standard session behavior in PHP. And, if it's possible, how to
change this behavior (via INI
Hi Chris,
Chris Shiflett wrote:
M. Sokolewicz wrote:
why is it this way should also be posted to the general newsgroup, it
barely has anything to do with internals
The behavior of the session extension has everything to do with
internals. I'm not sure why everyone is sending him to php-general.
Alan Knowles wrote:
I think he's referening to something like this (which is common in pear):
$x = $someobj-somemethod();
if ($x instanceOf PEAR_Error) {
...
}
while that code is redundant in the case of exceptions, it is still a
valid situation.. that $x may be a valid return, and
I like the new $obj instanceof ClassName way of checking class /
interface types, but this method does have one major drawback
compared to the old is_a() approach:
The class must be loaded in order to perform an instanceof check!
Apparently is_a() has also been deprecated, so that an
Taco Van Den Broek wrote:
Hans Lellelid wrote:
static, default behavior, probably accounts for 80% of uses:
$c = new Criteria(Author::NAME, Leo);
$a = AuthorFinder::find($c);
You pass your criteria to your search class as instantiated objects, why
don't you pass your parameters/config
Hi all,
I have a pattern I'm trying to implement in PHP5 using a class that
could be called statically or non-statically. Perhaps pattern gives
this too much legitimacy :) I can't figure out how to do this wanted
to ask if a) it's possible at all and b) if there's been any solution
Andre Cerqueira wrote:
$c = new Criteria(Author::NAME, Leo);
$a = AuthorFinder::find($c);
instantiated behavior for performing customizations:
$c = new Criteria(Author::NAME, Leo);
$af = new AuthorFinder();
$af-setLimit(5);
$a = $af-find($c);
I think it should be constructor's job to
Hi,
Marcus Boerger wrote:
Last but not least we know already that a lot of people like to
be able to handle both instanceof or null with typehints. But at
the moment we have no solution that can go into PHP 5.0. However
i am quite sure we will address this for 5.1.
I'm glad this issue will be
Marcus Boerger wrote:
Here is a slightly related example from my code [] -- and it
would be nice if I could use optional paramters w/ typehints.
IMO thats the only valid point you brought up here. Another thing missing
is that in derived classes the typehints should be able to accept
Hi Marcus,
Marcus Boerger wrote:
Hello Hans,
Friday, June 18, 2004, 9:15:47 PM, you wrote:
Of course, namespaces are more important than anything ;)
hehe, could you live with packages?
Probably! yeah :) -- what's the difference? Are namespaces more like
what's implement in C#/.NET (i.e. no
Andrei Zmievski wrote:
abstract class BasePeer {
// ...
public static function doDelete(Criteria $criteria, Connection $con) {
// ...
}
}
class AuthorPeer extends BasePeer {
public static function doDelete(Criteria $criteria, $con = null) {
if ($con === null) {
$con =
Robert Janeczek wrote:
is there any way that string 'false' (and its variations with capital
letters) could be interpeted as boolean of value false? i have xml
configuration file that has some switches (true/false) in it. when i use
this values in functions that require booleans i get true every
Hi guys,
I just had to take a moment to let you all know just how cool this PHP5
thing is. I know that I've been kinda vocal (and perhaps out of place)
in the past about some of the behavior of OO stuff like interfaces, and
sure disappointed when __toString() became less magical, etc. Those
Bert Slagter wrote:
Hi All,
I have a class and a subclass, both with a static method:
?php
class Foo
{
static function Bar()
{
self::Baz();
}
}
class Foo2 extends Foo
{
static function Baz()
{
echo 'Baz';
}
}
Foo2::Bar();
?
In this case I expect to find
Ferdinand Beyer wrote:
On 1 Jun 2004 at 15:21, Stephan Schmidt wrote:
Furthermore this renders the template-method pattern quite
useless, so
IMHO it should be changed.
He should define an abstract method Foo::Baz() here.
Yes, I agree that design-wise that would be better -- but it will still
Ferdinand Beyer wrote:
On 1 Jun 2004 at 21:13, Timm Friebe wrote:
Yes: self is bound at compiletime. It would need to be changed to
evaluation at runtime und would be far more useful then.
[...]
I wouldn't mind chaning self in the first place, though.
I prefer your solution to evaluate self at
Andi Gutmans wrote:
As no good syntax has been found for the less common case of allowing
NULL's, I think the best solution for now is not to allow null in the
regular type hint syntax, and have people who want to allow NULL's not
use type hints at all (in any case, they need to manually check
I'm using PHP5.0.0RC2. I saw that there was a similar question posted,
but apparently that issue had already been fixed.
---code
class File {
public $var;
function __construct($val) {
$this-var = $val;
}
}
$t1 = new
I also would add that from experience using IP addresses to validate
sessions does not work for any internet application.
It is not generic enough to be implemented in world-wide application, but it
can be useuful for intranet or extranets. That's to say cases when you know
the infrastructure
Marcus Boerger wrote:
I already changed SQLite because as far as i know there were only two
extensions left which didn't follow studlyCaps convention which we agreed
upon twice so far - even though ppl pretend we hadn't. The only other
extension i spotted so far not following studlyCaps is ming -
Hi -
Andi Gutmans wrote:
Only if you use E_STRICT. There was a long discussion about this on
internals@ a few weeks ago.
At 11:57 AM 3/17/2004 +0100, Clemens Gutweiler wrote:
?php
interface person {
function wakeup( $day, $time );
}
class hugo
Andi Gutmans wrote:
Nope. The final decision was to only check this during E_STRICT
because there's no reason why inheritance should be different from
implementation. People here felt that due to PHP not supporting
function overloading we should not be very strict, and therefore, only
give
Hi Andi,
Quick question -
Andi Gutmans wrote:
Marcus and rest,
Zeev and I took a long look at the whole __toString() issue. There is a
problem today that make_printabl_zval() is being called in many places,
some of which can't cope with a user-land __toString() being called. In
order to
Hi -
Andi Gutmans wrote:
Just to clarify, this is only for internal classes like Exception,
right? Userland __toString() will continue to be invoked when an
explicit (string) cast (or concat, etc.) is used, correct?
Wrong. The only time userland __toString() will be invoked will be in
I notice that in the new RC1, the following reference to class constants
is no longer possible:
class MyClass {
const MY_CONST = 1;
function __construct() {
echo MY_CONST;
}
}
You must now use self::MY_CONST to reference the class constant. While
I
I was just about to post the same bug ...
Except that I couldn't quite build a reproducing testcase. I get
exactly the same message in my code, but when I created a small static
class to reproduce the problem it seems to work fine ... (static or
non-static or mixture)
Hans
Jan Schneider
obj == null checks now trigger E_NOTICE
class Foo {
}
$t = new Foo();
if ($t == null) {
}
Notice - Object of class Foo could not be converted to boolean
Changing the comparison to $t === null makes the notice go away. Is
this intended? If not I can post it as a bug report.
Thanks,
Hans
--
Here's a script to reproduce the problem w/ static callbacks.
The problem only seems to happen when the function calling the static
function using preg_replace_callback() is not declared 'static' itself,
but is accessed as a static function. Also, this only happens when being
called from
Hi Marcus,
Andrei Zmievski wrote:
On Thu, 26 Feb 2004, Philip Fletcher wrote:
Looking at the documentation, the comments and method name (for hasMore())
do not have the same meaning - the comment is saying 'does the current
element exist?' and the method name says 'are there any more elements?'.
Hi -
Andi Gutmans wrote:
Well we don't have very much time anymore because I want to roll RC1
ASAP (assuming that we get a couple of bugs fixed which need fixing).
Personally I'm fine with either of these (I don't mind hasMore()) but
a decision has to be reached quickly. From discussing with
Hi -
Andi Gutmans wrote:
The question is if we should ignore constructors from this check. I
think we should but one person here thought we shouldn't.
I think constructors should be ignored.
Is everyone OK with peforming this check for abstract classes and
interfaces? Or do you think it should
Ferdinand Beyer wrote:
IMO we are trying to force a strict programming here that is
incompatible with PHP's loose character.
Yeah, I absolutely agree with that. The more I think about it the more
it also seems like this change is going to break a *lot* of PHP code out
there. Especially the
Hi Zeev -
Thanks for the response.
Zeev Suraski wrote:
If you take into account that [a] in PHP, you cannot have more than one
signature for a method in a given class, and you take into account the
fact that [b] your overriding method must be able to satisfy the same
interface as the method
Timm Friebe wrote:
On Wed, 2004-02-25 at 23:44, Marcus Boerger wrote:
Hello Timm,
i had the same expirience today too. And also for me it makes not much
sense. The constructor shouldn't check inheritance rules.
Neither should other methods follow this. What if I want to add a
non-default
to
be in shutdown sequence but beyond that I'm not sure -- Reflection_API,
XML (expat) ... ? Not using destructors...
Thanks-
Hans
Hans Lellelid wrote:
I'm getting a segfault at the end of (successful) script execution.
Appears to be an issue in the shutdown sequence; I'm unsure how to
report this bug, since
Timm Friebe wrote:
On Wed, 2004-02-18 at 18:40, Hans Lellelid wrote:
foreach($entities as $ent) {
$peer = $ent-getPeer(); // e.g. might be BookPeer
$peer-doSelect(new Criteria()); //static: BookPeer::doSelect()
}
$m= new Reflection_Method($ent-getPeer(), 'doSelect');
$m-invoke
Hi -
Pierre-Alain Joye wrote:
On Wed, 18 Feb 2004 12:23:04 -0500
John Coggeshall [EMAIL PROTECTED] wrote:
class foo {
static function bar() {
}
}
$a = new foo();
$a-bar(); /* Unacceptable and contradictory to the concept of static
*/ foo::bar(); /* Acceptable */
I have the same
Andi Gutmans wrote:
It depends what you call different signature. If you are talking about
default arguments, we should consider allowing those as they don't
change the isA relationship. However, if you want us to allow
inheriting interfaces which truly differ in function prototypes than
Hi -
Cristiano Duarte wrote:
On Tue, 17 Feb 2004 15:34:11 +, Stephane Drouard wrote:
Hans,
In PHP you are not allowed to explicit overload methods. Ex:
class A {
function x($a1) {}
function x($a1, $a2) {}
}
The function x is already defined and explicit overloading is not
Hi-
Cristiano Duarte wrote:
I still think that interfaces should follow the same behavior as classes
(i.e. if you can override in classes you can override in interfaces),
but I understand that academically this is wrong. Of course overriding
is wrong period, but it's the route you have to take
Andi Gutmans wrote:
Hey,
Marcus didn't mean it adds complexity to the code but to PHP. It's
obviously quite easy to implement this interface; implementation was
never a problem.
I don't really care too much if we have such an interface or not,
although I do think that it just makes things
Andi Gutmans wrote:
Hey,
Marcus didn't mean it adds complexity to the code but to PHP. It's
obviously quite easy to implement this interface; implementation was
never a problem.
I don't really care too much if we have such an interface or not,
although I do think that it just makes things
Hi -
Ard Biesheuvel wrote:
Hans Lellelid wrote:
Personally as PHP developer (as opposed to internals developer) I am
not in favor of having an interface, because I want to know that
try {
// ...
} catch (Exception $e) {
// ...
}
will catch *all* exceptions thrown by any libraries I choose
Hi -
Zeev Suraski wrote:
At 07:55 16/02/2004, Hans Lellelid wrote:
I have a need in a current application to extend interfaces and
possibly re-define (change signature) some of the inherited methods in
the child interface.
...
You're not supposed to change the signature when you're
extending
Hi -
This issue of inheritance interfaces persists to give me problems...
Perhaps I'm going about this wrong for PHP.
Zeev Suraski wrote:
You're not supposed to change the signature when you're
extending/implementing interfaces. I'll try to see if it's feasible
to improve the checks so
Hi Adam -
Adam Bregenzer wrote:
My biggest motivation for not having an exception class was to prevent
people from having a catch all with exceptions. Personally, I think
that attitude is what has caused an over use of exceptions (making every
function throw Exception so as to not have to deal
Hi -
Sebastian Bergmann wrote:
Andi Gutmans wrote:
Zeev is planning on fixing this.
Cool.
Interfaces should be allowed to extend other interfaces but not
to implement them.
interface Bar extends Foo {}
works already (at least last time I checked). What I need (and meant) is
I'm getting a segfault at the end of (successful) script execution.
Appears to be an issue in the shutdown sequence; I'm unsure how to
report this bug, since providing duplicating code is not possible.
The segfault is happening at the end of a Phing (http://phing.info)
build process, which
Sebastian Bergmann wrote:
Hans Lellelid wrote:
I thought this was going to be fixed for beta4/RC1, but still seems
not to be.
Works for me:
Apologies! -- yes, it does work. I was still doing the old Foo
implements Foo, Bar which used to work (but never should have).
Thanks-
Hans
--
PHP
Is there any way to have an _interface_ implement or extend multiple
interfaces? This was working as of PHP5b3, but seems to work no longer
as of latest snapshot I downloaded.
The only way to do it before was to have an interface implement other
interfaces:
interface ExtendFileSelector
On Mon, 2003-12-22 at 16:05, Hans Lellelid wrote:
Hi -
We're using the Reflection API in a project for which I'm lead
developer.
Seems to be something changed between beta-2 and beta-3. We're now
getting the following exception when calling getClass() on a class hint:
[...]
Works fine
Hi -
We're using the Reflection API in a project for which I'm lead developer.
Seems to be something changed between beta-2 and beta-3. We're now
getting the following exception when calling getClass() on a class hint:
exception 'reflection_exception' with message 'Class FileSet does not
Daniel Khan has asked me to help him with DB_NestedSet by maintaining the MDB driver.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
62 matches
Mail list logo
