Hi all,
first of all I do not want to set off yet another discussion about the
changes 4.4 brought. I do understand why the changes were necessary, and
in most of the cases, I would even endorse that pieces of code that
trigger the new "only variable..." waring are "bad code".
Anyways, to me it s
> > So, in case of "return new", wouldn't it make sense to remove the
> > warning as the code is 'legal'? And please, don't start a new "it's
> > just a friendly notice" flame war.
>
> It's just a notice, tune your error_reporting level accordingly.
Sorry, but that is just a stupid killer
Sorry, Olli, if that kind of ignores your statements, but I would like
not to distract from the issue. IIRC, what you suggested is called
"boxing" in C# and would lead too far here.
I wanted to focus only on the "return new ..." case and only on PHP4, as
"return new" is a very special case. This p
> The "return new..." is just a subset of the problem, but not
> the only one that is in wide use. For example, this is very common:
>
> function &getstuff($in)
> {
> if ($in=='ok')
> return new MyObject();
> else
> return false; // this is the common line
> }
>
> The "false" obvious
Hm, thinking a little more about this one:
> > function &getstuff($in)
> > {
> > if ($in=='ok')
> > return new MyObject();
> > else
> > return false; // this is the common line
> > }
"return false" (or null) is trying to return a reference to a literal,
which is (of course) questiona
> Von: Derick Rethans [mailto:[EMAIL PROTECTED]
> On Sat, 8 Oct 2005, Matthias Pigulla wrote:
> > The point is that this requires really unlogic and silly
> > workarounds
> > like 'return $tmp =& new Foo()'. That forces people to touch stable
> > c
> I agree that allowing "=& new" and disallowing "return new"
> by reference is inconsistent.
I'm so stubborn with this one because there might be good reasons if
you're the mechanic lying under the car fixing the engine, but it does
not make any sense if you just want to drive the car :)
> But
Hi internals,
I was experimenting with different approaches of maintaining state and
serializing objects in PHP5. The problem is handling static class
members and static variables inside methods.
First, I noted that static variables inside methods are shared between
instances. C++ seems to handle
> Von: Wez Furlong [mailto:[EMAIL PROTECTED]
>
> As you mentioned, static properties and statically scoped
> variables don't belong to an object instance, so it doesn't
> make sense to serialize them.
Ok, but on the other hand they are just variables - so the question was
if there is any (poss
> my suggestion would be, to simply shorten the string that
> gets exposed to "php" - and not show any version numbers (or
> maybe leave it to the user, say 0 for "no exposure", 1 for
> "only php" and 2 for "php with version number".
At least it would be interesting to know about the spread of
> You mean something like SRM:
> http://www.vl-srm.net/
>
> Though a bit more finished :-)
Derick is probably too busy to finish SRM all alone, and my C skills are
way too bad to help him :) So this gets off-topic here, but what about
writing something like SRM in PHP itself to avoid the need of
I think all of us who were upset making the transition to 4.4.0 would greatly
appreciate if (in the future) there will not only be short "there's a new
release" notices, but if these notices would directly point to a list like this
one.
E. g. MySQL does a pretty good job with their upgrade no
> 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 usin
Jochem,
the point with most of these issues is that there's no common
understanding of what things like protected or static interface members
mean; from an OO point of view, they make no sense, and I was only
trying to explain why.
Unless there is a common understanding what a certain language co
- "abstract" is no longer valid in interfaces.
- that "curly brace" thing?
> I've some fear of terrifying would-be upgraders with an
> unnecessarily long list here :)
You're kidding.
If you're intentionally not adding things to that list, better do not
compile the list at all. If people use
Anybody interested in my two cents? (I shouldn't have asked as I'm going
to tell you anyway.)
"You will break many more scripts by dropping [] for strings than the
other way around. Do you agree?" - Heck, this sounds as if you're doing
a "let's drop stuff for some technical reason no average PH
> For the 13th time. {} is not going away in 5.1.
>From the NEWS file:
16 Nov 2005, PHP 5.1 Release Candidate 5
- Added an E_STRICT warning on the usage of {} for accessing of string
offsets.
(Ilia)
That is, code that has been tested with RC4 and that worked (not even a
notice on whatever err
> I suggest removing that warning immediately until the matter
> is resolved.
+1 ( times the discount-for-rants-factor )
-mp
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
If I got that right, you still want to discourage {} and un-deprecate []
again, despite all the good reasons given on this list not to do so?
PHP5.1 would be accomplishing facts as to this one. ("Let's remove {}
altogether in 6 - nobody should be using them anyway as they were
deprecated since 5.1
Derick,
> If you prefer a PHP which causes strange crashses and memory
> corruptions, please downgrade to 4.3.11. I am getting tired
> about this
> bickering about this **FIX** that makes PHP stable.
You got me wrong here. I did not want to say anything against the 4.4.0
fix or even blame you f
> This is a non-issue for phpDocumentor. All we need is at
> least 6 months
> to a year of lead time on the final decision in order to
> adjust the code.
As I wrote, I happend to have Smarty and phpDocumentor checkouts at
hand. I just checked a recently installed version of Mediawiki and they
Great, I have been waiting for this list sine Derick mentioned the
meeting in his talk at the conference :)
@Derick: There have been some questions and issues raised during your
talk... Dou you remember them? It was about reading from files with the
new unicode semantics, and you said these were s
Now that was a quick reply :)
> Also known as runtime inheritance, or late binding. It's not a new
> thing, we have it today. The discussion was about whether to
> have a way
...
That is, one can write
if (...) class A extends X {} else class A extends Y {}
right now? Seriously ;)?
Every
> I don't see why you can't specify that a class definition must have a
> constructor. Obviously the constructor is not for the
> interface itself.
Ok, that is, having __construct in the interface asserts that everything
you get passed (as an implementation of the interface) has been
constructe
> Anyway, I see only one use case for interface constructors:
...
I also thought about that:
$whichClass = ...
if ($whichClass instanceof ISomehowConstructable)
$foo = new $whichClass(...);
would even work without reflection, but of coure would require to change
instanceof a little, too
> -Ursprüngliche Nachricht-
> Von: Jani Taskinen [mailto:[EMAIL PROTECTED]
> We could start with making it an E_ERR..erm..E_STRICT notice
> if you use {} with arrays or [] with strings. And really separate
> them in PHP 6. But does it make any sense?
At least some people
> > Well, safe_mode could prevent someone of doing a shell_exec("cat
> > /home/otheruser/web/config.php"); open_basedir can't do the same
> > thing.
>
> We were in a continual losing race against that sort of thing though.
> In pretty much every single release there have been ways to
> do th
> > Well, safe_mode could prevent someone of doing a shell_exec("cat
> > /home/otheruser/web/config.php"); open_basedir can't do the same
> > thing.
> >
> disabled_functions=shell_exec, etc
But safe_mode is more safe because it disables these functions
altogether? It's difficult to maintain
> Or
> a) am I missing something
> b) is it the core developers' opinion that core classes have
> the right of way?
If things behave like that at least there should be a list of "reserved
class names" just like with other keywords. And of course that list must
not be changed as it is considered
>
> Then I have to ask both of you: why is there no mentioning in
> the release notes or the upgrading guide regarding "Date"
> being reserved for PHP now?
I was also curious as to that. Once again the release announcement (more
precisely, the "upgrade" document) greatly understate
> Yes, and that will break code again as I just explained to
> Sebastian Kettler. And it will break *my* code ;-)
Too bad I don't find the right mail to qoute you now literally - but
nobody forces you to use the official PHP codebase for your stuff; go
ahead and maintain releases for yourself.
> > obviously one problem is that PEAR does ignore coding standards.
> > Classes should be prefixed in both pear and core. And
> neither Date nor
> > File is in any way prefixed.
>
> Err, how are we supposed to prefix PEAR::Date?
>
> PEAR_Date?
> Date_Date?
> Lala_Date?
The whole thing is
> I didn't say that my code is more important, but if we don't
> get the date class now, we will get it in 5.1.1 and then
> break your code - so that doesn't really matter. THe only
> correct solution is to start prefixing the pear date class,
> as that needs to be done in the long run anyway.
> >> I have always maintained that shared hosts should be running
> >> per-security context Apache instances as different users.
> >
> > The problem with that is that it makes name-based virtual
> hosts pretty
> > pointless because each apache instance will at least need an ip
> > address on i
> Von: Andi Gutmans [mailto:[EMAIL PROTECTED]
> BTW, just to clarify, I am not against a Date class (whatever its
> name) in the long run but I think it'd probably be a
> combination of work Derick, Pierre and new contributions.
It would be nice if there would be some 'official' statement as to
I have to back Sebastian with what he said. Obviously the release methodology
currently applied does NOT work, neither for the project nor the community
around it.
Do it how ever you like - discuss whether it's legal to add new features on
HEAD only or on release branches like Jani said.
BUT:
> Von: Jessie Hernandez
> So, the question is, can we scrap both namespace constants
> and namespace functions and just stay with classes (as was
> agreed on several months ago, Andi himself agreeing to it)?
...
> I think this is the best solution thus far. If any one of you
> still feels a n
I know this is weird and off-topic but I hope that someone here can give
me a starting pointer.
With installing a security update for the pcre3 library on Debian
(http://lists.debian.org/debian-security-announce/debian-security-announ
ce-2007/msg00177.html), preg_match('|^\(|', 'xxx') suddenly ret
> Von: Steph Fox [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 5. Dezember 2007 02:34
> import nstest::test as whatever;
>
> This works in the global space, right? Now along comes, say, Pierre or
> Derick or Marcus with this class they just have to add to an existing
> (non-namespaced) core ext
> To summarize the patch lead to approx. 5% slowdown and 3% memory
> overhead for typical applications (as always, you mileage may vary
> depending on your system's architecture and OS although my guesstimate
> is that you will see even worse results in a 64bit environment).
Does that slowdown res
> > Is it possible to always perform (unconditionally compile in) the
> > necessary housekeeping tasks but stick with the current GC, so that
> > cycle-detection only happens when the user calls a
> > gc_go_find_cycles()
> > function? Would that significantly improve the above numbers?
>
> Yes, th
> 1) recommend all global non-namespaced code that wishes to import
> namespaced code via "use Namespace::Classname" add a "namespace
> __php__;" at the top of the file, and that the __php__ namespace be
> reserved for use by end-user applications.
> 5) namespaces provide these benefits that are
> Von: Gregory Beaver [mailto:[EMAIL PROTECTED]
> Exactly - which is why you should never put classes, functions or
> constants in the __php__ namespace. The convention I am proposing is
> to
> only use __php__ for code that *uses* re-usable components, not
> *declares* them.
Let alone __php__.
> -Ursprüngliche Nachricht-
> Von: Sam Barrow [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 10. Dezember 2007 22:48
> An: internals@lists.php.net
> Betreff: [PHP-DEV] Namespace resolution
>
> Ok, it's supposed to be this way right? If i define a custom class in
> the global namespace cal
> Von: David Zülke [mailto:[EMAIL PROTECTED]
> The problem I see with that is that if I have an application that uses
> a 3rd-party library which does not use namespaces, I need to
> use ::LibClass everywhere. Until they switch to namespaces - then I
> need to touch hundreds and thousands lines of
> Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
> But you could achiever
> the same just by avoiding naming classes the same as internal classes,
> you surely know which classes are in your own namespace?
...
> Not using names of classes same as internal classes is not a big deal
> either - a
> -Ursprüngliche Nachricht-
> Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
> If the class for which autoloaded request is issued *exists*.
> However, we are discussing the case where this class *does
> not exist*, so it can not be loaded. Thus, autoload request
> will be repeat
> > Just a quick idea - what if requiring that autoloaders behave
> > deterministically, that is, once a certain autoloader
> > implementation
> > has been given the possibility to find a class it will
> > never be asked
> > again (because it wouldn't find it later on either).
>
> I'm not s
> From: Soenke Ruempler [mailto:[EMAIL PROTECTED]
> BUT let derived constructors change parameters
> a) as constructors are never called from the parent, but
> optionally from a child class, it's completely valid IHMO
> b) constructors are usally not used in object aggregation /
> setters, but
Hi all,
I'm afraid that recent changes in filestat.c [1] that were meant to fix
a bug [2] with file_exists() also altered the behaviour of
is_readable(). According to the docs [3] [4], is_readable should *not*
take safe_mode limitations into account, whereas file_exists should do.
[EMAIL PROTE
> I think the current behavior solves made old bug reports,
> where by people used is_readable() to see if they could read
> from a file, only to have the operation file due to
> safe_mode/open_basedir restrictions. Taking the check away
> would also mean it would be possible to "explore" fil
> i dont think this is a recent change. i think its only an
> oversite in the documentation.
[EMAIL PROTECTED]:~$ php ./bug.php
5.1.4
string(0) ""
bool(true)
bool(true)
[EMAIL PROTECTED]:~$ php -d safe_mode=1 ./bug.php
5.1.4
string(1) "1"
bool(true)
bool(true)
With 5.1.4 both file_exists() an
> -Ursprüngliche Nachricht-
> Von: Ants Aasma [mailto:[EMAIL PROTECTED]
> That would indeed be too slow. The standard way to handle
> this, is to only check visibility periodically. That is how
> Java, .NET, Python and countless others do that. Check
> http://www.hpl.hp.com/personal
> -Ursprüngliche Nachricht-
> Von: Etienne Kneuss [mailto:[EMAIL PROTECTED]
> Gesendet: Sonntag, 10. Dezember 2006 15:55
> Cc: internals@lists.php.net
> Betreff: Re: [PHP-DEV] [RFC] Magic Method that handles unset($object)
> You could use references, you would have to move some code
Hi internals,
please consider:
Result:
5.2.0
Array
(
[0] => *
[1] => b
)
Same with 5.1.4 and 5.1.6. I suppose that using foreach and referencing
the values turns the elements in $a into references, $b is a copy of the
array containing *references* and thus chaning the value of the firs
> Did you try a snapshot?
>
> 5.2.1-dev
> Array
> (
> [0] => a
> [1] => b
> )
Thanks, sorry for the noise.
mp.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Dear internals,
recently I was hurt badly by https://bugs.php.net/bug.php?id=53611. In short,
the FCGI variables PHP_VALUE and PHP_ADMIN_VALUE can be used to pass ini
settings to FPM. This feature was added in
https://github.com/php/php-src/commit/34ba9e39fafa3a980a1b69285f68b0e12ad6b876.
The
57 matches
Mail list logo
