Re: [PHP-DEV] run-tests SKIPIF caching can be problematic for third-party extensions
The reply below is from Sept 24, 2021. I just realized that I inadvertently responded to Nikita dierctly and never shared to the mailing list. Doing so now to close the loop on some open questions and provide more context for a PR I recently opened (https://github.com/php/php-src/pull/8076). Since this last message, I'll note that a mechanism to disable SKIPIF caching entirely was ultimately merged in https://github.com/php/php-src/commit/9fc6be297fc775c659d5e04b7a4a591bc8577f8a . I'm not sure I understand the setup you're using. The "nocache" tag that > mysqli uses covers the situation where part of the test setup is done in > the SKIPIF section -- because checking whether the test should be skipped > requires doing the same setup as the actual test. If the test does get > skipped, it's still fine to cache that. > > Now, it sounds like your situation is different from that, and you > actually have SKIPIF sections where first one test should be skipped, but > then a later test with identical SKIPIF shouldn't be skipped. Is that > correct? What changes between the time these two tests run? > To avoid code duplication across SKIPIF blocks, we have several helper functions ( https://github.com/mongodb/mongo-php-driver/blob/master/tests/utils/skipif.php). In addition to environmental checks (e.g. server, PHP version), we have one function that ensures the collection (table equivalent) under test is empty. Based on the mysqli tests I saw, those SKIPIF blocks are quite large and contain literal references to the schema, which leads to them being cached independently. In our case, the functions called from our SKIPIF blocks often rely on default values for arguments (e.g. COLLECTION_NAME). The definitions for these constants are derived from a filename ( https://github.com/mongodb/mongo-php-driver/blob/master/tests/utils/basic.inc), which ensures each test uses a different collection. Unfortunately, this also means many of our SKIPIF blocks end up having identical code and thus share the same cache entry. https://github.com/mongodb/mongo-php-driver/blob/master/tests/cursor/bug0671-001.phpt is an example of a common SKIPIF block, which ensures that the server is accessible and that the collection under test is empty (i.e. that we can successfully drop it). I think I was able to work around our issue with https://github.com/mongodb/mongo-php-driver/commit/ce6b11d475fb1ff19afed29bcf5b89c200f82440, but echoing "nocache\n" after a successful drop -- and only for PHP 8.1+ to avoid borks on earlier versions); however, this approach only allows us to opt out of caching for non-skips. Hypothetically, if we encounter an error dropping the collection for tests/cursor/bug0671-001.phpt and that test is skipped, it's not desirable for run-tests.php to immediately skip the subsequent bug0732-001.phpt test simply because the code in its SKIPIF block is identical. The risk here is that our test suite skips more tests than expected or are necessary. > Independently of that question (which is about whether "nocache" is > sufficient if we ignore cross-version compatibility issue) I do agree that > an option to disable the skip cache entirely would make sense. Would > https://github.com/php/php-src/pull/7510 work for you? > Being able to completely opt-out of SKIPIF caching seems generally useful. I'll take a look later today and provide some feedback on the PR. Thanks! -- jeremy mikola > On Thu, Sep 23, 2021 at 10:23 AM Nikita Popov wrote: > On Thu, Sep 23, 2021 at 4:10 PM Nikita Popov wrote: > >> On Wed, Sep 15, 2021 at 7:23 PM Jeremy Mikola wrote: >> >>> I just discovered that run-tests.php was changed to cache SKIPIF >>> evaluation >>> since 8.1.0beta3[1]. I believe ext-mongodb ran into the same issue as >>> mysqli[2], as we use SKIPIF to check that database contents are clean >>> going >>> into a test. The present solution in core is to check SKIPIF output for >>> "nocache" [3,4] and allow individual tests to opt out of caching; >>> however, >>> I'm worried that won't be portable for third-party extensions, where we >>> test with run-tests.php for each version of PHP that we support. >>> >>> Is there still time to consider an alternative solution? If "nocache" >>> needs >>> to remain in place for mysqli, perhaps 8.1.0's run-tests.php can be >>> enhanced to consult an environment variable (for maximum BC and playing >>> nice with `make test`) that disables caching entirely. >>> >> >> I'm not sure I understand the setup you're using. The "nocache" tag that >> mysqli uses covers the situation where part of the test setup is done in >> the SKIPIF section -- because checking whether the test should be skipped
Re: [PHP-DEV] Automatic implementation of Stringable may conflict with old, untyped arginfo declarations
On Fri, Nov 12, 2021 at 7:00 AM Nikita Popov wrote: > > With the introduction of Stringable PHP also started automatically adding > the string result type to __toString(), specifically for compatibility with > the interface. As such, it should be safe to add the string return type > everywhere for PHP >= 8.0. (If you use stubs with legacy arginfo, that > would automatically give you the right behavior: types on PHP 8, no types > on old versions.) > We haven't explored using stubs, but I'll keep that in mind. Andreas has definitely mentioned that in the past and I believe it's on the list of ideas to implement once we revisit typing across the board for the extension (which we plan to do since we finally dropped support for PHP 7.1). I previously added explicit string return types to all of our toString methods (including interfaces), which I understand is a small BC break for any userland classes implementing those interfaces (as rare as that is). Just yesterday, I had an idea to use tentative return type info on the interface toString methods ([mongodb/mongo-php-driver#1283]( https://github.com/mongodb/mongo-php-driver/pull/1283)), which seems to require no changes at all to userland classes. ReturnTypeWillChange attributes are not even required on PHP 8.1+ since the Stringable behavior will automatically add the return type info if it's omitted. For PHP 8.0 and earlier, we map the ZEND_BEGIN_ARG_WITH_TENTATIVE_RETURN_TYPE_INFO_EX macro to ZEND_BEGIN_ARG_INFO_EX -- so these methods will continue to have no return types there (also avoiding a BC break). I tested the change (i.e. tentative return type info for interfaces) with PHP's master branch to cover the warning you added in [86379b6]( https://github.com/php/php-src/commit/86379b6710f972e0d4a11c89ce28d5768d9824d3). There seems to be no conflict, which seems reasonable considering that return type is only "tentative" from the context of userland (and only until PHP 9.0, when it becomes enforced). Tentative return types are still considered the actual return type for internal purposes and satisfies the check for Stringable compatibility. Are we likely to run into issues with this approach? If so, I'll consider your last suggestion to define non-tentative return type info for interfaces on PHP 8.0+ (where Stringable will add it to userland classes automatically), and leave return type info absent for PHP 7.x. But if both are viable solutions, I think I prefer the tentative return type info approach. -- jeremy mikola
Re: [PHP-DEV] Automatic implementation of Stringable may conflict with old, untyped arginfo declarations
On Tue, Nov 9, 2021 at 4:30 AM Nikita Popov wrote: > > In > https://github.com/php/php-src/commit/a551b083073ea08f8fc53b0e1a6380b6de26cc6b > I've added a hack to add the string return type if it is missing and thus > make the signature compatible with the interface. That should address the > immediate compatibility issue. > Thanks for the quick fix. A related question that came up, and is most likely unique to ext-mongodb, follows. Many of our classes with toString() methods also implement a corresponding interface with a toString() method. For example: * https://www.php.net/manual/en/class.mongodb-bson-binary.php * https://www.php.net/manual/en/class.mongodb-bson-binaryinterface.php I'm in the process of adding explicit return type info to _all_ of our toString() arginfos (classes and interfaces), but a thought occurred to me that doing so may be a subtle BC break for userland classes implementing these interfaces, since an explicit string return type would then become necessary. But if I only modify our classes and leave our interfaces as-is, PHP rightfully reports an error because the class' toString() method cannot conform to both Stringable (with type info) and our interface (without type info) -- at least PHP versions before 8.1.0RC6. Reading the patch above, it looks like the automatic Stringable implementation only kicks in when the arginfo has no existing return type info. In that case, I think the only option to completely avoid a BC break would be to continue to leave our return type info omitted (on both our classes _and_ interfaces) and allow PHP 8.1+ to apply it automatically. Is that correct? -- jeremy mikola
[PHP-DEV] Automatic implementation of Stringable may conflict with old, untyped arginfo declarations
https://github.com/php/php-src/commit/b302bfabe7fadd07b022ee30aacf7f41ab1ae0fa
recently added automatic implementation of Stringable (
https://wiki.php.net/rfc/stringable) for internal classes. This introduced
fatal errors for each existing __toString() in ext-mongodb:
```
Declaration of MongoDB\BSON\BinaryInterface::__toString() must be
compatible with Stringable::__toString(): string in Unknown on line 0
Declaration of MongoDB\BSON\Binary::__toString() must be compatible with
Stringable::__toString(): string in Unknown on line 0
...
```
Our arginfos for these methods have historically never reported a return
type, going back to when it was originally written for PHP 5.x. For example:
```
ZEND_BEGIN_ARG_INFO_EX(ai_BinaryInterface_void, 0, 0, 0)
ZEND_END_ARG_INFO()
static zend_function_entry php_phongo_binary_interface_me[] = {
ZEND_ABSTRACT_ME(BinaryInterface, __toString, ai_BinaryInterface_void)
// ...
```
I noted that _ZendTestClass (referenced in the original commit's tests)
uses ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX to declare a string return
type (
https://github.com/php/php-src/blob/eda9d7ac22c70f75a44bf33139acf8c812d69944/ext/zend_test/test_arginfo.h#L74
).
While that's a trivial change we can make in ext-mongodb, I wonder if this
may have been an unanticipated BC break for third-party extensions. I
imagine ext-mongodb is not the only extension with older arginfo
declarations predating the introduction of type reporting in later PHP
versions.
--
jeremy mikola
Re: [PHP-DEV] run-tests SKIPIF caching can be problematic for third-party extensions
On Wed, Sep 15, 2021 at 1:59 PM Sara Golemon wrote: > > If the phpt file outputs "skip nocache" then that will skip without > caching on all versions, won't it? In 8.1 because it has the explicit > 'nocache' provided, and in older versions because they don't cache anyway. > > Am I missing something? > If I'm reading the most recent patch correctly [^1], the SKIPIF result is always cached if the output does not start with "nocache". If the output starts with "nocache" (ignoring whatever may follow), the entire result is replaced with an empty string. Given that, it seems like it's not possible to opt out of caching and skip a test. Perhaps that's by design if the cache is only intended to memoize SKIPIF blocks that do result in a test skip. But the question remains: how do we portably opt out of caching without skipping a test? In PHP 7.4 (and presumably earlier versions), run-tests.php appears to ignore unrecognized SKIPIF output [^2]; however, 8.0 is more strict and will flag unrecognized output as borked [^3]. I think Nikita alluded to that logic in his most recent patch [^1], since the same validation exists in 8.1; however, I don't think backwards compatibility (e.g. running the same test on both 8.0 and 8.1) was being considered there. [^1]: https://github.com/php/php-src/commit/0074a1d4e3a85d0d63118e7a30f4b7ed6da64695 [^2]: https://github.com/php/php-src/blob/php-7.4.23/run-tests.php#L2127 [^3]: https://github.com/php/php-src/blob/php-8.0.10/run-tests.php#L2200 -- jeremy mikola
[PHP-DEV] run-tests SKIPIF caching can be problematic for third-party extensions
I just discovered that run-tests.php was changed to cache SKIPIF evaluation since 8.1.0beta3[1]. I believe ext-mongodb ran into the same issue as mysqli[2], as we use SKIPIF to check that database contents are clean going into a test. The present solution in core is to check SKIPIF output for "nocache" [3,4] and allow individual tests to opt out of caching; however, I'm worried that won't be portable for third-party extensions, where we test with run-tests.php for each version of PHP that we support. Is there still time to consider an alternative solution? If "nocache" needs to remain in place for mysqli, perhaps 8.1.0's run-tests.php can be enhanced to consult an environment variable (for maximum BC and playing nice with `make test`) that disables caching entirely. [1]: https://github.com/php/php-src/pull/6681 [2]: https://github.com/php/php-src/pull/6726 [3]: https://github.com/php/php-src/commit/4d43cbe333690171753e9b8663df93d3762e02a8 [4]: https://github.com/php/php-src/commit/0074a1d4e3a85d0d63118e7a30f4b7ed6da64695 -- jeremy mikola
Re: [PHP-DEV] [RFC] Iterable
On Saturday, July 2, 2016, Aaron Piotrowski <aa...@trowski.com> wrote: > > > There was no discussion on the list of allowing stdClass, but I did discuss > it with some people in chat. Our consensus was that a casting to an array > was a reasonable and simple requirement to allow an instance of stdClass to > be iterable. > Sounds good to me. Happy to hear it was discussed. Thanks! -- jeremy mikola
Re: [PHP-DEV] [RFC] Iterable
On Sat, Jun 18, 2016 at 11:34 AM, Aaron Piotrowski <aa...@trowski.com> wrote: > > I plan on bringing the iterable RFC (https://wiki.php.net/rfc/iterable) > to a vote in about a week, does anyone have any further feedback on this > proposal? > Was there any discussion about a special allowance being made for stdClass? I've noted the is_iterable(new stdClass) example and ensuing "Object Iteration" section: PHP allows any object to be used with foreach. However, iterable does not > accept any object, only those implementing Traversable. Values accepted > by iterable should be designed for iteration, not any set of values (such > as the public properties of an object or a string). > I'm on the fence if that second sentence applies to stdClass. Based on how users typically end up with stdClass instances (e.g. casting arrays to an object, json_decode()), I tend to think of them as logically equivalent to associative arrays. To that end, I'd consider stdClass to be as "designed for iteration" as any associative array -- if we can even say a stdClass was designed at all :) As-is, the RFC requires users to either cast stdClass instances to an array or decorate them with an Iterator (e.g. ArrayObject). I find this a bit irksome, but it's certainly easy to work around. That said, I realize that voting is in progress and it's not my intention to interrupt anything. I just wanted to relay a viewpoint that might not have come up. -- jeremy mikola
[PHP-DEV] Naming of 'weak' type hints
On Monday, March 30, 2015, Christoph Becker cmbecke...@gmx.de javascript:_e(%7B%7D,'cvml','cmbecke...@gmx.de'); wrote: It appears to me that all of these suggestions may hide the fact that the arguments are converted to the hinted types. So perhaps converting type hints might be a good name. Coercive may be a concise term, without the negative connotation of weak/lax. -- jeremy mikola
[PHP-DEV] Gauging Interest:RFC to add map() function
Hello,I would like to submit an RFC to add a new function to the PHP language. The function would be called "map()". The purpose of this function would be to take an existing value within a range and make it to a corresponding location within a new range.The map() method would have 5 required parameters, $originalLow, $originalHigh, $newLow, $newHigh, and $value.map() would be implement the following:function map($originalLow, $originalHigh, $newLow, $newHigh, $value) { return $newLow + ($value - $originalLow) * ($newHigh - $newLow) / ($originalHigh- $originalLow);}Example:Let's say we are teachers and are grading final exams. We have a policy that the best score is 100, and the worst score is a 70. Students scored between 55 and 92. We want to easily re-score the exams to be within the new score range, so we would use the new map() function. Let's begin with mapping the lowest score: $newScore =map(55, 92, 70, 100,55); //$newScore = 70 If we have all of our scores in an array: $scores = array(71, 65, 55, 85, 88, 86, 92, 77, 73);We could use a foreach loop to remap each value: $newScores = array(); foreach($score as $scores) { $newScores[] = map(55, 92, 70, 100, $score); } var_dump($newScores); /* array(9) { [0]= float(82.972972972973) [1]= float(78.108108108108) [2]= int(70) [3]= float(94.324324324324) [4]= float(96.756756756757) [5]= float(95.135135135135) [6]= int(100) [7]= float(87.837837837838) [8]= float(84.594594594595) } */Just like that, we have the new exam grades that fit our policy, within the proper scale, without having to do any of the messy math ourselves.While I do recognize that this is somewhat trivial to anyone who knows the proper formula, I feel as though it would serve the PHP community well. Much the same as the pow() or pi() functions do. I appreciate your thoughts on this matter and whether or not this is worth pursuing as an RFC.Thank you,Jeremy Curcioj.cur...@me.com
Re: [PHP-DEV] Gauging Interest:RFC to add map() function
I am curious with something that is so easy; why would you want it in core?A lot of the Math Functions could be considered "so easy".abs() could be written out as: function abs($n) {if ($n = 0) return $n;else return $n*-1; }pi() could be replaced by simply setting a global variable equal to 3.14159265358979floor() could be written out as: function floor($n) {$stop = strpos($n, '.'); if ($stop !== false) return substr($n,0,$stop);else return $n }ceil() could be written out as: function ceila($n) { $stop = strpos($n, '.'); if ($stop !== false)return 1+substr($n,0,$stop); else return $n; }The above examples are just a few that stick out to me I'm sure that looking through the list of available math functions would provide a few more examples. Keeping these examples in mind, I don't follow the logic of range mapping being too easy toimplementmanually whenever it is needed to not warrant being included in core.
Re: [PHP-DEV] Gauging Interest:RFC to add map() function
The functionality provided is uncommon but perhaps usefu. However, I am*very* against the name `map` which has a very established meaning in theprogramming world; others have already mentioned this but I felt I shouldmention it again.I'd like to note that I am not married to the name. If there is a better wayto reference what the function is doing then that could be the namethen by all means it should be used.
[PHP-DEV] Annotations / Interceptors
Hi, I am new to the list and just got done doing a search through the archives to try and get an idea on where things stand in regards to annotation support in PHP. Although I did find some interesting debates, I was not really able to conclude one way or the other what the plan is. I've noticed some patches that have been submitted to the rfc wiki which have been declined, and I am seeing a lot of mixed feelings on whether or not PHP 'should' support them. What is the official position on annotations? I for one would really like to see this supported. I have been experimenting with annotations/interceptors in my framework for the last year or so, and I love them. The only problem I have is performance - this needs to be handled in the core. One thing I figured I would mention, is it seems like most people want annotations to be part of the reflection package. While this makes sense in the context of annotations, I think this would prevent annotations from being used as the foundation to interceptors, since a class level interceptor would need to get executed before the intercepted class is instantiated. As I understand reflection to work today, this would not be possible. I'm more than happy to contribute to an extension with those who share similiar feelings. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Autoboxing with type hints
I'm not sure if this is a bug, an oversight, or something that is known
and deemed not-worth-fixing, so I thought I would ask here first.
Consider the SPL_Types extension. This extension introduces some
classes that override assignment in order to do some type-checked
autoboxing:
$int = new SplInt;
$int = 5;
//$int is not overwritten with scalar '5', but is now SplInt(5).
$int = 'foo';
//throws UnexpectedValueException: Value not an integer
That is a pretty neat thing. However, I would see the primary use-case
for this as the following:
function foo(SplInt $int)
{
//some code
}
foo(5);
Unfortunately, this produces Catchable fatal error: argument 1 passed
to foo() must be an instance of SplInt, integer given. This, however,
works:
$int = new SplInt;
$int = 5;
foo($int);
Does it seem like a good idea for the type checking mechanism for type
hinted parameters to check whether the hinted class has overridden
assignment, and if so, delegate the type checking to that mechanism?
For example,
foo('bar');
would yield 'UnexpectedValueException: Value not an integer', rather
than the catchable fatal error associated with the type hinted parameter.
Or, perhaps there is something that the extension itself could be doing
to make this happen? Or, perhaps this intentionally does not happen?
I know that genuine scalar type hints are kinda-sorta-maybe on the table
for a future version, but as of right now using the SPL Types to emulate
that in a performant way would be pretty neat.
Thanks,
Jeremy
P.S. - As a side note - I wonder whether it would be possible to make
accessible from userspace the functionality that SPL_Types uses to
override assignment? For example, you could have an __assign($value)
magic method that, if present, would be invoked when attempting to
assign a value to an existing object:
class Foo
{
public function __assign($value)
{
echo $value;
}
}
$foo = new Foo;
$foo = 'foobar';//outputs foobar
echo ($foo instanceof Foo); //output 1
That's not something I'm really requesting - just an interesting
thought. I'm sure that operator overloading has been brought up and
shot down before, and that functionality is dangerously close to such.
But yeah.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?
Glen wrote: It's short, and it doesn't conflict with XML. I have to say, I don't understand all the hate on short_open_tag. So what if it conflicts with XML? PHP is not XML. If you use an XML construct in your PHP, escape it. PHP can generate a lot of other languages, too -- should every construct from these languages be forbidden in PHP as well? Jeremy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Access to syntax tree?
Is there any way to access the parse tree of a PHP file from within PHP?
I'm trying to write a code-checking utility to find namespace-related
problems in code and alert me to them. Specifically:
namespace foo\bar;
function foobar()
{
try
{
...
}
catch(Exception $e)
{
//nothing will be caught
//I forgot to qualify
//code silently fails
}
}
I didn't want to put a whole lot of work into this, so I'm trying to
avoid having to write in C/flex/ANTLR/etc. There's a bit of
grease-monkey internals stuff in PHP so I thought I would check.
Thanks,
Jeremy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Access to syntax tree?
Alexey Zakhlestin wrote: On Wed, Mar 25, 2009 at 8:13 PM, Jeremy jer...@pinacol.com wrote: Is there any way to access the parse tree of a PHP file from within PHP? will this work for you? http://docs.php.net/manual/en/tokenizer.examples.php That looks like it should work perfectly! Thanks for pointing this out; it's almost exactly what I was after. Jeremy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] config files and PHP_CONFIG_FILE_SCAN_DIR
For some time, PHP has had a build option
./configure --with-config-file-scan-dir=/etc/php5/conf.d/
that allows distribution maintainers to manage system-wide PHP
configuration by adding/removing individual files with configuration
fragments to this directory, for example when installing a package with
a compiled PHP an extension.
This is an improvement over the previous situation where php.ini had to
be edited by package install/remove scripts.
On Debian and Ubuntu systems (and maybe others), each SAFI ie. apache2
module, cli, or cgi is compiled with a different location of php.ini and
config-file-scan-dir. (which is a bit redundant, with the option of
naming it php-cli.ini, php-apache2.ini etc.)
Also, the config-file-scan-dir is set
to /etc/php5/apache2/conf.d, /etc/php5/cli/conf.d, which are then
symlinked to /etc/php5/conf.d, (also a bit redundant)
So it seems, it is easy to have system-wide settings in multiple
separate files, which is good for packagers, but per-SAFI configuration
must still be in *one* php.ini choosen from several locations in the
ini-search-path.
I wonder if the config-file-scan-dir could be a path with multiple
directories to search, then each SAFI could be compiled with a common
and a per-SAFI directory to scan.
It could be a loop around this part of main/php_ini.c around line 512:
/* If the config_file_scan_dir is set at compile-time, go and
scan this directory and
* parse any .ini files found in this directory. */
if (!sapi_module.php_ini_ignore
strlen(PHP_CONFIG_FILE_SCAN_DIR)) {
The config-file-cscan-path could then
be /etc/php5/conf.d:/etc/php5/apache2.d
or /etc/php5/conf.d:/etc/php5/cli.d
Depending how much change is wanted/tolerated, this could get rid of the
other special cases that search for ini-files in a path, which searches
for php-$SAFI.ini, then php.ini, etc. since they could be put in the
config-file-scan-path.
--
Jeremy Jackson
Coplanar Networks
(519)489-4903
http://www.coplanar.net
j...@coplanar.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About dropping magic_quotes in 5.3 (was: Re: [PHP-DEV] Re: PHP 5.2.7 + magic_quotes_gpc broken)
Hello, I don't post here often, but I wanted to input my thoughts. For the most part, I am a end user who developers PHP applications for mine and others needs. We can't just drop something so soon and expect others to catch up and be able to operate with no problems at all. There is tons of applications out there that still only develop using the latest stable version of PHP and do not realize that development versions of PHP will break their applications. Personally all my scripts work all the way up to PHP 6, but I know others I do download and use won't even operate in 5.3 as it is right now. I would suggest adding the deprecated note on the magic quotes feature for 5.3. Just leave it at that. So those developing scripts know the feature is deprecated, as well provide documentation on php.net on using alternative methods to magic quotes. While this means having to maintain testing magic quotes in PHP threw 5.3, this will give people enough time (years at that), to get rid of magic quotes. - Jeremy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: keeping traffic on this list manageable
Lukas Kahwe Smith wrote: Hi, So some core developers as well as lurking end users have noted that the traffic on this list prevents them from being able to follow this list. This is obviously a huge problem since this mailinglist is supposed to be our primary discussion and decision making tool. snip Personally, I'm an end user who reads the list because I care about the direction PHP is taking. However, I have rarely had the need to post to any of the mailing lists. In any case, the traffic on the list is not a problem for me - because I access it through NNTP (news.php.net) and it never clogs my inbox. I personally think mailing lists are an awful way to maintain a set of many concurrent discussion threads, and NNTP is far superior. If you severely dislike receiving a lot of irrelevant e-mail, then maybe give news.php.net a try instead? That way, you can just browse the lists in a threaded view whenever you feel like it. Works well for me, anyway - but then, I'm not a PHP developer, so maybe the story is different. Jeremy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote from a Mere User
I am a mere user you can consider as well. I usually just read internals. I wanted to add input into the namespace issue. Using a difference of ::: or :: for separators is really confusing. I could slip up in programing by missing a single : and then have to go back to debug and it would be very easy to miss this. I don't think option 1 and 2 would work here unless we used a different separator. At this time I do not have a suggestion for a separator. My eye sight isn't all that perfect, in fact typing them in this message, I had to double check I typed them correctly. Although this solves it, this isn't very user friendly. Option 3 sounds nice, but since reading a previous internals note, you can use these in a if/else statement. Which I would prefer almost for those weird cases where you need to only include a class if it was for something specific such as a database, operating system or php version compatibility. The issue I see with number 4 is lets say I have a forum and a cms. If I wanted to bridge those two and they had this conflict, I wouldn't be able to bridge these two very easily now. Conflicting code while working with apis and other open source/free scripts is my only concern with this. That said, I think option 3 would work the best here with option 1 as another choice if we used a different separator that was more unique. Jeremy On Oct 16, 2008, at 9:31 PM, Mark wrote: A mere user here too with some php namespace experience (with current implementation). Issue 1: Choice #4, with a fallback on choice #3 Issue 2: This should be a php.ini option, typically it's going to cause a lot of (useless) calls to __autoload() for some existing code while migrating to a namespace-oriented code. This is also going to break things for some people who use require() in __autoload(). Mark Le vendredi 17 octobre 2008 à 13:18 +1030, Josh a écrit : I'm another mere user, but here are my votes Issue 1: Choice #3 Issue 2: Agree with Greg. Josh Heidenreich ZCE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: SPL Comparator interface
Something that would be extremely useful is a comparator interface in
SPL, which could be used to easily implement sorting for objects.
Example:
class Foo implements Comparator
{
// is numeric for this example
public $bar;
//implements compare method from Comparator interface
public function compare($that)
{
//simple example; will return 1 if this is less
//than that; zero if they're equal; 1 if this is
//greater than that
return $this-bar - $that-bar;
}
}
Then, if I had an array of Foo objects, I could just call some kind of
spl_sort function on the array which would use my comparator to sort them.
I realize this can be kludged with usort(), but I think there should be
a better, OOP-ier way to do it.
I also realize that a similar effect could be achieved by defining an
SPL PriorityQueue-ish collection rather than an array, but I think there
ought to be a better way. Java has a Comparator interface which works
in much the same way, if that helps my case at all.
Jeremy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hey Marcus, On Sun, 03 Aug 2008 07:26:59 -0500, Marcus Boerger [EMAIL PROTECTED] wrote: Hello Internals, please let's not introduce new inconsistencies. Rather lets make new stuff consistent with old stuff during the alpha phase of 5.3. 1) new keyword 'use'. Semantically it is the same as 'static' or 'global' so it should be used in the same location. 2) namespaces, either use 'package' and only one per file, or use 'namespace' with curly braces. Read this as be consistent with other languages and even if one or two people do not like it the two main languages out there which have it are Java which goes with the former and C++ which does the latter. Please chose and not mix it. Also our mix is a nightmare when developing code. If we feel we have to keep the keyword 'namesapce' but cannot have curly braces, than I suggest we disallow multiple namespace per file. And there is no technical reason and surely no other reason whatsoever to not have curly braces. If there is then we either fix that or went with the wrong approach. 3) __invokable, see Etiene's mail Best regards, Marcus I'm +1 with you on all of these. Unfortunately, #2 has been beat to death, revived, and beat to death again so many times that the chances of getting anyone to budge on it now are probably pretty slim. It is inconsistent to not allow curly braces on namespace when *every other similar construct in the language* uses curly braces (this is like str_* vs str* all over again, haven't we learned by now?). Thanks. -- Jeremy Privett Chief Software Architect Omega Vortex Corporation http://www.omegavortex.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.3 and reflection
Hello, I'm installing a recent snap of 5.3 on my dev server. The app I'm working on makes heavy use of reflection. How has reflection changed in 5.3 to address namespaces? What resolution rules apply when creating a ReflectionClass? If I try to create a ReflectionClass for a class that is outside the current namespace, what will happen? Also, are there any plans to address namespaces themselves in the reflection API (i.e. ReflectionNamespace objects, getNamespace() method in the ReflectionClass object, etc)? Thanks, Jeremy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 and reflection
Stanislav Malyshev wrote: Hi! I'm installing a recent snap of 5.3 on my dev server. The app I'm working on makes heavy use of reflection. How has reflection changed in 5.3 to address namespaces? What resolution rules apply when creating a Namespaces should not have big influence on reflection, since namespace is just the logical partitioning of the class name - i.e. if the class name is Foo::Bar::Baz, you can say that Foo::Bar is the namespace, but for reflection you still use full class name. ReflectionClass? If I try to create a ReflectionClass for a class that is outside the current namespace, what will happen? You should be able to use any class name with ReflectionClass. Since namespaces are compile-time only, at runtime there's no such thing as current namespace. Thanks for your response. Just to clarify, - Class names are translated at compile time to include the namespace. This composite is now considered to be the class name by the engine, and the class name alone (i.e. Baz) is no longer meaningful. - Therefore, to reflect a class at runtime, the namespace must be included. To continue your example, if I tried to do this: $reflect = new ReflectionClass(Baz); it would not work, regardless of the namespace of the file that statement appears in. I must instead do this: $reflect = new ReflectionClass(Foo::Bar::Baz); Furthermore, there will never be a way to reflect a namespace, since the concept of namespacing is essentially lost by the time the reflection code would be executed. Is this accurate? Thanks, Jeremy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Properties in Interfaces?
Marcus Boerger wrote:
A much shorter thing to do might be:
interface Coord {
abstract $coord;
}
Something like that is exactly what I was looking for in my original
question. I don't want to specify implementation details, I just want to
ensure the property exists on the classes that implements the interface.
(Type hinting support would be beautiful, too.)
--
Jeremy Privett
C.E.O. C.S.A.
Omega Vortex Corporation
http://www.omegavortex.net
Please note: This message has been sent with information that could be
confidential and meant only for the intended recipient. If you are not the
intended recipient, please delete all copies and inform us of the error as soon
as possible. Thank you for your cooperation.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removal of unicode_semantics
Tomas Kuliavas wrote: We've discussed this a few times in the past and it's time to make a final decision about its removal. I think most people have agreed that this is the way forward but no one has produced a patch. I have a student working on unicode conversion for the Google Summer of Code and this would help make it simpler. unicode_semantics=on breaks backwards compatibility in scripts that have implemented multiple character set support in current PHP setups. If setting is removed, instead of maintaining at least some bits of backwards compatibility and doing some additional work, you force massive code rewrites in scripts that depend on working charset support and more work for people, who use interpreter. Every time somebody proposes removal of this setting, they claim that majority agreed on it when there is no agreement on anything. People only defended own positions and we had other flame about unicode_semantics. And leaving unicode_semantics in will make it so web application developers like myself, who distribute their applications to be installed on people's own servers, have to write two different versions of their software to support the switch being on or off because of the major differences in the language based on an ini setting. Not only is there twice the code in PHP's codebase, there's twice the code in the codebases for people like me. But, we've been through this discussion before. I've already stated my opinions. +1 to removing this. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Properties in Interfaces?
Stanislav Malyshev wrote: Hi! have plain properties that may contain everything. If we would have something like this: You can easily do this by having __get call getProperty. That's like 1 line of code to do. No language change needed. I don't know about you, but I'm not interested in that kind of performance trade-off. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why interfaces ?
Nathan Nobbe wrote: all, in recent weeks there has been a lot of arguing about what interfaces are, arent (on php-general and now on the internals list as well) etc. etc. i am quite curious, why interfaces were added to the language in the first place. note, i am not criticizing them, i am overjoyed that the language has them, however i am curious about the history. is this something php borrowed from java? does it have anything to do with 'entirely virtual classes' in c++ ? i think that the history behind the addition of interfaces to php, would shed a lot of light on their intended purpose for use by php developers. thanks, -nathan Interfaces exist in different OO-enabled languages. PHP strengthened its object model in PHP 5, and thus the introduction of interfaces. I'm pretty sure the intended purpose of interfaces was just like pretty much every other language. You implement interfaces in order to provide a consistent API. As long as class A implements interface B, I can be for certain that it's going to contain methods C and D. Interfaces also give you the ability to type hint against them, requiring objects that implement that interface, thus ensuring you know what methods are on that object. Interfaces are a very powerful feature, when implemented properly. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Properties in Interfaces?
Robert Cummings wrote: On Tue, 2008-04-29 at 20:04 +0200, John Carter -X (johncart - PolicyApp Ltd at Cisco) wrote: I think there's been two responses to this query: 1. We can't have properties in interfaces because interfaces don't have properties. I would say this is tautological and doesn't add anything. 2. Why would you need to? Getters and setters work. So I suppose to answer my question for myself, there's no real technical reason for not having properties in interfaces, but getters and setters work just fine and no-one (including me) really misses them. I have to agree. Enforcing existence of a property is just as much part of an interface as enforcing the existence of a method. Why go down the clutzy getter and setter method route when properties were meant to be accessed. Why should code be made slower? Methods are at least an order of magnitude slower than direct property access. Cheers, Rob. I'm glad someone out there agrees with me. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation.
[PHP-DEV] Class Properties in Interfaces?
Hey list, I was curious what everyone thought of implementing the ability to specify class members in interfaces. I've run into a couple of circumstances where I would like to specify public member names inside of an interface to ensure that these members are accessed in a standard way and to ensure that they exist. Currently, trying to include them in an interface results in *Fatal error*: Interfaces may not include member variables in file/line number. Thoughts? Thanks. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hinting patch
Sam Barrow wrote:
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}
I'll post an update soon.
That's certainly a non-intuitive syntax. How about we take a page out of
the book of other C-style languages before trying to invent something
else? I agree with Stas, return and returns are not part of a
function definition.
--
Jeremy Privett
C.E.O. C.S.A.
Omega Vortex Corporation
http://www.omegavortex.net
Please note: This message has been sent with information that could be
confidential and meant only for the intended recipient. If you are not the
intended recipient, please delete all copies and inform us of the error as soon
as possible. Thank you for your cooperation.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions = Apache Crash in PHP 5.3 Snaps
Jeremy Privett wrote: Jeremy Privett wrote: Hi Scott, Scott MacVicar wrote: Can you try a debug build with --enable-debug to get a more detailed backtrace. Also what is the exact configure line and which apache 2 model are you using? Worker or Pre-fork? Scott On 29 Mar 2008, at 01:12, Jeremy Privett wrote: Hey list, I really /really/ hate to cause additional noise on this list, but I'm developing software in the PHP 5.3 snapshots with a timeline for release around the same time this version of PHP is released. We always try to keep current with our snapshots to make sure everything still works. My development team has been grinded almost to a halt by the fact that any thrown exception in the latest PHP 5.3 snapshots is causing Apache to crash. There's already a bug report here: http://bugs.php.net/bug.php?id=44226 I know unreleased PHP versions can't be supported, but fundamental language functionality was broken. This bug has been open for a month. This seems like it would be a critical problem and I'm glad Jani had already looked at and responded to the report. This is just slowing my team down when the snapshots are generally pretty high quality, from my personal experience. If this could be looked at further, I would gladly help someone with debugging and testing and such, if they'll take a look at the code. Thanks. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. I mentioned it in my response to the bug report, but forgot to mention it here. I'm just using pre-built Windows Binaries for each. I'm on Windows XP Pro with SP2. Using Apache 2.2.8. Not sure what the exact Apache model is. Thanks for looking into this for me. Hey Scott and list, I wanted to check on this issue to see if anyone was actively working on it and see what I could do to help. Thanks. Another week later and still no response. I would hope /someone/ thinks this a critical issue and needs to be resolved. Is /anyone/ looking at this at all? Thanks. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation.
Re: [PHP-DEV] Exceptions = Apache Crash in PHP 5.3 Snaps
Scott MacVicar wrote: Jeremy Privett wrote: Another week later and still no response. I would hope /someone/ thinks this a critical issue and needs to be resolved. Is /anyone/ looking at this at all? Thanks. The line that is crashing was last changed by Dmitry on January 24th, see http://php.markmail.org/message/7egzhpab6reff7lj I can't see any errors with valgrind. Any idea Dmitry? Scott Thank you, Scott. The problem only seems to occur in Apache. Trying to reproduce in CLI or in IIS using ISAPI results in no problems. I've tested from Apace 2.2 all the way back to Apache 1.3.39 and get the same result. I can have a friend of mine test the issue in Linux to make sure it's not just a Windows issue. I'll get back to you about that. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions = Apache Crash in PHP 5.3 Snaps
Jeremy Privett wrote: Hi Scott, Scott MacVicar wrote: Can you try a debug build with --enable-debug to get a more detailed backtrace. Also what is the exact configure line and which apache 2 model are you using? Worker or Pre-fork? Scott On 29 Mar 2008, at 01:12, Jeremy Privett wrote: Hey list, I really /really/ hate to cause additional noise on this list, but I'm developing software in the PHP 5.3 snapshots with a timeline for release around the same time this version of PHP is released. We always try to keep current with our snapshots to make sure everything still works. My development team has been grinded almost to a halt by the fact that any thrown exception in the latest PHP 5.3 snapshots is causing Apache to crash. There's already a bug report here: http://bugs.php.net/bug.php?id=44226 I know unreleased PHP versions can't be supported, but fundamental language functionality was broken. This bug has been open for a month. This seems like it would be a critical problem and I'm glad Jani had already looked at and responded to the report. This is just slowing my team down when the snapshots are generally pretty high quality, from my personal experience. If this could be looked at further, I would gladly help someone with debugging and testing and such, if they'll take a look at the code. Thanks. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. I mentioned it in my response to the bug report, but forgot to mention it here. I'm just using pre-built Windows Binaries for each. I'm on Windows XP Pro with SP2. Using Apache 2.2.8. Not sure what the exact Apache model is. Thanks for looking into this for me. Hey Scott and list, I wanted to check on this issue to see if anyone was actively working on it and see what I could do to help. Thanks. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: mlively
Mike Lively wrote: Maintenance on runkit/classkit. I've talked with pollita and she seems happy about it ;) I'm working on a project that would benefit from runkit, so this would be lovely. There was a bug that was giving me grief, previously. If I remember what it was, I'll let you know. :-P -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation Web:http://www.omegavortex.net E-Mail: [EMAIL PROTECTED] Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Exceptions = Apache Crash in PHP 5.3 Snaps
Hey list, I really /really/ hate to cause additional noise on this list, but I'm developing software in the PHP 5.3 snapshots with a timeline for release around the same time this version of PHP is released. We always try to keep current with our snapshots to make sure everything still works. My development team has been grinded almost to a halt by the fact that any thrown exception in the latest PHP 5.3 snapshots is causing Apache to crash. There's already a bug report here: http://bugs.php.net/bug.php?id=44226 I know unreleased PHP versions can't be supported, but fundamental language functionality was broken. This bug has been open for a month. This seems like it would be a critical problem and I'm glad Jani had already looked at and responded to the report. This is just slowing my team down when the snapshots are generally pretty high quality, from my personal experience. If this could be looked at further, I would gladly help someone with debugging and testing and such, if they'll take a look at the code. Thanks. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation.
Re: [PHP-DEV] Exceptions = Apache Crash in PHP 5.3 Snaps
Hi Scott, Scott MacVicar wrote: Can you try a debug build with --enable-debug to get a more detailed backtrace. Also what is the exact configure line and which apache 2 model are you using? Worker or Pre-fork? Scott On 29 Mar 2008, at 01:12, Jeremy Privett wrote: Hey list, I really /really/ hate to cause additional noise on this list, but I'm developing software in the PHP 5.3 snapshots with a timeline for release around the same time this version of PHP is released. We always try to keep current with our snapshots to make sure everything still works. My development team has been grinded almost to a halt by the fact that any thrown exception in the latest PHP 5.3 snapshots is causing Apache to crash. There's already a bug report here: http://bugs.php.net/bug.php?id=44226 I know unreleased PHP versions can't be supported, but fundamental language functionality was broken. This bug has been open for a month. This seems like it would be a critical problem and I'm glad Jani had already looked at and responded to the report. This is just slowing my team down when the snapshots are generally pretty high quality, from my personal experience. If this could be looked at further, I would gladly help someone with debugging and testing and such, if they'll take a look at the code. Thanks. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. I mentioned it in my response to the bug report, but forgot to mention it here. I'm just using pre-built Windows Binaries for each. I'm on Windows XP Pro with SP2. Using Apache 2.2.8. Not sure what the exact Apache model is. Thanks for looking into this for me. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a final decision
Pierre Joye wrote: 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 bug reports about this problem, especially when the reporters begin to spam me and other with all possible funny words ;-) There is not really a need to discuss the removal again, that's why I ask for a simple vote: +1: remove them (as it is now in HEAD) -1: Restore them and always return FALSE (not 0) 0: I don't care, do what you wish, I never use them anyway Feel free to comment the topic but please don't start an endless discussion, we already discuss it to death two years ago (yes, two years ago :-) Thanks, +1 -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation Web:http://www.omegavortex.net E-Mail: [EMAIL PROTECTED] Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[Fwd: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP]
Forgot to CC list. Original Message Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP Date: Mon, 21 Jan 2008 10:07:43 -0600 From: Jeremy Privett [EMAIL PROTECTED] Organization: Omega Vortex Corporation To: Antony Dovgal [EMAIL PROTECTED] References: [EMAIL PROTECTED] Antony Dovgal wrote: 6 reasons why we must to get rid of The Switch ASAP 1) it gives users false sense of compatibility when no compatibility is even planned; 2) it's supposed to mean compatibility, but can be changed only in php.ini, which means users would still have to maintain 2 versions of their software: one for On and second for Off. 3) 2+ bigger codebase [1] (with lots of duplicates because we have to do same things in native and unicode modes); 4) increases the maintenance costs a lot [2]; 5) this is yet another reincarnation of ze1_compatibility switch. I believe most of the people here agree it was a total failure - untested, unneeded and, most important, not working thing that complicates user's and developer's lives. Those who want compatibility may and will stay with PHP5 forever, those who need Unicode support will use PHP6. 6) we need to remove the switch ASAP and make PHP6 Unicode-only before people spend their time doing useless compatibility ports of their applications. --- [1] http://cvs.php.net/viewvc.cgi/php-src/ext/standard/string.c?revision=1.664view=markup Don't click this link if you want to sleep well today. [2] Here is a typical problem: http://bugs.php.net/bug.php?id=42861 Try to fix it without looking at the solution and you'll see what I mean. Seriously. +1 Thank you, Antony. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation Web:http://www.omegavortex.net E-Mail: [EMAIL PROTECTED] Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[Fwd: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP]
Forgot to CC list again. Just not my day. Original Message Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP Date: Mon, 21 Jan 2008 10:11:32 -0600 From: Jeremy Privett [EMAIL PROTECTED] Organization: Omega Vortex Corporation To: Geoffrey Sneddon [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Geoffrey Sneddon wrote: On 21 Jan 2008, at 14:38, Antony Dovgal wrote: 3) 2+ bigger codebase [1] (with lots of duplicates because we have to do same things in native and unicode modes); From the cross-reference I assume you mean PHP's codebase. We still need binary string support — Unicode is only suitable for textual content. Images, for example, are binary data and we still need binary strings for them. Not everything people deal with in PHP is a textual string. He could really be referring to both, honestly. The size of codebases in PHP applications will grow as a result, as developers will have to provide the compatibility ports for making their code work with both the switch on and off. Either that, or they just have to support one or the other, but not both. Which results in vendors alienating their userbase because they happen to be on a host or server that has the option set out of their favor for whatever reason. And if I remember correctly, there's an explicit typecast (binary) for binary data now, isn't there? -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [Fwd: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP]
Tomas Kuliavas wrote: On 21 Jan 2008, at 14:38, Antony Dovgal wrote: 3) 2+ bigger codebase [1] (with lots of duplicates because we have to do same things in native and unicode modes); From the cross-reference I assume you mean PHP's codebase. We still need binary string support — Unicode is only suitable for textual content. Images, for example, are binary data and we still need binary strings for them. Not everything people deal with in PHP is a textual string. He could really be referring to both, honestly. The size of codebases in PHP applications will grow as a result, as developers will have to provide the compatibility ports for making their code work with both the switch on and off. Either that, or they just have to support one or the other, but not both. Which results in vendors alienating their userbase because they happen to be on a host or server that has the option set out of their favor for whatever reason. And if I remember correctly, there's an explicit typecast (binary) for binary data now, isn't there? unicode and binary typecasts are not backwards compatible. I think the emphasis on the PHP6 release needs to be taken off the backwards compatibility and placed more on fixing what's broken about the current solution. If people need Unicode to the point that they're willing to make the jump to PHP6, then they'll do just that. It's terribly inefficient to try and make everything easy on everyone and your end result is hurting the internals developers for the sheer amount of headache that's being caused by the current implementation. You can't have it all, so instead of trying to make PHP6 backwards compatible, how about the focus be placed on making it BETTER than PHP5? -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation.
Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
Tomas Kuliavas wrote: 5) this is yet another reincarnation of ze1_compatibility switch. Which is the worst mistake ever imo - If you wanted PHP 4 you would simply use PHP 4. Now if you want PHP 5 just damn use PHP 5. And if you don't control PHP version used by end user? Only bad in-house apps are written for one specific PHP version and setup. you're point being? Without the requested change here you would have one more version, resulting in PHP 5.*, PHP 6.*-unicode, PHP6.*-native. there is only a little difference between php5 and php6 with unicode.semantics off. php6 with unicode.semantics on design is broken. It replaces standard functions that worked same way through all PHP4-5 versions and forces use of code that is totally backwards incompatible. binary and unicode typecasting triggers E_PARSE errors in older PHP versions. I can't mix PHP6 and older PHP code in one script or library or function. PHP introduced changes similar to unicode.semantics=on with mbstring function overloading. When I learned about it, I've stopped trusting ereg and string functions. With mbstring overloading I still have options to disable broken design. With unicode semantics I am forced to use features provided by interpreter instead doing things the way I want and having better controls over script. PHP with unicode.semantics on is more suitable for novice developers who are not familiar with character sets and lazy developers, who want their PHP4-5 code to become Unicode aware without any changes on their side. If PHP4-5 code works with multiple charsets and 8bit data, it will break in PHP6. I don't care if you remove this setting. I'll find the way to make my code work. but don't expect me to remain silent if you say that it is a good thing. It is good for PHP codebase. It is not good for portable PHP script developers. Removal of setting forces developers to drop 5.2.0 and older versions or to maintain two library versions. If setting remains, developers can ask to turn it off. PHP_INI_SYSTEM is php.ini and httpd.conf. And most people on shared servers don't have access to httpd.conf. As long as it's not PHP_INI_PERDIR, unicode.semantics will never be an acceptable solution. In my opinion, even if it were PERDIR, it still wouldn't be an acceptable solution as you'll still have portability problems, either way. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation Web:http://www.omegavortex.net E-Mail: [EMAIL PROTECTED] Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation.
Re: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
Hi Greg, I'm speechless. All of your points are sound and you've obviously done your homework, here. I agree with Ken in that you've gone above and beyond on the research and arguments you've presented here. Excellent work and a hearty +1 to all of your points. Jeremy Gregory Beaver wrote: Hi Derick, I've been thinking a *lot* about your provocative email in the past couple of days, and have come to a different conclusion from my original reply (which, as a reminder stated I saw no problem with removing namespaces as long as we kept the import facility to alias classes via use). After a few hours of thinking practically about the implementation, I realized that this would be impossible for the same reasons as your first argument. So, I set out to find a solution that keeps namespaces and solves the problems. I have found the solutions to every problem I could find, and to my surprise, even after crafting a new patch to solve some of them, have found a way to solve all of the problems within the existing implementation (with a few tweaks, but nothing major changed) or by specifying new coding conventions. Summary: 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. 2) use Name::*; is technically impossible without some kind of autoloading mechanism, but can be reasonably approximated by importing a long namespace name as a shorter one. use PEAR2::Really::Long::Name as a; then allows referring to PEAR2::Really::Long::Name::Classname as a::Classname, and PEAR2::Really::Long::Subnamespace::Classname as a::Subnamespace::Classname. 3) multiple namespaces per file should be allowed, but strongly discouraged as a coding practice of last resort for most users. 4) brackets for namespaces is most necessary for hierarchical namespace implementations. This is not such an implementation, and as such brackets do not add clarity but do slow down the implementation. 5) namespaces provide these benefits that are not available in PHP: a) short, unqualified descriptive class names can be used without fear of conflicting with an internal class b) a clear, uniform coding convention on how to avoid conflicts between your code and others that will help those who have to maintain the code of others. c) a way to alias longer names to increase readability and maintainability of code. 6) There are some dangers when using namespaces with autoload, but simple ways of thwarting those dangers. Also dangerous is trusting external code that is in the same namespace, as functions can be redefined. Detailed answers: Derick Rethans wrote: 1. As it is impossible to do use XXX as NativeClass we get to the snip extension (DateTime, DateTimeZone). However introducing the new class DateTimeSpan might break people's code that do things like: ?php use myNamespace::DateTimeZone as DateTimeZone; ? This is indeed the biggest problem. However, it only exists in the global namespace (non-namespaced code). An example script using the non-existing hypothetical PEAR2::DateTime class: ?php include 'PEAR2/Autoload.php'; use PEAR2::DateTime; // fatal error - use name conflicts with internal class $a = new DateTime; ? However, the answer is simple and elegant. PHP applications that take advantage of namespaces should use a namespace *in the application global code* that is reserved for application code, like __php__. ?php namespace __php__; include 'PEAR2/Autoload.php'; use PEAR2::DateTime; $a = new DateTime; // $a is an object of class PEAR2::DateTime after autoloading, or if a previously included file has declared class DateTime in namespace PEAR ? Note that the only difference here is the addition of 1 line of code at the top of the file. On the same token, this code: ?php namespace __php__; $a = new DateTime; // $a is an object of class ::DateTime ? works as expected, accessing the internal DateTime class directly. In other words, 1 line of code is needed to take advantage of namespace's full protection and ability to import conflicting class names into the global (in this case unqualified, not containing :: in the name) scope, while at the same time preserving BC with existing code (no modification needed beyond addition of namespace __php__;). I recommend that the manual specify this convention, and will happily take on the documentation of it. 2. You have to import every class yourself. You can currently not do: use myNamespace::* as *; // or similar syntax Actually, ::* would only be deterministic if use performed some kind of autoloading, it's not a question of runtime versus compile-time - it's simply not possible to determine which class is intended if more than one ::* is used unless the answer is determined by code loading, this is why Java/Python import
Re: [PHP-DEV] Namespace
Stanislav Malyshev wrote: implementation [details] not the concept. I believe that the implementation needs a little ironing out ... what's the harm in taking the time to do this? or at least taking the time to let consensus take hold? No harm, but we will have multiple namespaces per file figured out pretty soon, and I don't see any new developments with the braces thing, so what exactly would we wait for? metrics that support your argument that namespaces will make code more maintainable, offer better structure and cleaner code. Obviously, we can't have any metrics of anything until the namespaces are implemented and used in some serious project, which can't happen until we have a release with namespaces in it. it remains nothing more than a pontential even after release. in the same For some time, yes. And if one chooses not to use it, maybe forever for that particular user. I'm all for discussing practical ones, but frankly I don't see any new issues here worth delaying anything. Hey Stas, I just felt the need to send a note in to say thank you for working to keep the namespaces implementation in. I've been developing toward PHP 5.3 and would be sorely disappointed if I had to re-write all of my libraries to remove the use of namespaces. So, thanks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace
Larry Garfield wrote: On Wednesday 05 December 2007, Stanislav Malyshev wrote: implementation [details] not the concept. I believe that the implementation needs a little ironing out ... what's the harm in taking the time to do this? or at least taking the time to let consensus take hold? No harm, but we will have multiple namespaces per file figured out pretty soon, and I don't see any new developments with the braces thing, so what exactly would we wait for? Actually, as I've said previously IF we switch to multiple namespaces per file (which I honestly have no strong opinion on), switching to braces at the same time makes sense. It's much easier to parse visually (by a human) in that case, and there's no reason I know of why we couldn't still forbid non-namespaced code in a namespace-using file to avoid confusing weirdness. I know I just finished praising you just some hours ago, Stas, but I'm going to have to step in and agree with Larry on this one. It really doesn't make sense for there to be no braces for namespaces (especially if you're going to allow multiple per file). A namespace is a logical grouping of classes/functions and other constructs of this type in PHP use braces. That is very confusing syntax when compared to other areas of the language. Jeremy
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
Richard Quadling wrote: On 15/11/2007, Sam Barrow [EMAIL PROTECTED] wrote: I found a patch by Derick online to allow for scalar type hinting, and made it work with the newest snapshot of PHP 5.3. I also added the ability to type hint for resources. I would like to ask that it be added to the next PHP release. It allows type hinting for int, float, bool, string, resource, and object, I also added the ability to use the secondary keywords for all of these types (such as double, real, long, etc.). It will maintain 100% backwards compatibility, as the type hinting is 100% optional, implemented in the same way as array/class type hinting. I have the patch on my PC, please let me know where and when i can submit it. I'd be happy to do the patching and submission myself, just asking for permission here. What happens for type conversion? Is the param cast to the hinted type? The idea of type hinting for array and class is to make sure you get something appropriate. Rarely would you think of an array and cast it as an integer (or vice versa), so it makes sense. But with a string (0), an integer (0) or a boolean (false), they are all the same, so does this mean we would be having to cast all the params to the function/method? I imagine that it will behave the same was as the other type hinting and just bomb out if the incoming data is of the wrong type. It kind of defeats the purpose of type hinting if it's really just type casting in the method call. To your point, I think it would really only help those OCD developers among us who always use === and try to make PHP behave like a strongly typed language. --- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation
RE: [PHP-DEV] Renaming namespaces to packages
Hey Stanislav, I think the issue is that of confusion. When I first heard PHP6 was going to have namespaces, I was expecting namespaces like C++ or C#. What was actually provided was confusing, at first, because it didn't behave like namespaces in other languages that I've used. Personally, I don't care what the name is, as long as the feature is implemented. But, coming from a background in C++ and C#, I do believe that the namespaces name is a bit misleading. Calling the implementation packages would make more logical sense. All that matters now is that it gets implemented, really. My two cents. Thanks. --- Jeremy Privett Software Developer Zend Certified Engineer Peak8 Solutions -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 10:30 AM To: Derick Rethans Cc: Dmitry Stogov; 'Johannes Schlьter'; 'PHP Internals List' Subject: Re: [PHP-DEV] Renaming namespaces to packages Well, our implementation is not namespaces, packet doesn't have any Where I can see definition of what is namespaces and what is not? I can live with packages, though I like this name less - but what I don't really understand is why anything that doesn't work like c++ namespaces can't now be named namespaces - do they have a trademark on it or what? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Type-hinted return values in PHP5?
And Zend Studio does this for you already, if you use comment your code correctly. I really don't see a good use for this, either. Jeremy -Original Message- From: Larry Garfield [mailto:[EMAIL PROTECTED] Sent: Saturday, July 28, 2007 6:05 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5? On Saturday 28 July 2007, Stanislav Malyshev wrote: It would give you similar benefits to input type hinting, but instead of Functions are now able to force parameters to be objects..., it would also read Calling functions are now able to expect return types to be objects If a function was defined to return object Z, but instead returned false, then obviously there is something wrong and it could be caught before calling code sees it expecting it to be something else. Catching language-level error in application code is usually harder than just handling it in user code. And if you are talking about distinction between false/null and actual object, language level is the wrong level to catch such things. If you handle the error in runtime, you could have the check as well. If you don't, the script breaks anyway, so it is not going to help you much. Even more, the return value is the product of the module code, while input values are product of the outside code. So when you say I'm going to process only type X, and I make a requirement for others to pass only X to me, it makes for me more sense than saying I'm going to return only type X so I'm making restriction for myself to return only type X. The latter is more like declaring variable types, which have its functions in compiled languages but usually is not happening in dynamic interpreted languages. Also, since from the client side there's no way to check if the function you are calling actually does have the return type restriction, it's quite hard to program basing on that from the client side. So you actually check it in one place (library) and use it in entirely different place (client) which is usually bad idea since the client becomes too reliant on internal details of the library. If I, or someone else decided to make a patch for this, and assuming it worked exactly like I described, would it be accepted? I don't know... I personally don't see much use for it, but others may disagree. I think the only serious advantage I could see would be to allow context-assistance IDEs more data, so they could provide method-completion. As nice a feature as that would be, I don't think it's worth modifying the language syntax for. I agree that in a loosely typed language that sort of thing needs to be checked by the application code anyway. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Question about Namespace patch
Stanislav, Absolutely not the case. Take a look at C++, C#, even Python. The namespaces implementation of those languages is mostly consistent (even if Python doesn't call it that). You're not helping developers at all with this implementation. If you're working with a large library and have to import a lot of classes, the way this works is nothing but a pain. We would be better off not using namespaces at all, in this case. Thus, the problem has not been solved. Also, for the implementation to be complete, Core Developers and Extension Developers would need to namespace their classes / functions. And that, undoubtedly, is a LOT of work. I can understand this being the justification for implementing namespaces in the way it's been implemented, because all of this other stuff in the global namespace, but you still need to offer developers *some* way of importing everything out of a namespace. I absolutely will have upwards to close to 25 - 30 classes in a single namespace. And sometimes more. To be able to import them all is an absolute necessity for this implementation to be remotely feasible. Having an import block at the top of files that's that huge just doesn't make any sense. And that doesn't even consider the fact that I may be using OTHER libraries as well that may be namespaced. PEAR is a perfect example of this. Look at all the libraries that exist there. I would absolutely love to just: import PEAR; import PEAR::HTTP; import PEAR::Image; And not have to worry about going through and picking out every little individual class that I need. And with all of the languages I mentioned before, that is *exactly* how it works. Of course, we're back to the namespacing of the PHP Core and Extensions. Which is really the main blocker to any serious namespaces implementation, beyond what's currently patched to HEAD today, correct? I hope you can better see my viewpoint, now that I actually had the time to sit down and type out a more coherent reply. This implementation and the unicode.semantics discussion have to be the most frustrating points PHP6 has for me, right now. Thanks. --- Jeremy Privett Software Developer Peak8 Solutions -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 1:39 AM To: Jeremy Privett Cc: Derick Rethans; Markus Fischer; internals Subject: Re: [PHP-DEV] Question about Namespace patch And that's exactly why this implementation isn't intuitive. As far as I can see from the way it's been explained, so far, that is not possible. No implementation is intuitive, unless by intuitive you mean works as in that other language I know. Too bad in each of these languages it works differently :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Question about Namespace patch
Alexey, I honestly wish that were the case with the situation I'm dealing with at my current job. And I know a lot of people that are absolutely in the same boat as I am. I definitely understand your reasoning here, but we're obviously talking about design versus convenience. This is one of those situations where convenience makes the difference. Was there ever a decision on whether or not the patch is going to be backported to PHP5? I think I'll grab a PHP6 snapshot and toy around with the implementation a bit. Who knows ... it may grow on me. We'll see. Thanks. --- Jeremy Privett Software Developer Peak8 Solutions -Original Message- From: Alexey Zakhlestin [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 2:14 AM To: Jeremy Privett Cc: Stanislav Malyshev; Derick Rethans; Markus Fischer; internals Subject: Re: [PHP-DEV] Question about Namespace patch In reality, it is rarely (almost never) needed to import all the classes. Usually you need 2-4 per file, not more, and importing just what you really need is the step to a clean design. You don't need to import every class which is used implicitly, only those which are explicitly used. On 7/23/07, Jeremy Privett [EMAIL PROTECTED] wrote: Stanislav, Absolutely not the case. Take a look at C++, C#, even Python. The namespaces implementation of those languages is mostly consistent (even if Python doesn't call it that). You're not helping developers at all with this implementation. If you're working with a large library and have to import a lot of classes, the way this works is nothing but a pain. We would be better off not using namespaces at all, in this case. Thus, the problem has not been solved. Also, for the implementation to be complete, Core Developers and Extension Developers would need to namespace their classes / functions. And that, undoubtedly, is a LOT of work. I can understand this being the justification for implementing namespaces in the way it's been implemented, because all of this other stuff in the global namespace, but you still need to offer developers *some* way of importing everything out of a namespace. I absolutely will have upwards to close to 25 - 30 classes in a single namespace. And sometimes more. To be able to import them all is an absolute necessity for this implementation to be remotely feasible. Having an import block at the top of files that's that huge just doesn't make any sense. And that doesn't even consider the fact that I may be using OTHER libraries as well that may be namespaced. PEAR is a perfect example of this. Look at all the libraries that exist there. I would absolutely love to just: import PEAR; import PEAR::HTTP; import PEAR::Image; And not have to worry about going through and picking out every little individual class that I need. And with all of the languages I mentioned before, that is *exactly* how it works. Of course, we're back to the namespacing of the PHP Core and Extensions. Which is really the main blocker to any serious namespaces implementation, beyond what's currently patched to HEAD today, correct? I hope you can better see my viewpoint, now that I actually had the time to sit down and type out a more coherent reply. This implementation and the unicode.semantics discussion have to be the most frustrating points PHP6 has for me, right now. Thanks. --- Jeremy Privett Software Developer Peak8 Solutions -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 1:39 AM To: Jeremy Privett Cc: Derick Rethans; Markus Fischer; internals Subject: Re: [PHP-DEV] Question about Namespace patch And that's exactly why this implementation isn't intuitive. As far as I can see from the way it's been explained, so far, that is not possible. No implementation is intuitive, unless by intuitive you mean works as in that other language I know. Too bad in each of these languages it works differently :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Question about Namespace patch
Yes, because that's ABSOLUTELY the way to respond to the community that has continued to support PHP. If that is what this discussion is going to degrade to, you're essentially saying Please, gives us feedback but we're not listening. If this is the case, then I'll keep in mind and make sure it's known that bringing your issues and feedback to the PHP Devs is such a lovely waste of time and energy. Thanks. --- Jeremy Privett Software Developer Peak8 Solutions -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicolas Bérard-Nault Sent: Monday, July 23, 2007 10:03 AM To: Derick Rethans Cc: David Zülke; PHP Internals Subject: Re: [PHP-DEV] Question about Namespace patch Despite all the comments made on this list by countless people, it's still Stanislav's way or the highway. I don't want to sound negative but come on... this is getting ridiculous. Stanislav, why don't you just tell everybody that you'll stop answering because the patch will stay AS IT IS over your dead body anyway ? I think you'll save us all some time. This discussion is endless and not productive. I can't speak for anybody here but I think a vote by all people who have commit access to php-src would clarify this issue once and for all so we can just move along. But that's just my 2 cents. On 7/23/07, Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 23 Jul 2007, David Zülke wrote: Am 23.07.2007 um 16:25 schrieb Brian Moon: import SQLAlchemy::Column import SQLAlchemy::Table import SQLAlchemy::Join import SQLAlchemy::ForeignKey import SQLAlchemy::Session import SQLAlchemy::Transaction Why use namespaces if you are going to do this? You are just bringing your classes into the global name space. The nice thing about namespaces IMO, is that I don't have to have a class named SQLAlchemy_Transaction. I can just have a class named Transaction in the SQLAlchemy namespace. I can then create a new object using $obj = new SQLAlchemy::Transaction. Oh yes, sure, that must be the main point about namespaces - I can use :: instead of _ as a delimiter! Yay! You forgot that you can also move the prefix in front of the class name to namespace prefix! Come on, you can't be serious. I sort of agree, I don't see how the current implementation is really useful for anything. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Nicolas Bérard-Nault ([EMAIL PROTECTED]) Étudiant D.E.C. Sciences, Lettres Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Question about Namespace patch
I wasn't referring to that. I know you've been responding to feedback. I was referring to Nicolas' suggested reply. --- Jeremy Privett Software Developer Peak8 Solutions -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 10:43 AM To: Jeremy Privett Cc: Nicolas Bérard-Nault; Derick Rethans; David Zülke; PHP Internals Subject: Re: [PHP-DEV] Question about Namespace patch Yes, because that's ABSOLUTELY the way to respond to the community that has continued to support PHP. If that is what this discussion is going to degrade to, you're essentially saying Please, gives us feedback but we're not listening. I responded - with arguments, explanation or reference to prior arguments - to every comment on the list. It is hardly not listening. Maybe not agreeing - but nobody promised you to agree with everything you say here. It's not what feedback means. It means you will be listened to, your proposals would be weighted, discusses and seriously considered. That is what you are getting. I can not promise you immediate acceptance - and nobody would. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
3 - How will PHP behavior on a situation that you have a naming conflict?
Something like...
?php
class Bar { ... }
?php
namespace Foo {
class Bar { ... }
}
?php
import Foo;
$b = new Bar();
Well, PHP's namespaces don't behave like every other language I've ever used
that supports namespaces. So, the code snippet you used here wouldn't work,
anyway.
Jeremy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
For 100th time, import Foo is a no-op. I'm thinking about prohibiting it at all... If you do import Foo::bar you'll get an error if Bar is already defined. I'm still trying to figure out why you think this is an acceptable implementation of namespaces. This isn't namespaces at all. This is barely an acceptable method of shortening classnames. What are we, as developers, supposed to do on a namespace that has a particularly large number of available classes? Import them all individually? So, I now need to go from having a file that includes necessary libraries to a file that needs to import them all? That's REAL intelligent design, right there. --- Jeremy Privett Software Developer Peak8 Solutions -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
I'm going to have to agree with Larry, here. If there's no *real* namespace
implementation in PHP6, there may as well not be one at all. Take a look around
at the countless other languages that already have this functionality. You're
gimping the language further if you implement namespaces without such core
functionality as this.
Regards,
Jeremy
-Original Message-
From: Larry Garfield [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 08, 2007 1:13 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Simple Namespace Proposal
Yes, it would be. What's the problem with that?
I'm coming from the background of a plugin-based architecture where plugins
routinely add functions that would, conceptually, exist in a different
namespace.
That would require having both multiple namespaces per file and multiple files
per namespace. If we can't do that then we're back to using static classes
as if they were namespaces.
On Sunday 08 July 2007, Dmitry Stogov wrote:
-1 for braces and multiple namespaces per file
Braces will allow define something outside namespace and I like to avoid
this possibility.
In the following correct example function bar() is defined in global
namespace.
?php
namespace A::B {
function foo() {
}
}
function bar() {
}
?
Dmitry.
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann
Sent: Sunday, July 08, 2007 10:13 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Simple Namespace Proposal
Nicolas Bérard-Nault schrieb:
+1 for braces around namespace definition.
-0 on that, because there is no clear standard with regard
to how other programming languages solve this.
Java does not require braces with its package construct
[1] and C# does for its namespace construct [2].
--
[1]
http://java.sun.com/docs/books/jls/third_edition/html/packages.html
[2] http://www.jaggersoft.com/csharp_standard/8.12.htm
--
Sebastian Bergmann
http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867
C514 B85B 5D69
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it. -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
-Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 19, 2007 9:09 AM To: Rasmus Lerdorf Cc: Peter Brodersen; internals@lists.php.net Subject: Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6? On 6/19/07, Rasmus Lerdorf [EMAIL PROTECTED] wrote: But this is no different from writing code that will work on both PHP 5 and PHP 6. The only difference is that instead of checking for PHP 5 you will be checking for Unicode. Like I said, we don't want the Unicode decision to be synonymous with PHP 5 vs. PHP 6 because then the non-Unicode folks will never get the benefits of the non-Unicode improvements in PHP 6 and we would be forced to support PHP 5 for a lot longer. We really stretch our already thing resources in order to support multiple branches, so anything we can do to get as many people as possible onto the same codebase helps us a lot. Just as a last (hopefully) comment, even if nothing seemed to have an influence, no matter how many we are to prefer a unicode only mode (so far only you are in favour of it, maybe Andree too but I don't remember his opinion on this topic :). The gain we hope to have by keeping a non unicode mode is about having more users moving to PHP6. I would like to know why it will work better than with php5, any thoughts? And let forget that maintaining (and develop/implement) these two modes will obviously take more time. Cheers, --Pierre I remember when PHP 5 came out. All the apps I worked on and any I saw that was worth its salt took very little effort to get working in the new PHP version. The BC breaks weren't that bad. With that said, PHP 5 adoption was ... slow, at best. unicode.semantics is not the way to solve this problem in PHP 6. The big push for PHP 6 is UNICODE SUPPORT. And you're making this a switch that you can simply turn on and off? That's not how you move people onto the new version, that's how you keep people AWAY from it. Vendors are not going to be bothered to update their products to support PHP 6 with unicode on and off. And if they only write it one way or the other, they'll lose sales because it won't work on Customer A, B, and C's hosts. So, what will they do? Stay in stable waters for as long as they can. Which means, nobody's leaving PHP 4 or 5. PHP can afford a BC break, trust me. If you want people to adopt PHP 6, don't make it harder for them to do so. unicode.semantics does NOT make it easier for the vendors (who control PHP adoption, by the way -- it's all about who's programming the products for the versions) to adopt PHP 6. It makes it harder. You say you want to move people onto PHP 6 as seamlessly as possible by making it easy to port code written in PHP 5 onto it, and that's great. But, it's not the correct solution. Because, these people will have to live with the knowledge that their code works on PHP 5, and on SOME distributions of PHP 6. You want people off of PHP 4 and PHP 5? Put together a plan to drop ALL support for these versions and PUBLICIZE the heck out of it. You let people KNOW that after PHP 6 is out, you have a steady plan to drop support for PHP 4 in x number of months and PHP 5 in x number of years(?). That way, if they want to continue getting security updates, they know where to go. And vendors will be more inclined to get their butts in gear to support updates in technology. In this situation, BC is going to be the bane of PHP's existence. By enabling unicode.semantics, you are polluting what PHP 6 was supposed to be and giving an excuse to people who are lazy and don't want to do the extra work necessary to support the changes. And those people will not do them, if you don't force them to. Meaning, their apps will work on PHP 5 and a subset of PHP 6 installations. But, let's look at this situation from another angle. What if unicode.semantics becomes the next magic_quotes or safe_mode, and is ALWAYS OFF in 95%+ of PHP installations? All of the work you did to add unicode support was WASTED on this presumption that if you don't have BC, no one's going to use it. Whereas the opposite is clearly true, in this case. If you have BC, it'll get used simply because it works with old code, but the main thing that changed about the language will never be touched. -- Jeremy Privett PHP Developer Zend Certified Engineer Peak8 Solutions -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Known Issues with PHP6 on Windows?
Antony Dovgal wrote: On 02/07/2007 08:08 AM, Jeremy Privett wrote: Hey everyone, I was just curious if there were any known issues with the PHP6 builds on Windows. I've been trying to set a build up in my local environment and Apache keeps throwing this error at me: Syntax error on line 173 of C:/Apache2/conf/httpd.conf: Can't locate API module structure `php6_module' in file C:/php6/php6apache2.dll: No error It's still php5_module. But this should be changed in the next snapshot. Perfect, that fixed it. Thanks. -- Jeremy C. Privett Chief Operating Officer Zend Certified Engineer Completely Unique [EMAIL PROTECTED] Phone: 303.459.4819 Mobile:303.883.0312 Fax: 303.459.4821 Web: www.completelyunique.com This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. Your compliance is appreciated. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Known Issues with PHP6 on Windows?
Hey everyone, I was just curious if there were any known issues with the PHP6 builds on Windows. I've been trying to set a build up in my local environment and Apache keeps throwing this error at me: Syntax error on line 173 of C:/Apache2/conf/httpd.conf: Can't locate API module structure `php6_module' in file C:/php6/php6apache2.dll: No error Thanks. -- Jeremy C. Privett Chief Operating Officer Zend Certified Engineer Completely Unique [EMAIL PROTECTED] Phone: 303.459.4819 Mobile:303.883.0312 Fax: 303.459.4821 Web: www.completelyunique.com This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. Your compliance is appreciated. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP / C++ Interaction
On 2/13/06, Andrew Mather [EMAIL PROTECTED] wrote:
- can I talk to a C++ library from PHP, either directly or via
a PHP/C extension?
You could just have the PHP extension written in C++. There is no
requirement of PHP extensions to be written in C, you just need to make sure
you properly wrap the C parts inherited from the core w/ an extern C block.
I have wrapped more than a handful of C++ libraries at my day job in into
PHP extensions using more or less the following approach.
Here's a rough overview of the changes needed (this list might not be
complete, but should be close).
config.m4 changes
-
I set the the compiler environment variables (aka CC and CXX) to both use
g++. Not sure if this is necessary.
In your included libraries (aka PHP_ADD_LIBRARY_WITH_PATH) make sure you
include libstdc++
your source file changes
---
Wrap the following in an extern C like shown below:
extern C {
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include php.h
#include php_ini.h
#include ext/standard/info.h
#include php_your_extension_name.h
}
And later on further down wrap the following:
extern C {
#ifdef COMPILE_DL_YOUR_EXTENSION_NAME
ZEND_GET_MODULE(your_extension_name)
#endif
}
As best as I can remember, that is all that is necessary to write a C++ PHP
Extension instead of a C one. Brighter minds on this list might know better
if I am forgetting something, but I remember it being very minimal changes
so I think the above is it.
-Jeremy
--
---
Jeremy Johnstone
http://www.jeremyjohnstone.com
[EMAIL PROTECTED]
Re: [PHP-DEV] Need help in defining a class from C code.
Kiput,
Even if you are right about the state of the PHP/Zend code/documentation
(which I am not commenting on either way), it's definitely not a wise idea
to insult the very people who wrote that code when asking for their
assistance. With that said, if no one else steps up with a code snippet
before I get home this evening, I would be happy to provide you with one.
-Jeremy
On 1/25/06, Kiput [EMAIL PROTECTED] wrote:
Hi.
I'm currently working on a tiny wrapper in C++ which will aid in
easy embeding PHP in C++ apps. Till now I managed to work on it
without any help, but this time I need your help guys - I'm tired of
that messy, undocumented PHP/Zend code. Could anyone (I'm sure it's 5
minutes of work, since most of you work with PHP/Zend frequently)
write me a snippet of code in C which would be equal to following PHP
code:
class Foobar
{
function __set( $name, $value )
{
echo( $name = $value );
}
function __get( $name )
{
echo( $name );
}
}
I was working, but since I've implemented resource zval type into my
lib it somehow (I even didn't noticed) stopped. =(
If this is wrong list then I'm sorry, thought my question is closely
tied to PHP's internals after all. =)
Thanks.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
---
Jeremy Johnstone
http://www.jeremyjohnstone.com
[EMAIL PROTECTED]
Re: [PHP-DEV] [PATCH] __toString()
Hello All, Was this actually added into PHP? Can anyone confirm if PHP's toString() magic method will work everywhere a string is used (aka printf, switch, etc)? If so, will this be possibly available in the 5.1x branch (since it's sorta a bug/consistency fix) or will it only make it into the next major release? -Jeremy On 9/28/05, Marcus Boerger [EMAIL PROTECTED] wrote: Hello Edin, cool, thanks! marcus Wednesday, September 28, 2005, 10:52:00 PM, you wrote: http://ftp.emini.dk/pub/php/win32/php6/ Edin Marian Kostadinov wrote: I'd like to do some tests of the new __toString functionality but it seems that it is committed only in PHP6-CVS branch. Is there a way to get a windows binary snapshot for this branch? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- --- Jeremy Johnstone http://www.jeremyjohnstone.com [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Named arguments revisited
Just to throw in my two cents since every one else has (not that my 2
cents is worth anything more than just that), but isn't it as easy as
doing something like the following:
(using pseudo example from above)
function db_connect($params) {
$host = 'localhost';
$user = 'root';
$password = '';
$port = 3301;
extract($params, EXTR_OVERWRITE);
// ... more code here
}
This covers the default parameters in a clean fashion which is easy to
understand and should be readable to anyone who knows PHP in even the
slightest fashion. Now to the issue of type hinting, it's as simple as
doing something like the following:
if(!($obj instanceOf ClassName)) {
throw new Exception();
}
Then you have complete control of how the error is handled (be it
exceptions, trigger_error(), etc). To me, it seems the options are a
LOT more flexible using array syntax than using actual named
parameters, but maybe that's just me. To each their own, but if it
were me, it seems the above not only is easier to use / read, but also
guaranteed to work on almost all versions of PHP (at least in the case
of the first code snippet).
--
---
Jeremy Johnstone
http://www.jeremyjohnstone.com
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bonsai.php.net 302 redirects to a bad URL (http:/cvs.php.net, aka missing / on http://)
Someone should likely check it out. telnet bonsai.php.net 80 Trying 66.163.161.116... Connected to cvs.php.net. Escape character is '^]'. GET / HTTP/1.1 Host: bonsai.php.net HTTP/1.1 302 Found Date: Thu, 05 Jan 2006 06:36:04 GMT Server: Apache/1.3.34 (Unix) PHP/5.1.2RC2-dev Location: http:/cvs.php.net/ Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 -- --- Jeremy Johnstone http://www.jeremyjohnstone.com [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 4.4 BC break
Or you as a developer add the following to your code: error_reporting(error_reporting() ~E_NOTICE); at the top of a common file and release a new release and quit f***ing bing about something which isn't likely to change anytime soon. If your clients aren't knowledgeable enough to setup their servers properly to not show errors in a production environment, then do it for them in your script. Yeah it's not the best solution, but it works fine and gives you time to correctly update your scripts the proper way. -Jeremy On 7/17/05, Jon Parise [EMAIL PROTECTED] wrote: On Tue, Jul 12, 2005 at 10:33:14PM +0100, Nicholas Telford wrote: Firstly, a major version number increment implies a major change (4.2.0 and 4.3.0 had much more major changes than this iirc). Secondly, as far as I'm aware, it doesn't issue a warning, it issues notices which, and this has been stressed on many occasions, should not be displayed on production servers. Sure, but the issue here has very little to do with production servers. What's happening is that site administrators are upgrading their test environments and then checking their existing software to make sure it hasn't broken. They see all of these new warnings and then report them back to the application developers. It would be much easier for each application developer to redirect that site administrators to a note on php.net explaining the change than for the application developers to explain the change over and over again. Or, even better, the administrator would find it there themself. -- Jon Parise (jon of php.net) :: The PHP Project (http://www.php.net/) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- --- Jeremy Johnstone http://www.jeremyjohnstone.com [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 4.4 BC break
On 7/12/05, Chuck Hagenbuch [EMAIL PROTECTED] wrote:
Yes, they could turn off warnings. But since the code has always run
cleanly beforehand, they don't think to do that.
It's definitely not the cleanest solution, but for those of you who
want to have a quick fix which will hide the problem until you have
time to fix it properly, use the following at the top of a common
file:
if(!defined('E_STRICT')) {
define('E_STRICT', 2048);
}
error_reporting(error_reporting() ~E_NOTICE ~E_STRICT);
Never depend on a user to do something for you that you can do
yourself. If you feel notice reporting should be off on a production
level script, then turn them off, and make it easy and documented for
them to turn it back on if they want it, not expect them to know how
to disable them theirself automatically.
--
---
Jeremy Johnstone
http://www.jeremyjohnstone.com
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] os x linking issue with extension
Although this list should be able to answer the question for you, another list which might be of assistance/interest to you is pecl-dev. http://pecl.php.net/support.php -Jeremy On Apr 3, 2005 2:00 PM, Michael Johnston [EMAIL PROTECTED] wrote: (I'm not sure if extension development belongs on this list, but I couldn't find a better one. If there is a more appropriate list, could someone please point me to it?) -- --- Jeremy Johnstone http://www.jeremyjohnstone.com [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why does PHP accept [new] session ids from client?
On Thu, 31 Mar 2005 12:13:22 -0500, Chris Shiflett [EMAIL PROTECTED] wrote: The behavior of the session extension has everything to do with internals. I'm not sure why everyone is sending him to php-general. No one there is going to be able to change this behavior. They can only suggest userland code to try to work around it. IMHO, based on what I had read of his email and even upon rereading it now, he asked why is it this way and is it possible to disable this behaviour?, both of which are not strictly internals related questions (although the first could partially be construed that way). He was not asking for the internals team to change this behaviour (which of course most of the people on generals would have no ability to do) so in that case, his question was best asked there, not here (again IMHO). -- --- Jeremy Johnstone http://www.jeremyjohnstone.com [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why does PHP accept [new] session ids from client?
Not to be rude or anything, but this question is better suited for php-general -Jeremy On Tue, 29 Mar 2005 12:47:29 -0500, Hans L [EMAIL PROTECTED] 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 settings, etc.). As I understand (and experience) it, if a client [browser] presents a session id (e.g. in a cookie) to the server, then PHP will attempt to match that ID to the session on the system. If found, that session information will be made available to the scripts. Fine. But, if *not found* then a new session will be created with the specified ID. Is there any way to disable this behavior? I can't think of a single circumstance under which this would be the desired behavior, but my use of sessions has been more limited to authentication web applications. I know about using session_regenerate_id() after authentication, to prevent fixation, but it seems like this is a workaround for a more fundamental problem in PHP session behavior. On a side note, does anyone know if Hardened-PHP exhibits the same behavior? Thanks, Hans -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- --- Jeremy Johnstone http://www.jeremyjohnstone.com [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
You have to admit one thing about Terje, he does have a knack for irrating virtually every single big wig on the PHP core development team. I haven't kept a close record, but I think I have seen almost everyone of importance comment negatively on his suggestion and/or about him personally because of his persistence to beat a dead horse. =) -Jeremy On Tue, 08 Feb 2005 20:44:49 +0100, M. Sokolewicz [EMAIL PROTECTED] wrote: Ok, this is getting plain annoying. Please stop this endless chatter, all of you! It's annoying, senseless, and counter-productive. If you *really* want to keep bitching at eachother, then please do it somewhere else (iow, not on the list). Andrei Zmievski wrote: Terje, Yeah, follow it up with an insult; that'll do lovely. If you had some insight into human nature, you'd know that humour is very subjective, and given the feedback I've got from others in this thread (which have _not_ been jokes), it's rather hard to see what's a joke and what's not. Perhaps you should examine your own insight into human nature. You have been arguing endlessly about a feature that is questionable, if not completely unnecessary in PHP, and given the number and the nature of replies you received from many PHP developers, you would have been better off giving it up or finding another approach. However, you persist and view your own opinions as the only valid ones. Let me explain: Although I understood that the literal thing you wrote above was of course a joke, my question was meant to see whether there was a serious side to the joke, as well. In other words, if people reacted negatively to this (and, judging from other reactions, it seems so, or at least, they concentrated on the code, rather than my point illustrated with it). If you know it was a joke, you should have taken it as one. I've been known to have a good sense of humour. However, I'm also sensitive, so when I don't know if something is meant as a joke or not, I don't find it amusing. Apparently, this was something you didn't understand, at all, and instead insult me about something you know _nothing_ about. Is that C++ or your sense of humor? What have I done to you, to get an insult from you? How would you feel it if someone else said this to you? A friggin' immature thing to say. Enough of this. - Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- --- Jeremy Johnstone http://www.jeremyjohnstone.com [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Major isssue with foreach() in PHP 4.3.10
Found other bug report indicating this is a Zend Optimizer issue. IMHO, an announcement should be made on the homepage indicating if you upgrade to PHP 4.3.10 you should also make sure you upgrade Zend Optimizer. On Thu, 16 Dec 2004 13:53:39 -0600, Jeremy Johnstone [EMAIL PROTECTED] wrote: http://bugs.php.net/bug.php?id=31134 This is breaking a large number of scripts. -- --- Jeremy Johnstone http://www.jeremyjohnstone.com [EMAIL PROTECTED] -- --- Jeremy Johnstone http://www.jeremyjohnstone.com [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Compiling extensions
Forgive me if this sounds like a newbie type question, but hopefully someone has some advice for me. I am wanting to distribute an extension I wrote for PHP and was wondering what the best way to compile it for all platforms would be. I am completely comfortable compiling the extension under Linux for all versions of PHP, but looking for the best way to compile for *BSD, Solaris, OSX, and Windows. Is there a way to do this easily or am I forced to setup a machine with each platform and compile from it? I thought there was another way, but not sure, so I thought I would ask. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compiling extensions
I have proposed it to PECL a while back (like June I think), not sure on the status of the proposal though. Because of the nature of why I am using this extension, I need to precompile it for as many platforms as possible and use it as a dynamically loaded module (it's basically a script licensing system). I know this isn't the most idea solution, but for my needs it is basically the only one available which works the way I want. -Jeremy http://www.jeremyjohnstone.com P.S. - (off-topic reply) You must know me then I guess. I have everything but OSX available in my server rack in my house, so yes I could do it that way. Was just hoping for an easier solution. Guess I might just have to cave in and buy me an Apple if there is no other way. On Tue, 12 Oct 2004 16:26:25 -0400, Paul G [EMAIL PROTECTED] wrote: well, normally this would be done with autoconf (if you have code that isn't directly portable), assuming you are distributing it as source. however, to test you would need access to said platforms. have you proposed your extension to pecl? pecl-l would probably be a better place to ask and i would think folks there would be glad to help with testing on the platforms you don't have available. off-topic: you mean you don't have all those in that rack of yours? g paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the Zend Studio performance issue
Just to note, although prior versions of ZS were very slow (especially in Win32), that doesn't mean the current version is (that review you linked was reviewing a year+ old version). I recently upgraded to the latest edition (3.5.1) and can say the speed has improved immensely where there is no noticeable delay anywhere in the program. I haven't tested it much on Win32 (I use Linux by choice), but it even seems to be much faster there as well. I would check it out if I were you. -Jeremy On Sunday 08 August 2004 05:16 pm, Ron Korving wrote: ok, i guess this is where my newbieness comes in.. i'm sorry, ignore this whole post :) ron Wez Furlong [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Err, we didn't write it, try talking to Zend... --Wez. On Sun, 8 Aug 2004 20:55:00 +0200, Ron Korving [EMAIL PROTECTED] wrote: hi guys, if you read the reviews on this page: http://www.php-editors.com/review/?editor=16 , you will notice that a lot of people don't use zend studio for the simple reason that it's lacking in performance... this includes myself. i would really love to use it because of all the features, but when i use the gui, i want the program to respond instantly, which it doesn't do... it's easy to blame java for this, but on the other hand, a program such as azureus ( http://azureus.sourceforge.net ) seems to perform better... to me, performance is the only (yet fatal) reason i don't use zend studio... i kinda get the idea you're missing out on sales because of this issue.. i hope you can somehow resolve this all some day.. ron -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
Personally I would never use it myself, as I know of better ways around it which make more sense to me. But on the other hand if it would help others then more power to yah. I think the argument of user's abusing it is bogus, as clearly mentioned in this thread. There isn't a WTF factor, as almost everyone knows what goto does. So frankly it boils down to this. a.) If it can be added without affecting anything I do then great, do it. b.) If your in the camp who is against using it (like me) then don't, but don't tell others what they can and can't use. c.) Newbies will be newbies no matter how much you hand hold them, so just let them be newbies and hope they grow out of it sooner than later. Just my 2c... -Jeremy On Wednesday 28 July 2004 09:12 pm, Sara Golemon wrote: I wrote up a patch for implementing gotos in php scripts a couple months ago as an exercise in working with the Zend engine. I put it aside assuming noone would actually want it, but Wez and Ilia convinced me to post it for consideration: Description: http://pecl.org Patch: http://pecl.org/patches/opcode_goto_5.1.0.diff Talk amongst yourselves... -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Spammer on Bugs page
On Tuesday 20 July 2004 04:46 pm, Jacques Marneweck wrote: Hi Daniel, Take a look over @ Colin Viebrock's Blog and see how his turing test works (http://www.viebrock.ca/code/11/email-protection) and I posted to you earlier how to do sound turing links. I was gonna hack a quick image generation script together, but the URL you gave seems to work fine already. The links directly to the relevant code are: http://www.viebrock.ca/downloads/turing-image.phps http://www.viebrock.ca/downloads/turing.phps The description can be found here: http://www.viebrock.ca/code/10/turing-protection And the example demo can be found here: http://www.viebrock.ca/downloads/turing-test.php -Jeremy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The open letter to Derick Rethans derick@php.net
On Friday 18 June 2004 02:04 pm, Andi Gutmans wrote: That said, I think it'd be great if there'd be people willing to pitch in and work on trying to get it to work. Well if it's help which is needed, then I volunteer myself for anything that needs to be done to make it happen. -- Jeremy Johnstone http://www.jeremyjohnstone.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] question on function declarations
Nope, this isn't the correct place. Try [EMAIL PROTECTED] -Jeremy On Saturday 29 May 2004 04:47 pm, ahti wrote: hello! i really don't know if this is the right place to post this kind of question, but it seems to be quite close. why can't i use C-like variable conversions in php's function declaration, eg. function myfunction($var1, (int)$var2, (bool)$var3=0) ? - ITV - Sinu lemmiksaated internetis! http://www.itv.ee -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] abuse-proof zif_mail()
I have no say or pull around here, but I am +1 on the idea, but unsure on the
implementation from below.
-Jeremy
On Sunday 30 May 2004 08:49 am, Paul G wrote:
folks,
first post/patch, please be gentle g.
hosting companies using mod_php have a *very* hard time preventing and
tracking abuse of mail(). when sendmail is invoked from a suexeced cgi
script, we get the username. with mod_php mail(), we get a big fat nothing,
a ton of spam in the spool and a bunch of abuse reports from ticked off
victims. we then go on a grepping witchhunt, which is hardly a workable
option on a busy production box.
the patch i am including below apends an X-AntiAbusePHP:
/path/to/script/which/is/spewing header to all messages sent through
mail(). while we will be actively parsing that header in our sendmail
replacement script, leaving the username only and throttling/limiting based
on per-user sending threshholds, those who do not go that far to be good
netizens will at least be able to identify the source of spewage post
mortem.
we already have iptables ACLs in place to prevent unauthorized connections
to remotehost:25, but most people can not implement that, so the socket
calls may be my next mutilation target. with that said, it would be much
more intrusive (hence likely unsuitable for addition into the core) and i
thought it would be more prudent to test the waters with a trivial patch,
since i am likely to have done something wrong/contrary to the php way of
doing things.
i would think this {sh,c}ould be ifdefined, but being unfamiliar with the
status quo policy on that and considering that the patch has a fair chance
of being unwelcome, i did not pursue it.
cheers,
paul
diff -ru php-4.3.6/ext/standard/mail.c php-4.3.6.abuse1/ext/standard/mail.c
--- php-4.3.6/ext/standard/mail.c 2004-01-08 20:35:58.0 -0500
+++ php-4.3.6.abuse1/ext/standard/mail.c2004-05-30
08:27:55.0 -0400
@@ -87,6 +87,8 @@
int to_len, message_len, headers_len;
int subject_len, extra_cmd_len, i;
char *to_r, *subject_r;
+ char *exec_file=NULL;
+ int abuseh_len=0, got_headers=0;
if (PG(safe_mode) (ZEND_NUM_ARGS() == 5)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, SAFE MODE
Restriction in effect. The fifth parameter is disabled in SAFE MODE.);
@@ -103,6 +105,18 @@
return;
}
+ got_headers = headers ? 1 : 0;
+ exec_file= zend_get_executed_filename(TSRMLS_C);
+ /* add 2 [strlen(\r\n)] _if_ we are appending to preexisting
headers */
+ abuseh_len = (got_headers*2) + strlen(ABUSE_HEADER_TAG) +
strlen(ABUSE_HEADER_SRC) + strlen(exec_file);
+ headers = got_headers ? erealloc(headers, headers_len + abuseh_len
+ 1) : emalloc(abuseh_len + 1);
+ if(got_headers) strcat(headers, \r\n);
+ strcat(headers, ABUSE_HEADER_TAG);
+ strcat(headers, ABUSE_HEADER_SRC);
+ strcat(headers, exec_file);
+ headers_len += abuseh_len;
+
+
if (to_len 0) {
to_r = estrndup(to, to_len);
for (; to_len; to_len--) {
diff -ru php-4.3.6/ext/standard/php_mail.h
php-4.3.6.abuse1/ext/standard/php_mail.h
--- php-4.3.6/ext/standard/php_mail.h 2002-12-31 11:35:33.0 -0500
+++ php-4.3.6.abuse1/ext/standard/php_mail.h2004-05-30
08:26:59.0 -0400
@@ -24,6 +24,9 @@
PHP_FUNCTION(mail);
PHP_MINFO_FUNCTION(mail);
+#define ABUSE_HEADER_TAGX-AntiAbusePHP: Added to track PHP abuse,
please include with any abuse report\r\n
+#define ABUSE_HEADER_SRCX-AntiAbusePHP: This message was sent
through
+
#if HAVE_SENDMAIL
PHP_FUNCTION(ezmlm_hash);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] email change
http://master.php.net/manage/users.php On Sunday 11 April 2004 11:49 am, Sergey Kartashoff wrote: Hi! I have an PHP CVS account 'gluke' which is binged to email gluke @ php.net. This email forwards all email at gluke @ sky.net.ua. Please tell me how can i change a forward destination ? I mean change gluke @ sky.net.ua to something else ? -- Regards, Sergey aka gluke. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
FYI, if you put the word premier in front of the URL, you will get much faster download speeds. Anytime you see a URL with download.microsoft.com you can almost always change it to premierdownload.microsoft.com and get much faster speeds. -Jeremy On Tue, 2003-12-16 at 22:40, Daniel Convissor wrote: Hi Folks: FINALLY heard back from Microsoft... On Tue, Dec 02, 2003 at 08:19:56PM -0500, Daniel Convissor wrote: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm which looks pretty promising since it's titled Full Download with Local Install. Alas, no links to actually get the file. Here are the links: http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.1.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.2.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.3.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.4.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.5.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.6.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.7.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.8.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.9.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.10.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.11.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.12.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.13.cab http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.bat http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/Extract.exe Download them all then run PSDK-FULL.bat dir to extract files to That will extract the files. Then you need to go to that dir and run setup.exe. Enjoy, --Dan -- FREE scripts that make web and database programming easier http://www.analysisandsolutions.com/software/ T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 RC 1 - Article/Tutorial Sponsorship Opportunity
I don't think you were, but in any case please don't think I was putting down Zend at all when I said that. Zend does infinite things for the PHP community. I was mearly saying that we would be willing to help share that part of the responsibility (sponsoring articles/tutorials). Jeremy On Thu, 2003-11-13 at 00:37, Andi Gutmans wrote: Hey, I think you misunderstood me. I didn't mean I wasn't keen on the idea. We are constantly paying people to write articles. I just meant that I think it's wrong if no one documents here because they'll say companies like Zend will finance it. There are things beyond articles which need to be written such as the PHP manual, release notes, NEWS and so on. And of course the critical mass one company can provide is smaller than a whole community. Then again it's great if your company sponsors articles and as I said, we're constantly doing the same. Andi At 08:51 PM 11/12/2003 -0600, Jeremy Johnstone wrote: I saw a mention of someone inquiring if Zend would sponsor the writing of articles / tutorials on PHP5, and that it appeared Andi wasn't too keen on the idea. I went to my boss and found that my employer would be interested in possibly sponsoring articles to be written on the new features and benefits of PHP5. We own a large network of web development and web hosting related sites (hotscripts.com / webhostingtalk.com / devpapers.com / programmingtalk.com / dbforums.com / etc.) If your interested in this, please contact us for more information. Please reply to: [EMAIL PROTECTED] Jeremy Johnstone Lead Developer iNET Interactive http://www.inetinteractive.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 RC 1 - Article/Tutorial Sponsorship Opportunity
We are completely open in this area. We want to get as much as possible in as many areas as possible, to be honest. You might take a quick look at devpapers.com to see the format of where we would be mostly using the articles/tutorials. Jeremy On Thu, 2003-11-13 at 16:32, Kevin Waterson wrote: This one time, at band camp, Andi Gutmans [EMAIL PROTECTED] wrote: There are things beyond articles which need to be written such as the PHP manual, release notes, NEWS and so on. Ok, what do you need/want written? Kevin -- __ (_ \ _) ) | / / _ ) / _ | / ___) / _ ) | | ( (/ / ( ( | |( (___ ( (/ / |_| \) \_||_| \) \) Kevin Waterson Port Macquarie, Australia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 RC 1 - Article/Tutorial Sponsorship Opportunity
I saw a mention of someone inquiring if Zend would sponsor the writing of articles / tutorials on PHP5, and that it appeared Andi wasn't too keen on the idea. I went to my boss and found that my employer would be interested in possibly sponsoring articles to be written on the new features and benefits of PHP5. We own a large network of web development and web hosting related sites (hotscripts.com / webhostingtalk.com / devpapers.com / programmingtalk.com / dbforums.com / etc.) If your interested in this, please contact us for more information. Please reply to: [EMAIL PROTECTED] Jeremy Johnstone Lead Developer iNET Interactive http://www.inetinteractive.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: AW: [PHP-DEV] PHP 5 RC1
Forgive me for the shameless plug, but since I work for the company who owns the site I couldn't help but throw in you can always post the new articles about PHP5 here: www.devpapers.com Jeremy On Wed, 2003-11-12 at 06:15, Kevin Waterson wrote: This one time, at band camp, Wolfgang Drews [EMAIL PROTECTED] wrote: *This message was transferred with a trial version of CommuniGate(tm) Pro* I agree. I think we need to take care of this. I wouldn't count on any one company for this (although this is also important). How about the people from internals@ who made changes volunteer to write about their changes? nice idea, but you and i both know how lazy people get, when they have to write docs or articles instead of producing awesome code ;). I really would like to see Zend doing such a campaign, not because i think you are responsible to do so, but because it should be/is worth the money for your company (roi). Writing docs and articles is time consuming and difficult for developers to fit in php development along with a job to get some money to eat. Is there a list of the major changes? eg libxml2 domxml new OO goodness sqlite bundled more?? I will get something started if you like, the weight of having each of the developers do something on top of the standard docs would be a little excessive. But I agree it would be nice to have a 'What to expect from PHP5' article out there. Or perhaps a series of of articles on the most important features? Just my $0.02 Kevin -- __ (_ \ _) ) | / / _ ) / _ | / ___) / _ ) | | ( (/ / ( ( | |( (___ ( (/ / |_| \) \_||_| \) \) Kevin Waterson Port Macquarie, Australia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] $_SESSION questions
I have recently found that if I don't register a session using PHP's
session management code I can use the $_SESSION variable as my own
superglobal which I can use for whatever purpose I deam fit. Here is a
small code snippet to illustrate:
$_SESSION = new my_custom_session_obj();
function test_session() {
print($_SESSION-loginvars[username]);
}
test_session();
Works fine. Of course there is no autosaving of the session as PHP
normally does, but this is fine as I already have code to do this. My
question is this a bug or a feature. I don't want to use this code
if it is not an officially supported usage as it would obviously not be
very backwards compatible and also not useable in new versions of PHP.
If anyone can tell me approximately when this started to work (have
tested in several 4.3.x builds already) and if it's expected to work in
the future I would greatly appreciate it.
Jeremy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Overriding $DOCUMENT_ROOT in an Apache Module
Care sharing what you did to fix it? On or offlist is fine. Jeremy On Thu, 2003-09-25 at 10:22, Mark Morley wrote: Then your not setting it correctly via your apache module. Actually I am setting it correctly, but as you say... FYI - If you using apache 1.3.x you CANNOT reset document root. DOCUMENT_ROOT is set at a low level of initial child request startup. Your third party module isnt at a low enough level to do this. ..Apache replaces certain variables later on in the processing chain, including DOCUMENT_ROOT. I found a way to avoid this though, and now my module is working the way I want and I am able to specify the DOCUMENT_ROOT dynamically. Thanks for the replies though, they helped track it down. Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Looking for comments whether this is a bug or not
I am not sure if this is a bug, but I have came across two test cases
where the behavior is not as expected so I thought I would ask.
The problem I am having seems to be with addslashes not properly
escaping this type of string C:\test\foo.exe. Here is the scenario:
$email-body = This is a test email. Testing c:\test\foo.exe;
When the $email object is later broke down and stored in the database
addslashes is done (as it should be) before the variable is stored.
If you check the database though, no slashes were added to the string.
The only way I can seem to get it to work as I thought it should, is to
do the following:
addslashes(str_replace(\\, , $body))
Then when you check the database you see the proper This is a test
email. Testing c:\\test\\foo.exe.
The other example I have is with an object which looks similar to:
class login_handler
{
var last_ticket_subject;
// ... (code truncated)
}
If I set the class's last_ticket_subject to This is a test
c:\test\foo.com later in the code, then do the following:
addslashes(serialize($login_handler))
and check the database, once again it didn't add any slashes. The only
way I can get it to add the slashes as I think it should, is to do the
following:
addslashes(str_replace(\\, , serialize($login_handler)))
I am doing something wrong (or did I misunderstand something) or is this
in fact a bug? I have tested it on PHP 4.2, 4.3.2, and 4.3.3 and the
behavior is exactly the same. If it isn't a bug, can someone clarify for
me why addslashes would be designed this way?
Jeremy Johnstone
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Looking for comments whether this is a bug or not
The actual value of those variables are pulled in from other sources,
they are not actually hard coded like I showed below. It was simply for
illustration purposes.
Jeremy
On Sat, 2003-08-30 at 15:56, Ken Tossell wrote:
Your string assignments look wrong. For example, \t is a tab
character. Try your test cases with 'This is a test email. Testing
c:\test\foo.exe'; that should give you a proper string.
Ken
Jeremy Johnstone wrote:
I am not sure if this is a bug, but I have came across two test cases
where the behavior is not as expected so I thought I would ask.
The problem I am having seems to be with addslashes not properly
escaping this type of string C:\test\foo.exe. Here is the scenario:
$email-body = This is a test email. Testing c:\test\foo.exe;
When the $email object is later broke down and stored in the database
addslashes is done (as it should be) before the variable is stored.
If you check the database though, no slashes were added to the string.
The only way I can seem to get it to work as I thought it should, is to
do the following:
addslashes(str_replace(\\, , $body))
Then when you check the database you see the proper This is a test
email. Testing c:\\test\\foo.exe.
The other example I have is with an object which looks similar to:
class login_handler
{
var last_ticket_subject;
// ... (code truncated)
}
If I set the class's last_ticket_subject to This is a test
c:\test\foo.com later in the code, then do the following:
addslashes(serialize($login_handler))
and check the database, once again it didn't add any slashes. The only
way I can get it to add the slashes as I think it should, is to do the
following:
addslashes(str_replace(\\, , serialize($login_handler)))
I am doing something wrong (or did I misunderstand something) or is this
in fact a bug? I have tested it on PHP 4.2, 4.3.2, and 4.3.3 and the
behavior is exactly the same. If it isn't a bug, can someone clarify for
me why addslashes would be designed this way?
Jeremy Johnstone
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP compiler
After seeing the conversation on the PHP archive idea (having a PHP equivalent of a jar file), it reminded me of an idea I had a long time ago. Has anyone ever thought of writing a PHP compiler which would compile a PHP script into native machine code? If you have thought of it, what stopped you from building it? I would be highly interested in joining a team which wanted to push the limits of PHP by doing something like this. I think this is the next logical step in the PHP for anything and everything goal. Jeremy
RE: Re[4]: [PHP-DEV] PHP compiler
PS: I am one of the last people you should be complaining at about php isn't intended for that; perhaps you should study your PHP history before you make your next post. That is why I apologized if I came off rude. I snapped back without realizing who had actually made the post I was responding to. Jeremy -Original Message- From: Wez Furlong [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 11:11 AM To: Jeremy S. Johnstone Cc: [EMAIL PROTECTED] Subject: Re: Re[4]: [PHP-DEV] PHP compiler Damn, and I was just about to respond suggesting that you cancel your cvs account too ;-) It's easy to think that PHP can and should be applied to everything that you might want to do, ranging from your web pages to managing the power on your ACPI laptop and so on, but you do need to keep sight of the fact that PHP was designed for The Web Problem, and that The Web Problem will always be the primary focus of PHP. Anything that *really* doesn't fit with that just isn't going to get into the core. However, quite often, you can extend or otherwise modify PHP to suit your own needs - it is OpenSource after all. --Wez. - Original Message - From: Jeremy S. Johnstone [EMAIL PROTECTED] To: 'Wez Furlong' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 4:54 PM Subject: RE: Re[4]: [PHP-DEV] PHP compiler I apologize if I sounded rude at all, it's just that I am sick of people telling me php isn't intended for that, when I come up with new ideas. I ask those same people what they think PHP is for, and inevitably I get some variation on LAMP. If PHP is only intended to ever be a web programming language and has no plans of branching out in the future, I think PHP is grossly limiting itself. Jeremy -Original Message- From: Jeremy S. Johnstone [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 10:42 AM To: 'Wez Furlong' Subject: RE: Re[4]: [PHP-DEV] PHP compiler Okay, so you want to arbitrarily limit PHP's use to simple web applications? With attitudes like this, maybe I should just cancel my CVS account at php.net and go join a Microsoft ASP team somewhere. If myself and other person who started the Java-alike thread want to discuss PHP having internal support for features such as this, I think we are well entitled to. Of course that doesn't mean the core programmers have to head our desires and actually allow it to be included, but it doesn't stop us from discussing the merits of such a solution. Jeremy -Original Message- From: Wez Furlong [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 10:30 AM To: Simeon Koptelov; [EMAIL PROTECTED] Subject: Re: Re[4]: [PHP-DEV] PHP compiler This isn't really an internals matter, and isn't going to happen in the core (for various reasons). It is something you can implement yourself using your own extension and the streams API. Can we please drop this thread (and related Java-alike threads) now and replace them with more technical issues actually related to the internals of PHP ? :-) --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: Re[2]: [PHP-DEV] PHP compiler
The only problem with that approach is that you have to distribute the php executable and your program is loaded using a command line similar to: Php -par someapp.par Instead of simply: ./someapp I know this is a small difference, but it makes a big difference when you are dealing with customers who are, how should I say this, not as computer savy as they should be. Jeremy -Original Message- From: Simeon Koptelov [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 10:37 AM To: [EMAIL PROTECTED] Subject: Re[2]: [PHP-DEV] PHP compiler Hello Jeremy, Wednesday, August 6, 2003, 8:16:49 PM, you wrote: JSJ No that is not what I meant. What I meant is so when you write an JSJ application using PHP-GTK you could distribute a single executable JSJ instead of the current method. Personally the current method JSJ doesn't bother me, but to a laymen user it is not what they are JSJ used to and causes issues. I am not looking for a speed improvement JSJ really, just a useability improvement for those who choose PHP is JSJ equally as suited to desktop applications as it is to web JSJ applications. JSJ Jeremy Then the jar-like archives is all that we really need :) And in web apps this will be very handy too. There's no need in PHP code compilation in this case -- you simply pack all package files and dirs in one archive using tar+bz2 or zip or something else. -- Best regards, Simeonmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Proposal] Idea for Application level variables
I noticed something which you said, and forgive me if this part may be
obvious, but you mentioned across instances of applications? Do you mean
something like a shared memory between all web connections to the
server? One issue I could forsee if this is the case, what happens when
there is no connections to the server for an extended period of time
(extended being even as short as a few minutes)? Should PHP store this
superglobal's value indefinitely, or perform some type of garbage
collection? If PHP should clean up after itself, what criteria would you
expect to be followed for deciding if something is no longer useful? I
don't think you would want this criteria configurable in a ini setting
for example, because hosting companies all do something different. If a
developer were to use this feature, they would need a standardized
timeframe that the values would last. This is just a couple things I
think would need to be considered before implementing something like
this. If I am way out in left field, I apologize.
-Jeremy
-Original Message-
From: Davey [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 07, 2003 8:15 AM
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] [Proposal] Idea for Application level variables
Andrey,
// masv = my application shared vars. This is the name of the shared
var. // Only the first 4 chars are used to calculate memory address.
$_APPLICATION = new Shm_Protected_Var(masv, 1024 /*memory*/);
$_APPLICATION-start_section() var_dump($_APPLICATION-getVal());
$_APPLICATION-end_section();
This isn't quite as transparent as $_SESSION is and $_APPLICATION would
also not be a superglobal. What I would like to see at the end of this
is a $_APPLICATION variable (or $_APP? some poeple complained that
$_APPLICATION is too long) that behaves *exactly* like $_SESSION (in
assignment etc) except that its values are available not across
sessions but across applications and instances of applications.
- Davey
Andrey Hristov wrote:
Hi Davey,
I don't know whether this will be implemented in an extension but
there are sollutions in userland : to use sysvshm+sysvsem or shmop.
The sysvshm+sysvsem extension exposes the C api. I know for 2 wrappers
around this API to make the use of shared memory (and thus something
like application wide variables) easy to implement in userspace:
1)
http://www.php-tools.de/site.php?PHPSESSID=b4a4ab7142b7d3209c7eee976912
0cba
file=patMisc/shmc.xml
2)http://www.hristov.com/andrey/projects/php_stuff/shm.php.gz
The second one is written according to PEAR CS. It exposes 4 classes.
Shm_Protected_Var is what is needed to implement $_APPLICATION:
// masv = my application shared vars. This is the name of the shared
var. // Only the first 4 chars are used to calculate memory address.
$_APPLICATION = new Shm_Protected_Var(masv, 1024 /*memory*/);
$_APPLICATION-start_section() var_dump($_APPLICATION-getVal());
$_APPLICATION-end_section();
Regards,
Andrey
- Original Message -
From: Davey [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, August 07, 2003 3:36 PM
Subject: [PHP-DEV] [Proposal] Idea for Application level variables
Hey,
I'm quite new to this, so please don't shoot this down too harshly. If
I don't explain something clearly enough, please ask me.
Because Application variables are pretty much shared session
variables, I wonder if perhaps the session code can be modified to
handle these variables.
In userland, the implementation would be similar to sessions, and can
work on two levels, for a single file or for a group of files.
Userland usage examples:
// cross file (i.e. an entire website)
application_vars_start('my_website'); // my_website is used as the SID
$_APPLICATION['website_users'] += 1;
// single file
application_vars_start(); // uses filename based SID, see below
$_APPLICATION['page_users'] += 1;
I figured that by using the following in place of the user-input SID,
you can easily have page-wide application vars, and by using the arg
for
application_var_start() in the the place of
SG(request_info).path_translated you can have it across whatever you
like, problem is when you have multiple sites on the same server,
someone else might choose the same name
PHP_MD5_CTX context;
PHP_MD5Init(context);
PHP_MD5Update(context, SG(request_info).path_translated,
strlen(SG(request_info).path_translated));
PHP_MD5Final(key, context);
I don't know if this is clear enough, but in my head at least, it
seems a inexpensive solution to something PHP is (in some peoples
opinion) lacking. (Note: SRM seems like overkill just for this).
Another nice thing about this, as it'll be using the Session
infrastructure it could use the session handlers aswell (sqlite, mm
etc)
one problem that has been mentioned is multi-threaded situations, but
I would assume that either the current session code doesn't suffer
from this (and therefore neither will this) or that the session code
will need
RE: Re[4]: [PHP-DEV] PHP compiler
I apologize if I sounded rude at all, it's just that I am sick of people telling me php isn't intended for that, when I come up with new ideas. I ask those same people what they think PHP is for, and inevitably I get some variation on LAMP. If PHP is only intended to ever be a web programming language and has no plans of branching out in the future, I think PHP is grossly limiting itself. Jeremy -Original Message- From: Jeremy S. Johnstone [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 10:42 AM To: 'Wez Furlong' Subject: RE: Re[4]: [PHP-DEV] PHP compiler Okay, so you want to arbitrarily limit PHP's use to simple web applications? With attitudes like this, maybe I should just cancel my CVS account at php.net and go join a Microsoft ASP team somewhere. If myself and other person who started the Java-alike thread want to discuss PHP having internal support for features such as this, I think we are well entitled to. Of course that doesn't mean the core programmers have to head our desires and actually allow it to be included, but it doesn't stop us from discussing the merits of such a solution. Jeremy -Original Message- From: Wez Furlong [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 10:30 AM To: Simeon Koptelov; [EMAIL PROTECTED] Subject: Re: Re[4]: [PHP-DEV] PHP compiler This isn't really an internals matter, and isn't going to happen in the core (for various reasons). It is something you can implement yourself using your own extension and the streams API. Can we please drop this thread (and related Java-alike threads) now and replace them with more technical issues actually related to the internals of PHP ? :-) --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] user contributed notes
I have been doing cleanups of the SNMP area over the past couple days. I am planning on bringing the documentation fully up to date with the source code. I also cleaned up some of the notes which had broken links or violated note policies. In regards to user notes, I am simply following the guidelines outlined in http://www.php.net/manual/howto/chapter-user-notes.html. -Jeremy -Original Message- From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED] Sent: Monday, July 14, 2003 3:08 PM To: [EMAIL PROTECTED] Cc: Harrie Hazewinkel Subject: [PHP-DEV] user contributed notes Hi, Could someone explain what the purpose is of 'User Contributed Notes. I noticed some notes as part of snmpget.php which are not notes, but questions for help. http://www.php.net/manual/en/function.snmpget.php Not sure what to do with them, and if I can delete the questions?? regards, Harrie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] xml_set_element_handler and xml_parse
I am running into a strange problem which goes in direct opposition to what is said in the documentation. I need to know what is the correct behaviour before I update the documentation. Problem is this: With the function xml_set_element_handler, if you don't set an actual end element handler (you set it to or FALSE) the function xml_parse will return the following error: Xml_parse(): Unable to call handler () in /path/to/script on line ## The documentation explicitely states that If a handler function is set to an empty string, or FALSE, the handler in question is disabled. If I create a dummy function which actually does absolutely nothing and put it's name as the end element handler I do not get the above error message. Am I doing something wrong, is this a bug, or should I update the documentation for this function? PHP version: 4.3.2 XML expat version: 1.95.4 ,,, (Ô Ô) ===oOO==(_)==Ooo=== Jeremy Johnstone [EMAIL PROTECTED] .oooO Oooo. ==( )=( )== \ ( ) / \_) (_/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
