Re: [PHP-DEV] make new return a reference to existent object
Hello, -1 New implies "new". Use a factory. Maybe we should add an old construct: $object = old MyClass(); Just kidding :) -- Best regards, Jasonmailto:[EMAIL PROTECTED] Monday, May 9, 2005, 10:30:56 AM, you wrote: LP> I would like (for code cleanliness purposes) to make 'new' return a reference LP> to an already created object under certain circumstances without using a LP> factory, is it possible? LP> Thanx -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Hello Andi, I have to strongly disagree with your ifsetor() comment. the use for ifsetor is in no way eliminated with filtering. I write very clean code and have taught all my developers to write very clean code. We run the latest stable PHP version with maximum error reporting. We do this so we can have more secure code with fewer logic errors. However, running in E_STRICT makes life rather miserable for simple things such as accessing any array key that may or may not have been included. I'm finding myself having the need for the ifsetor() construct in all areas of programming - not just in _POST or _GET. Even though you don't see yourself using it much, there are many developers on this list who DO see the use for it, and there are countless developers off this list who don't even know about it, but would find it useful for migrating to E_ALL | E_STRICT error reporting. If there was any way to accommodate this with userland PHP code, I would have already done it. However it is an engine level function that has to be added to the core of PHP. +ALot Thanks. -- Best regards, Jasonmailto:[EMAIL PROTECTED] Sunday, June 5, 2005, 3:13:52 PM, you wrote: >>4) I still want the ifsetor operator since it is very helpfull and again >>simplifies a lot of things. AG> I don't think ifsetor() shortcut is a big deal nor needed in PHP. I've said AG> it numerous times. Once we have a filtering API there will be even less AG> times where it will be applicable. Write an extra 10 characters or so... AG> Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Hello Sean, I should have clarified this -- The following is how I do it all the time. It's just a bit longhanded for something that is done so often. $email = (isset($_GET['email']) ? $_GET['email'] : ''); It get's even messier when you want to get something like this: $value = (integer) (isset($myBigArray['SomeKey1']['SomeOtherKey']) ? $myBigArray['SomeKey1']['SomeOtherKey'] : 0); where $value = ifsetor($myBigArray['SomeKey1']['SomeOtherKey'], 0); is a bit cleaner. Thanks. -- Best regards, Jason mailto:[EMAIL PROTECTED] Monday, June 6, 2005, 1:22:11 PM, you wrote: SC> Jason Garber wrote: >> If there was any way to accommodate this with userland PHP code, I >> would have already done it. However it is an engine level function >> that has to be added to the core of PHP. SC> For the record, I also find ifsetor useful, but what you want can be SC> accomplished like this: SC> $email = isset($_GET['email']) ? $_GET['email'] : 'no email address'; SC> ifsetor would make this much nicer, but there /is/ a way to accomplish SC> what you want in userland. SC> S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Hello, I don't know if chiming in at this point has any merit, but here is what I see. We have many, many people in favor of goto and ifsetor. They see much legit use for those constructs. Then, we have others who say that it will result in spaghetti code. This is a completely invalid point because we have all seen spaghetti code in PHP already. Spaghetti code comes from an inexperienced or sloppy developer, not from cool language features. When considering what language to use in my company, I looked at the community and open-development that surrounds PHP. These are some of the reasons that I chose PHP. I am still very happy at that choice. The biggest thing that I see working against PHP is individuals who say "I don't see myself using , so you should not be ALLOWED to use ." That being said, we need carefully evaluate the plusses and minuses of adding a feature: Is it's use clear? Does it reduce the speed of PHP? Does it open bizarre security holes? Is it useful by a reasonable percentage of developers? Does it solve a common problem or annoyance present in PHP? Does it add additional problems or annoyances to PHP? All in all, I think if everyone stops being religious about goto, and logically evaluates it, we can quickly come to a conclusion. -- Best regards, Jasonmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Hello Noah,
In general, the people who advocate writing this construct differently,
are missing the point.
ifsetor is NOT input filtering, it is not a complex, general purpose
do-everything construct, it is a simple replacement for
$x = (isset($ANY_var) ? $ANY_var : 'Default Value');
$x = ifsetor($ANY_var, 'Default Value');
It needs to be fast, and simple.
Using @ is not acceptable, because it still entails a call to the
custom error handler function.
It ought to be able to handle any type.
It will be a much-used, not-needed language construct that will
speed up PHP, produce cleaner code, and encourage the adoption of
E_ALL error reporting.
Thanks.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Monday, June 13, 2005, 8:23:17 PM, you wrote:
NB> Rob,
NB> I agree with you entirely. It's possible to write this code probably
NB> a hundred different ways which, to me, also noting the number of
NB> posts the topic has generated, indicates that it should be supported
NB> in the language. A common convention for a common operation seems
NB> like a sensible goal to me. As nice as it is to be able to roll your
NB> own, code sharing is facilitated when we include de facto behaviors.
NB> The single implementation close to the metal would also help with
NB> speed and code verifiability.
NB> Thanks,
NB> -Noah
NB> On Jun 13, 2005, at 6:33 PM, Robert Cummings wrote:
>> On Mon, 2005-06-13 at 16:23, Ron Korving wrote:
>>
>>> If it were possible at all to make a function accept unset
>>> variables without
>>> generating a notice, I think ifsetor() shouldn't even be
>>> implemented. People
>>> could then have the freedom to create such functions themselves. But
>>> unfortunately, it doesn't seem to be possible, unless you'd
>>> suppress every
>>> function call with a @, which I don't think is the way to go in
>>> this case.
>>>
>>> So if it would be possible somehow to create your own isset()-like
>>> functions
>>> in PHP-code, I'd say implement something that would make that
>>> possible, and
>>> ingore the whole ifsetor() discussion from that moment on. People
>>> would be
>>> free to write whatever function they'd prefer.
>>>
>>
>> Voila!
>>
>> function ifsetordefault( $array, $key, $default=null )
>> {
>> if( isset( $array[$key] ) )
>> {
>> return $array[$key];
>> }
>>
>> return $default;
>> }
>>
>> echo ifsetordefault( array( 1 => 'One', 2 => 'Two' ), 3, 'Three' );
>>
>> Or if you prefer:
>>
>> function ifsetpathordefault( $array, $path, $default=null, $sep='/' )
>> {
>> $pathBits = explode( $sep, $path );
>>
>> $nest = $array;
>> foreach( $pathBits as $pathBit )
>> {
>> if( !isset( $nest[$pathBit] ) )
>> {
>> return $default;
>> }
>>
>> $nest = $nest[$pathBit];
>> }
>>
>> return $nest;
>> }
>>
>> And yet, I'd still prefer an internal function to do this MUCH MUCH
>> MUCH
>> faster and then I'd also never need to run across the problem of
>> naming
>> collisions with other libraries that implement the same code :)
>>
>> Cheers,
>> Rob.
>> --
>> ..
>> | InterJinn Application Framework - http://www.interjinn.com |
>> ::
>> | An application and templating framework for PHP. Boasting |
>> | a powerful, scalable system for accessing system services |
>> | such as forms, properties, sessions, and caches. InterJinn |
>> | also provides an extremely flexible architecture for |
>> | creating re-usable components quickly and easily. |
>> `'
>>
>> --
>> 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] In regards to E_STRICT and PHP5
Hello boots,
if(AppDevLevel == 'Production')
{
error_reporting(E_ALL);
}
else
{
error_reporting(E_ALL | E_STRICT);
}
Why don't you implement something like this in your application -
then you CAN control what error level is used at the client site.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Thursday, June 16, 2005, 3:09:43 PM, you wrote:
b> --- George Schlossnagle <[EMAIL PROTECTED]> wrote:
>> On Jun 16, 2005, at 2:50 PM, boots wrote:
>> > --- Andi Gutmans <[EMAIL PROTECTED]> wrote:
>> >
>> >> You missed the point of E_STRICT. I introduced it as an
>> E_PEDANTIC.
>> >> That was the whole idea. To be pedantic about code that works,
>> not
>> >> to warn about code that doesn't work (which is for higher warning
>> >> levels)
>> >>
>> >
>> > I don't think I missed that, I just don't appreciate it :)
>>
>> If you don't want pedantic checks, don't run with E_STRICT.
b> As a developer, I want to run with E_STRICT, or at least, I want to
b> know what the engine thinks in regards to the correctness of my code.
b> That is not the problem. The problem is that I can't control what
b> customer environments and I don't necessarily want to port perfectly
b> acceptable PHP4 code to avoid warning on their systems. The point is
b> that E_STRICT is meant for developers but is implemented in the general
b> runtime where it impacts more than just developers.
b> Well, you were all kind enough to allow me to have my say so I will
b> leave it in your capable hands now and accept your decisions.
b> Thank-you.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] In regards to E_STRICT and PHP5
Hello Rasmus,
Thanks. I guess I did not realize that because all of my
application logic is included after I set error_reporting()
Thanks for pointing this out.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Thursday, June 16, 2005, 4:32:11 PM, you wrote:
RL> Jason Garber wrote:
>> Hello boots,
>>
>> if(AppDevLevel == 'Production')
>> {
>> error_reporting(E_ALL);
>> }
>> else
>> {
>> error_reporting(E_ALL | E_STRICT);
>> }
>>
>> Why don't you implement something like this in your application -
>> then you CAN control what error level is used at the client site.
RL> Because setting E_SCRIPT at runtime is mostly useless as many of the
RL> E_STRICT checks are compile-time.
RL> -Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP Macros
Hello Internals,
Remember the ifsetor() discussion? There were many, many people for
it, and many people that did not see the point. To this day, it's
not been allowed into the source tree, and I don't see any way to
change that. So...
Please consider (some form of) this if it's possible:
define_macro square(x)
{
((x) * (x))
}
define_macro ifsetor(x, y)
{
(isset(x) ? x : y)
}
$n = square($n);
If the parser/compiler sees one of these, then it will add it to
it's list of "macros", and when it runs into the usage of one, it
will do a little token-replacing before compiling it...
Is it technically doable?
Thanks guys.
--
Best regards,
Jason Garber mailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator ideas
Hello,
I as a userland library author, would appreciate namespaces quite a
bit. Here is an idea:
namespace1..class()
$x = new MyApp..MemberOrder();
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Saturday, November 26, 2005, 3:52:35 PM, you wrote:
GB> Hi all,
GB> I have only one caveat with the \ separator, which is that it is a
GB> little bit too similar to division with /, and can result in some
GB> confusing code like:
GB> namespace name1 {
GB> class name2{}
GB> }
GB> define('name1', 1);
GB> define('name2', 2);
GB> $a = new name1\name2;
GB> $b = name1/name2;
?>>
GB> The same issue exists with all colon based separators (that sounds bad
GB> when read the wrong way...) because of the ternary operator, and :: with
GB> static classes/methods.
GB> namespace name1 {
GB> class name2{}
GB> }
GB> define('name1', 1);
GB> define('name2', 2);
GB> // this may be a parse error with the current namespace patch,
GB> // but need not be if we use ->
GB> class name1
GB> {
GB> const name2 = 1;
GB> }
GB> $a = new name1:::name2;
GB> $b = name1::name2; // do you see the difference? I get confused
?>>
GB> What about using the T_OBJECT_OPERATOR? This is a parse error in
GB> existing versions, and also implies some separation.
GB> namespace name1 {
GB> class name2{}
GB> }
GB> define('name1', 1);
GB> define('name2', 2);
GB> // this may be a parse error with the current namespace patch,
GB> // but need not be if we use ->
GB> class name1
GB> {
GB> const name2 = 1;
GB> }
$a = new name1->>name2;
GB> $b = name1::name2;
?>>
GB> I also proposed on IRC using \\ as this is similar to netware driver
GB> separators:
GB> define('name1', 1);
GB> define('name2', 2);
GB> $a = new name1\\name2;
GB> $b = name1/name2;
?>>
GB> However, I know Andrei hated this :). I very much prefer the use of ->,
GB> as this has the same advantage as :: of "rhyming" with current syntax.
GB> Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Something (was: Re: [PHP-DEV] Re: Labeled Breaks (not the G-word))
Hello Zeev, I would like to point out that PHP has been changing over the last few years from a language that Rasmus used for his online resume to an enterprise grade application development language. I've personally watched it go from PHP3 -> PHP4 -> PHP5, and *much* anticipate the future releases because they empower me and my company to do so many things that were previously not possible or very difficult. OO, for example, aids us greatly in implementing business logic, but I would hate to use it for *everything*. Please don't lose sight of where PHP is going. There are *alot* of experienced programmers who crave more powerful features that they previously emulated or worked around. On the other hand, there are tons of people who still include($_GET['file']) or put untrusted input straight into a database query. Ignorant people will be ignorant. Giving them the truth about these matters is the best way to fight it, not to take away highly useful features from the people who could really use them. From: http://zend.com/company/overview.php "As the meteoric growth of PHP continues, it is clear that it has become a relevant and significant development language. Any corporation building enterprise-grade applications would be wise to consider the open source development platform as a strong competitor to traditional commercial solutions." I personally like MySQL's methodology of adding many features, but not sacrificing speed, stability, or security. Thanks. PS: This whole issue strangely reminds me of http://slashdot.org/articles/04/01/08/0111228.shtml?tid=152&tid=185 -- Best regards, Jasonmailto:[EMAIL PROTECTED] Sunday, November 27, 2005, 3:54:43 PM, you wrote: ZS> At 22:18 27/11/2005, Nicolas Bérard Nault wrote: >>Goto exists in C. If you affirm that goto should >>not exist in PHP because it gives the >>opportunity to screw their code to programmers, >>are you also affirming that C programmers are smarter than PHP programmers ? ZS> I wouldn't make any statement regarding the ZS> intelligence level of C and PHP developers, since ZS> there are plenty of idiots and smart people on ZS> both camps; It has everything to do with ZS> training and experience. And the training and ZS> experience levels of the average PHP developer is ZS> nowhere near that of the average C/C++ developer. ZS> Sorry for repeating it for the 1001st time in the ZS> few years, but PHP did not get to where it is ZS> today because we added everything and the kitchen ZS> sink, that's Perl. I would *really* be great if ZS> people realized that PHP the way it is now is ZS> successful, but it's not inherent to the PHP ZS> project. Not every bunch of features we pack ZS> under the name "PHP" will retain this level of success. ZS> We *can* screw it if we go in the wrong ZS> direction, and adding redundant features which ZS> are useful in rare cases and much more likely to ZS> be abused than to be properly used is a good step ZS> in that direction. A lot of people are saying we ZS> already went too far with PHP 5, and that's ZS> arguable. It's clear, however, that adding more ZS> and more language features and making PHP more ZS> and more complex is not a good recipe. ZS> Zeev ZS> -- ZS> PHP Internals - PHP Runtime Development Mailing List ZS> 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: Basic Namespace Requirements
Hello Sara, Please explain what the difference is between nested classes, and this type of namespacing? If you scrapped namespace constants and functions, then all we have left is classes. If it was looked at as nested classes, then we get all the functionality with all the simplicity and the benefit of being able to use "::". Please take a moment to explain, because I am an avid user, not a tokenizer :) -- Best regards, Jasonmailto:[EMAIL PROTECTED] Monday, November 28, 2005, 5:25:41 PM, you wrote: >> So, the question is, can we scrap both namespace constants and namespace >> functions and just stay with classes (as was agreed on several months ago, >> Andi himself agreeing to it)? This would make the patch smaller, simpler, >> AND would allow me to reuse the "::" operator (and there would be no >> conflicts with ternary operations). >> SG> Absolutely. Static methods and Class constants are more than sufficient. SG> All the added functionality of namespaces without all the baggage. SG> +1 SG> -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV]
Hello Mike, Same at my company. mailto:[EMAIL PROTECTED] Wednesday, November 30, 2005, 4:31:58 AM, you wrote: MH> Just FYI, the lack of tags on all development projects at my company. MH> Mike MH> On Mon, 28 Nov 2005 20:29:42 +0100 MH> Marcus Boerger <[EMAIL PROTECTED]> wrote: >> Hello Bastian, >> >> id like to see '> >> marcus >> >> Monday, November 28, 2005, 9:56:56 AM, you wrote: >> >> > What concerns me most is that > > tags will be disabled or not in php6. I currently use <%= to counter >> > this, but I am most certainly *not* happy with it. >> >> > So a clean > > about xml/xsl files parsed and neither about my templates growing too >> > large because of php overhead. >> >> > Sara Golemon wrote: >> >>> I recall this being discussed before, but not what came of it: is there >> >>> a problem with just ignoring > >>> or =? > >>> much doubt there's any BC break. Unless someone's program relies on >> >>> parse errors. >> >>> >> >> The problem there becomes legacy support for: >> >> >> >> >> >> >> >> And before you say "just watch for parens" there's also: >> >> >> >> >> >> >> >> and a much more insiduous example: >> >> >> >> >> >> >> >> no semicolon, no parens, no paamayim nekudotayim, nothing but a >> >> perfectly valid looking PI tag. >> >> >> >> -Sara >> >> >> >> >> Best regards, >> Marcus >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php MH> Mike Hall MH> Twist Digital Media MH> e. [EMAIL PROTECTED] MH> D I S C L A I M E R MH> Statements and opinions expressed in this e-mail may not represent those MH> of the company. MH> The information transmitted is intended only for the person or entity to MH> which it is addressed and may contain confidential and/or privileged MH> material. Any review, retransmission, dissemination or other use of, or MH> taking of any action in reliance upon, this information by persons or MH> entities other than the intended recipient is prohibited. If you MH> received this in error, please contact the sender immediately and delete MH> the material from any computer. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Hello Aidan,
I think named parameters would be a useful feature... I'll leave it
at that.
Here is a coding idea for you, in case you hadn't considered it...
function highlight($text=NULL, $needle=NULL, $strip_links=NULL, ...)
{
is_null($text) && $text = SOME DEFAULT VALUE;
is_null($needle) && $text = SOME DEFAULT VALUE;
is_null($strip_links) && $text = SOME DEFAULT VALUE;
...
}
In that way, the user doesn't have to remember the default values,
just the offsets.
Best wishes with the proposal.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Wednesday, January 11, 2006, 8:53:11 PM, you wrote:
AL> Andrei Zmievski wrote:
>> On Jan 9, 2006, at 4:09 AM, Aidan Lister wrote:
>>
>>> As useful functions tend to increase in complexity over time, often so
>>> does the number of parameters.
>>>
>>> It soon gets to the point where function calls look like:
>>> foo(true, false, false, false, false, true)
>>> The rest of the parameters being required to be supplied, with their
>>> default value, when the user is only interested in changing the last
>>> option.
>>>
>>
>> If you get to the point where your function has a dozen parameters, I
>> would suggest re-thinking the purpose and design of such a function,
>> because you are likely trying to make it do too much.
>>
>> -Andrei
AL> In a simple highlighting function I wrote (which at 16k hits is probably
AL> considered useful) I needed most of the following parameters:
AL> $text
AL> $needle
AL> $strip_links
AL> $case_sensitive
AL> $whole_word_only
AL> $simple_text_only
AL> $highlight_pattern
AL> $return_or_print
AL> $use_xhtml
AL> $tooltips_or_divs
AL> I imagine any function dealing with html may use a significant portion
AL> of these. Obviously some of these are for effect, but I think my point
AL> is clear enough.
AL> We've discussed other options at developers disposal like associative
AL> arrays, setOpt and getOpt functions in a class, but again each have
AL> their drawbacks and named parameters solve the problem elegantly.
AL> Could we properly discuss the pros and cons of a name parameters
AL> implementation - even if it's only to put the whole issue to bed once
AL> and for all?
AL> Best wishes,
AL> Aidan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Hello Jared, JW> PHP is all about using a simple means to an end and getting the job JW> done. Named parameters makes coding easier, not harder. Well stated. -- Best regards, Jasonmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Hello Andi, I think the "sexy" syntax is a significant plus, even if associative arrays were used in the implementation. Is it a complex thing to implement? -- Best regards, Jasonmailto:[EMAIL PROTECTED] Thursday, January 12, 2006, 6:44:59 PM, you wrote: AG> In my opinion, as Ilia stated passing an associative array does the AG> job quite well for the use-case where named arguments would be useful. AG> Sure it might be a tad-bit sexier that you don't have to write AG> array() but the truth is that the implementation would probably still AG> use an array. Unlike Ada which has extremely strict typing, in PHP in AG> most cases we wouldn't be able to optimize away the named parameters, AG> meaning that we'd probably do the array() trick anyway. AG> Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Adieu register_globals
Hello Zeev, I'd be happy to do this. Do you want this placed in a function or just sample code to post somewhere? -- Best regards, Jasonmailto:[EMAIL PROTECTED] Monday, March 6, 2006, 6:38:34 PM, you wrote: ZS> A part of the decision was to supply the few lines of code necessary ZS> to emulate register_globals in userspace. Volunteers? :) ZS> Zeev ZS> At 22:46 06/03/2006, Pierre wrote: >>On Sun, 5 Mar 2006 16:21:28 +0100 >>[EMAIL PROTECTED] (Pierre) wrote: >> >> > Hello, >> > >> > As discussed last year, register_globals will be removed in php6. This >> > patch is the first step: >> > >> > http://pear.php.net/~pierre/remove_register_globals.txt >> > >> > The only thing I find confusing is a comment in main/php_variables.c >> > php_autoglobal_merge. The comment says something and the tests >> > something else (register_globals AND instead of register_globals OR). >> > I will review all the affected tests if you consider this patch ok to >> > be commited. Some will be updated, other simply removed. >> > >> > I did not run benchmarks, but I feel like it speeds up php a bit :) >> > >> > Comments and feedbacks welcome, >> >>Still welcome... >> >>The patch includes now: >>- the all tests fixes (session) >> * tests being useless now are skiped (to allow review, will removed >> later) >>- functions removed: >> * session_register >> * session_unregister >> * session_is_registered >> They need register_globals to work >> >>I will wait until wednesday for feedbacks or objections, and commit on >>thursday. >> >>--Pierre >> >>-- >>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] Passing functions to function by reference
Hello Rasmus,
RL> In 5.1 this now throws an E_STRICT instead of a warning. It is still a
RL> bad idea to pass a tempvar by reference, so yes, you should strive to
RL> write E_STRICT clean code.
At the possible expense of being blamed and flamed, I'll say it...
ifsetor($var, 'default') would go a long way to accommodate E_STRICT
code.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Wednesday, April 26, 2006, 6:41:26 PM, you wrote:
RL> Brian Moon wrote:
>> In PHP4, you could do:
>>
>> function test()
>> {
>>return array(1,2,3);
>> }
>>
>> $var = array_shift(test());
>>
>> PHP 5.0 broke this. There was a fatal error on the array_shift that
>> only variables could be passed by reference. There was a good argument
>> for it. So, we started migrating our code.
>>
>> Well, seems this works in 5.1. So, my question is, was it an
>> intentional "fix" or will this break again and we need to continue to
>> watch for this?
RL> In 5.1 this now throws an E_STRICT instead of a warning. It is still a
RL> bad idea to pass a tempvar by reference, so yes, you should strive to
RL> write E_STRICT clean code.
RL> -Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] private, protected, readonly, public
Hello internals,
__get() and __set() are great, but 90% of the time, I find myself
using them to create public readonly properties.
The only problem with this is it is horridly inefficient, consuming
at least 1 function call and one switch statement (or equiv) per
property read.
Would it be possible to create a new object property attribute:
readonly
class xx
{
readonly $bar;
}
$o = new xx();
$o->bar = 10;
>>> FATAL ERROR
This way, PHP would allow reading (as if it were public), but only
allow writing from within the class.
I think it could really boost performance of complicated application
logic that wishes to enforce good visibility.
Comments?
PS. What brought this up was some serious performance issues in a
piece of code that I am working with - most of which can be tied
back to __get() performance.
--
Best regards,
Jason Garber mailto:[EMAIL PROTECTED]
IonZoft, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Hello,
PHP implements many features, and skips many features. I think the
rule of thumb needs to be that if a feature is implemented, finish
it.
For example, if you provide __get() and __set(), provide an
efficient way of handling the normal use case.
If you start triggering an E_NOTICE when an undefined variable is
accessed, then provide an easy way to access variables that may or
may not be set.
If you provide a __tostring() method, then finish it so that is gets
called when an object is cast to a string, concatenated with a
string, as well as being output with echo, print.
There are a lot of casual users of PHP. There are also the people
out there who are buying the Zend products, buying the MySQL support
contracts, using PHP at Yahoo! -- the people who have chosen to use
PHP OVER Java/.NET/Perl, because it is a great language -- the
people who need the completed features because they are running
multi-million-dollar businesses on this platform.
Take a step back and truly evaluate why someone in a demanding
situation might want every bit of performance and readability that
they can squeeze out of *existing* language features.
I'm not talking about adding hundreds of new features, or turning
PHP into the next java. It's about real business cases.
It's not about what YOU WOULD NOT use, it's about what a lot of
people need.
--
Best regards,
Jason Garber mailto:[EMAIL PROTECTED]
IonZoft, Inc.
Friday, May 12, 2006, 3:16:27 PM, you wrote:
igc> It seems to me this would be a great option to add. How difficult would it
igc> be? Would it take significant editing of the source code? I don't see the
igc> issue in adding it - seems like it would have plenty of places to be used.
igc> Though, if it is added, the name 'readonly' seems a little misleading. It
igc> gives off the idea of being able to set it, and not edit again, and not
only
igc> being able to edit it inside the class.
igc> On 5/12/06, Hartmut Holzgraefe <[EMAIL PROTECTED]> wrote:
>>
>> Bastian Grupe wrote:
>> > Blame my recent use of Java here ;-)
>> >
>> > Well, I think the whole point of ppp is to having to use setters and
>> > getters consistently.
>>
>> i'm going to blame your use of Java for this one, ppp is way older
>> than the setter/getter fashion and as far as i remember the main
>> reason to introduce the setter/getter pattern into java was to
>> have a standard way for Java IDEs to provide access to Java Bean
>> properties in property dialogs in their GUI design tools
>>
>> > I personally wouldn't like to be able to access some members which are
>> > private, and not others. It just *feels* wrong.
>>
>> Think of it as a more fine grained permission system, like unix
>> file attributes. Reading and writing a property value are two
>> different operations and it makes sense to distinguish access
>> rights not only by ownership but also by type of operation.
>>
>> > And I don't know whether or not less typing is really a good argument in
>> > this situation (think unreadable code in shortcut-ish programming
>> > languages).
>>
>> Less typing is not an argument by itself, else we'd all do APL
>>
>> But less typing is less error prone (and no, plese *don't* mention
>> auto-completion here ;), it can be less readable, too, and in this
>> special case it spreads information that should be in one place.
>> Maintainability can become an issue, too.
>>
>> Take a look at typical PHP class implementations: they have
>> all properties on top followed by the member functions. So to find
>> out whether a private property is really provite or whether it has
>> a getter or even a setter, too, i would have to browse the full
>> class code.
>>
>>class example {
>> private $foo;
>> private $bar;
>> [... more properties ...]
>>
>> function __construct() {...}
>> function __destruct() {...}
>>
>> function getFoo() {...}
>>
>> [... more code ...]
>>}
>>
>> So $foo is readonly here and $bar is really private. Or wait,
>> maybe we have just overlooked getBar()?
>>
>> With
>>
>>readonly $foo;
>>
>> on the other hand you have all the information in one place.
>>
>> If you want to go the getter/setter path all the way then we
>> wouldn't need all the ppp stuff anymore alltogether, we would
>> just make everything private and have the getter and setter
>> decide (using instanceof on $this etc.) the access rights.
>>
>>
>> --
>> Hartmut Holzgraefe, Senior Support Engineer.
>> MySQL AB, www.mysql.com
>>
>> Are you certified? http://www.mysql.com/training/certification
>>
>> --
>> 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] private, protected, readonly, public
Hello Marcus,
class x
{
public readonly $xyz;
protected readonly $abc;
}
Definitions:
- public readonly- outside class can only read, not write.
- protected readonly - subclass can only read, not write.
- private readonly - does not make sense - do not support.
How difficult would it be to build this into the PHP engine?
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Saturday, May 13, 2006, 5:27:34 AM, you wrote:
MB> Hello Etienne,
MB> Friday, May 12, 2006, 2:11:38 PM, you wrote:
>> Hi,
>> my 2c:
>> 1) it shouldn't replace the visibility definition: we could also have
>> protected readonly properties.
MB> same here visibility and read/write control are two seperate things.
>> 3) how would you check if the property if readonly ? Trying it could
>> result to a Fatal error as you wanted. You would then need a
>> isReadonly() method/function: the function call wouldn't be spared.
MB> We could add this to reflection api easily.
MB> Best regards,
MB> Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Hello Zeev,
In the same way that public readonly properties would be useful
from the global scope, protected readonly properties would be just
as useful to those of us who spend their php-lives writing base
classes (like me) for others to extend and use.
I would imagine that the Zend Framework will encounter the
(performance based) need for this eventually - I already have.
That being said, an access level that means "public readonly" would
be very good - but taking it the whole way would be a lot better.
Considering that it is an optional keyword, and will only be used
where __get(), __set() used to be used - it won't confuse the end
users who do not care about it. (get/set is a lot more complex).
Thanks!
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Monday, May 15, 2006, 2:15:50 PM, you wrote:
ZS> I have to say that in second thought (after realizing what you really
ZS> meant) it sounds like a very useful feature.
ZS> The main thing that worries me is the complexity to the end user,
ZS> which is already in a pretty bad shape as it is today, and many
ZS> people here care very little about it, because they can't relate to
ZS> beginners and average developers. Private/protected/public is a
ZS> challenge to many of them (not the theory, real world situations),
ZS> doubling complexity with a modifier is not a good idea.
ZS> In order to push complexity down I'd avoid making this yet another
ZS> modifier, and in fact make this an access level, on par with
ZS> private/protected/public, that would behave like public, except for
ZS> when outside the object scope (i.e., have it between protected and
ZS> public). One of the trickey things would be finding an acceptable
ZS> name, since 'readonly' implies something which this variable isn't
ZS> (it's very much writable, from the right places). Maybe something
ZS> like 'visible' (of course preferably we need to find something that
ZS> begins with 'p'...)
ZS> Zeev
ZS> At 02:35 12/05/2006, Jason Garber wrote:
>>Hello internals,
>>
>> __get() and __set() are great, but 90% of the time, I find myself
>> using them to create public readonly properties.
>>
>> The only problem with this is it is horridly inefficient, consuming
>> at least 1 function call and one switch statement (or equiv) per
>> property read.
>>
>> Would it be possible to create a new object property attribute:
>> readonly
>>
>> class xx
>> {
>> readonly $bar;
>> }
>>
>> $o = new xx();
>>
>> $o->bar = 10;
>> >>> FATAL ERROR
>>
>>
>> This way, PHP would allow reading (as if it were public), but only
>> allow writing from within the class.
>>
>> I think it could really boost performance of complicated application
>> logic that wishes to enforce good visibility.
>>
>> Comments?
>>
>> PS. What brought this up was some serious performance issues in a
>> piece of code that I am working with - most of which can be tied
>> back to __get() performance.
>>
>>--
>>Best regards,
>> Jason Garber mailto:[EMAIL PROTECTED]
>> IonZoft, Inc.
>>
>>--
>>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] private, protected, readonly, public
Hello Andi, Your request for edge condition research is an excellent one. We've just been through a hellish couple weeks of QA failures (at my company) which just *underscore* your point. The last thing any of us needs is a broken PHP. That being said, is there anything I can do to help us find this stuff out? -- Best regards, Jasonmailto:[EMAIL PROTECTED] Tuesday, May 16, 2006, 5:41:31 PM, you wrote: AG> Where would readable be enforced? Would it try and prevent getting AG> references to it? Are there any internal functions/classes which need AG> fixing to honor readable? AG> I think these answers would really be helpful. AG> Thanks. AG> Andi AG> At 02:37 PM 5/16/2006, Marcus Boerger wrote: >>Hello Andi, >> >> that is why most here already switched to "public readable". >> >>best regards >>marcus >> >>Tuesday, May 16, 2006, 11:31:14 PM, you wrote: >> >> > I can't quite explain it but for me the ability to work-around >> > private with methods which are able to access the private variable, >> > is different than marking a property as read-only but it not being >> > read-only in all semantics. Probably because private variables do >> > often have getters and setters, whereas something which is marked as >> > read-only (like a harddrive) tends to be read-only always. >> >> > Andi >> >> > At 02:08 PM 5/16/2006, Zeev Suraski wrote: >> >>>However, the reason i write this mail is that you said there could be >> >>>problems. Well this is deply integrated in the handlers and they don't >> >>>let you out. In other words if this stuff is not working then the whole >> >>>PHP 5+ object model is broken. Or in other words, if this is broken alot >> >>>of other stuff regarding object handling is already broken. >> >> >> >>You're probably right about this one. You can already return a >> >>reference to a private variable today and change it. Andi - did you >> >>mean something else? >> >> >> >> >>Best regards, >> Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Hello Marcus, Is this correct? private readable $abc; - doesn't make sense. protected readable $abc; - sub-class can read, not write - not visible outside class public readable $abc; - sub-class can read, and write - outside class can read, not write If not, please clarify. Thanks! -- Best regards, Jasonmailto:[EMAIL PROTECTED] Tuesday, May 16, 2006, 5:49:45 PM, you wrote: MB> Hello Andi, MB> nothing else needs to be fixed. The patch considers a reference as a write MB> operation as well as anything else that doesn't identify itself as a read MB> operation. And the enforcement itself just means that whatever you define MB> besides readable is being ignored for read operations. MB> best regards MB> marcus MB> Tuesday, May 16, 2006, 11:41:31 PM, you wrote: >> Where would readable be enforced? Would it try and prevent getting >> references to it? Are there any internal functions/classes which need >> fixing to honor readable? >> I think these answers would really be helpful. >> Thanks. >> Andi >> At 02:37 PM 5/16/2006, Marcus Boerger wrote: >>>Hello Andi, >>> >>> that is why most here already switched to "public readable". >>> >>>best regards >>>marcus >>> >>>Tuesday, May 16, 2006, 11:31:14 PM, you wrote: >>> >>> > I can't quite explain it but for me the ability to work-around >>> > private with methods which are able to access the private variable, >>> > is different than marking a property as read-only but it not being >>> > read-only in all semantics. Probably because private variables do >>> > often have getters and setters, whereas something which is marked as >>> > read-only (like a harddrive) tends to be read-only always. >>> >>> > Andi >>> >>> > At 02:08 PM 5/16/2006, Zeev Suraski wrote: >>> >>>However, the reason i write this mail is that you said there could be >>> >>>problems. Well this is deply integrated in the handlers and they don't >>> >>>let you out. In other words if this stuff is not working then the whole >>> >>>PHP 5+ object model is broken. Or in other words, if this is broken alot >>> >>>of other stuff regarding object handling is already broken. >>> >> >>> >>You're probably right about this one. You can already return a >>> >>reference to a private variable today and change it. Andi - did you >>> >>mean something else? >>> >>> >>> >>> >>>Best regards, >>> Marcus MB> Best regards, MB> Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Hello Christian, CS> Does anyone apart from me wonder why we need to bloat the language for CS> an obscure feature like this? Please take a step back, take a deep CS> breath, count to 10 and that's *really* what the PHP community has been CS> waiting for. Please consider that not everyone does the same things with PHP that you do - you apparently haven't run into the need for it. That's okay, but others have. -- Best regards, Jasonmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Hello Marcus, I've put together a simple test framework and a 18 test cases to start with. It's a stand-alone system that should work correctly on PHP 5 installs. Both CLI mode and Web Server mode work fine. NOTE: The tests I wrote are only testing standard functionality. We need to add tests to check out the new readable patch. -- View the tests online: http://open.izrm.com/~jason/php-readable -- Download a .tgz - just unpack it and it's ready to go: http://open.izrm.com/~jason/download/php-readable.tgz -- Get it with SVN: svn checkout svn://open.izrm.com/php-readable -- If anyone is interested in contributing test cases, please send them over. Thanks! -- Best regards, Jasonmailto:[EMAIL PROTECTED] private-outside-read.php private-outside-write.php private-subclass-read.php private-subclass-write.php private-thisclass-read.php private-thisclass-write.php protected-outside-read.php protected-outside-write.php protected-subclass-read.php protected-subclass-write.php protected-thisclass-read.php protected-thisclass-write.php public-outside-read.php public-outside-write.php public-subclass-read.php public-subclass-write.php public-thisclass-read.php public-thisclass-write.php testing-system-test.php Tuesday, May 16, 2006, 6:11:23 PM, you wrote: MB> Hello Jason, MB> write testcase, write in a way that they capture any usage you can MB> think of. Parameter parsing, reference handling returning, inheritance, MB> trying to circumvent the whole stuff, checking all error messages are MB> in place, overloading internal objects that have special handlers just MB> to hwat happens with them (dom, simplexml for instance). How do the MB> magic methods __get, __set, __unset, __isset interfere if at all MB> best regards MB> marcus MB> Tuesday, May 16, 2006, 11:59:08 PM, you wrote: >> Hello Andi, >> Your request for edge condition research is an excellent one. We've >> just been through a hellish couple weeks of QA failures (at my >> company) which just *underscore* your point. The last thing any of >> us needs is a broken PHP. >> That being said, is there anything I can do to help us find this >> stuff out? >> -- >> Best regards, >> Jasonmailto:[EMAIL PROTECTED] >> Tuesday, May 16, 2006, 5:41:31 PM, you wrote: AG>>> Where would readable be enforced? Would it try and prevent getting AG>>> references to it? Are there any internal functions/classes which need AG>>> fixing to honor readable? AG>>> I think these answers would really be helpful. AG>>> Thanks. AG>>> Andi AG>>> At 02:37 PM 5/16/2006, Marcus Boerger wrote: Hello Andi, that is why most here already switched to "public readable". best regards marcus Tuesday, May 16, 2006, 11:31:14 PM, you wrote: > I can't quite explain it but for me the ability to work-around > private with methods which are able to access the private variable, > is different than marking a property as read-only but it not being > read-only in all semantics. Probably because private variables do > often have getters and setters, whereas something which is marked as > read-only (like a harddrive) tends to be read-only always. > Andi > At 02:08 PM 5/16/2006, Zeev Suraski wrote: >>>However, the reason i write this mail is that you said there could be >>>problems. Well this is deply integrated in the handlers and they don't >>>let you out. In other words if this stuff is not working then the whole >>>PHP 5+ object model is broken. Or in other words, if this is broken alot >>>of other stuff regarding object handling is already broken. >> >>You're probably right about this one. You can already return a >>reference to a private variable today and change it. Andi - did you >>mean something else? Best regards, Marcus MB> Best regards, MB> Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Hello Hannes, Nothing is wrong, I presume. Ignorance on my part. Thanks. -- Best regards, Jasonmailto:[EMAIL PROTECTED] Wednesday, May 17, 2006, 7:50:47 AM, you wrote: HM> Hi Jason >> I've put together a simple test framework and a 18 test cases to HM> Whats wrong with 'run-tests.php' ? http://qa.php.net/write-test.php HM> -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Multi-Method Dispatch in PHP 5.1?
If it makes any difference...
I would say no way to multi method dispatch. PHP, in my understanding, was
a loosely typed language, and this is straining against that very
concept. In the rare case that one needs multi-method dispatch, they can
use a format such as:
class xyz
{
public function Foo($p1 = NULL, $p2 = NULL)
{
if($p1 instanceof Bar && is_numeric($p2))
{
//do something or
return $this->Foo_Bar_Int($p1, $p2);
}
elseif($p1 instanceof OtherBar && is_null($p2))
{
//do something or
return $this->Foo_Otherbar($p1);
}
}
...
}
~Jason
At 4/21/2004 07:32 AM +0200, Michael Walter wrote:
Christian Schneider wrote:
Sebastian Bergmann wrote:
Since we introduce class type hints in PHP 5.0 I think it would be a
good thing [tm] to add multi-method dispatch in PHP 5.1.
Actually I think multi-method dispatching for PHP is A Bad Thing[tm].
Multi-method dispatching is necessary for statically checked, inflexible
languages without default parameters like Java.
That's probably why Common Lisp, a language way more dynamic than PHP,
provides you with a complete implementation of multiple dispatch. How
exactly do you think are default parameters related to the issue, anyway?
PHP has other means of handling the most common problems this tries to
solve and having two methods of the same name is more confusing than
helping IMHO.
I assume you are you aware of what dynamic dispatch is trying to solve --
could you give an example of the 'other means' you are referring to?
Cheers,
Michael
--
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] Multi-Method Dispatch in PHP 5.1?
Just a note, Would "Object" be more appropriate than "Class"? The expected variable type is an object (defined by a class), and the gettype() function returns 'object'.. # php -r '$x=new stdclass(); var_dump(gettype($x));' string(6) "object" It may mean adding a new reserved word though. ~Jason At 4/22/2004 01:29 AM +0200, Marcus Boerger wrote: Hello Andi, the patch is here. It's a bit outdated but shouldn't cause much problems to apply after RC2. It allows "Class", "Array" but atm misses "Resource". marcus Wednesday, April 21, 2004, 11:50:46 AM, you wrote: > At 03:29 PM 4/20/2004 -0400, George Schlossnagle wrote: >>On Apr 20, 2004, at 3:18 PM, Marcus Boerger wrote: The problem with this is that that integer may well be a string when you look at it. There's no good way to do this past discriminating between scalar, array and object (by type, of course). I personally think that that is fine (adding an array typehint would be nice). >>> >>>Somewhere at my server should be a patch for "array". For some reason >>>i was too lazy to ask for that to commit again before RC1. I you still >>>want this just ask Andi/Zeev again. >> >>Andi/Zeev, >> >>Thoughts on allowing array typehinting? > I don't have a problem with array type hinting but I want to roll RC2. I > suggest we look at Marcus' patch after RC2 and see if it's small enough to > allow the inclusion before 5.0.0. > Andi -- Best regards, Marcusmailto:[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] Performance Consideration of 1 class per file
Hi,
One of the questions that I have is "how long is long?". Here is an
interesting example of a large system that I work on.
On the first line of each script, we have a line like:
require_once('izfc.core4.php'); //exists in global include path
The job of that script is to find and include all functionality that the
application needs at that point, but no more. It traverses the directory
tree up one level at a time searching for 4 files in each level. Anything
named "_include" is automatically added to the include path, and anything
named "_init.php" and "_exec.php" is automatically included (init is
top-down, exec is bottom-up). The init and exec files are the directory
level control files that include and initialize components of the
application. For instance, the database connection is created in a low
level _exec.php file.
Performance aside, it has really proved to be a great system for providing
directory level functionality (like sessions), database connections, and
general functionality includes for a large application (~5000 scripts;
70,000,000 row, 200+ table, 8gb mysql database).
So, this discussion prompted me to take a close look at the
performance. By the second line any given script in this section of the
project, all of the following files have been found and included (which
took 24 file_exist() calls):
Here are the components of the include path that was set:
.
/home/ionzoft/z.projects/vos4a/dev.2/virtual/myhealthycustomers.com/_include
/home/ionzoft/z.projects/vos4a/dev.2/_include
/home/ionzoft/z.projects/vos4a/dev.2//../../izfc/izfc4.production
And here are the files that were included:
[0] => /var/var-home/ionzoft/z.projects/vos4a/dev.2/virtual/_vo/member/menu.php
[1] => /var/var-home/ionzoft/izfc/izfc.core4.php
[2] => /var/var-home/ionzoft/z.projects/vos4a/dev.2/_root.php
[3] =>
/var/var-home/ionzoft/z.projects/vos4a/dev.2/virtual/myhealthycustomers.com/docroot/_init.php
[4] =>
/var/var-home/ionzoft/z.projects/vos4a/dev.2/_include/conf.CommunityData.php
[5] => /var/var-home/ionzoft/z.projects/vos4a/dev.2/_exec.php
[6] => /var/var-home/ionzoft/z.projects/vos4a/dev.2/_include/conf.core.php
[7] => /var/var-home/ionzoft/z.projects/vos4a/dev.2/_include/conf.vars.php
[8] => /var/var-home/ionzoft/z.projects/vos4a/dev.2/_include/conf.SysData.php
[9] => /var/var-home/ionzoft/izfc/izfc4.20040124/class.CSysData.php
[10] =>
/var/var-home/ionzoft/z.projects/vos4a/dev.2/_include/conf.ErrorHandler.php
[11] =>
/var/var-home/ionzoft/z.projects/vos4a/dev.2/_include/code.ErrorHandler.php
[12] => /var/var-home/ionzoft/z.projects/vos4a/dev.2/_include/conf.db.php
[13] => /var/var-home/ionzoft/izfc/izfc4.20040124/class.CMySQLConnection.php
[14] => /var/var-home/ionzoft/izfc/izfc4.20040124/class.CLog.php
[15] =>
/var/var-home/ionzoft/z.projects/vos4a/dev.2/virtual/myhealthycustomers.com/docroot/_exec.php
[16] => /var/var-home/ionzoft/izfc/izfc4.20040124/code.Links.php
[17] => /var/var-home/ionzoft/z.projects/vos4a/dev.2/virtual/_vo/_exec.php
[18] =>
/var/var-home/ionzoft/z.projects/vos4a/dev.2/virtual/_vo/member/_exec.php
[19] =>
/var/var-home/ionzoft/z.projects/vos4a/dev.2/virtual/myhealthycustomers.com/_include/class.CVOSession.php
[20] => /var/var-home/ionzoft/izfc/izfc4.20040124/class.CSession.php
[21] => /var/var-home/ionzoft/z.projects/vos4a/dev.2/_include/class.CMember.php
[22] =>
/var/var-home/ionzoft/z.projects/vos4a/dev.2/virtual/myhealthycustomers.com/_include/class.CVOPage.php
[All in all, it is 2108 lines of code that was included; a database
connection was established, several queries, session established,
configuration arrays loaded, etc...]
Here are some numbers:
- It took .0003 seconds to complete the 24 file_exists() calls
- It took .017 seconds to include the 22 files (2108 lines)
- It took .002 seconds to finish the script, write the output, and get to
the bottom.
Obviously, the act of including the files took the longest. How much of
that time was filesystem stats, and how much was PHP loading, parsing, and
executing the content?
If each file_exists() call uses one or more stats, then I must say that a
stat is a very quick operation.
~Jason
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints
Consider this below:
At 5/11/2004 03:23 PM +0300, Andi Gutmans wrote:
At 11:44 AM 5/11/2004 +0200, Timm Friebe wrote:
On Mon, 2004-05-10 at 18:16, Andi Gutmans wrote:
> I think it's hard to put closure on this type hints issue.
[...]
> As no good syntax has been found for the less common case of allowing
> NULL's, I think the best solution for now is not to allow null in the
> regular type hint syntax, and have people who want to allow NULL's not use
> type hints at all (in any case, they need to manually check their
parameter
> so they'll do one more manual check).
Will this affect optional arguments? I.e., will the following still
work?
class UserClass {
public static function forName($name, ClassLoader $c= NULL) {
// ...
}
}
class UserClass{
public static function forName($name, $c = NULL) {
if(is_null($c))
//...
elseif($c instanceof ClassLoader)
//...
else
//Throw an error
}
}
Using this method, you can easily solve the issue pointed out above, while
allowing the type hint to be strict.
~Jason
$works= UserClass::forName('MySQLConnection');
(not passing any value for the optional parameter) vs.
$fails= UserClass::forName('MySQLConnection', NULL);
(passing NULL as "value" for the optional parameter)
Nope, why would it work? If we make the type hint strict (which I think we
should) then you can't define it to NULL.
Doing so would be kind of inconsistent.
Andi
--
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] [RFC] Type hints
Hello, I've been following this discussion from the beginning. To be pointed, I think that the whole matter is rather a serious case of "overfunctionality". Consider allowing a type hint such as function foo(MyClass $bar) The only way I see that as being useful is to be able to assume that you can safely say $bar->DoSomething()from within your function WITHOUT FIRST HAVING TO write an if() statement that verifies that it is not null. Even allowing null as a default parameter is somewhat disturbing. The programmer should ditch the typehint if he needs any behavior other than the one described above, and use a simple if() statement to find out if it is the correct class. If it is deemed necessary to allow a NULL default parameter, then let's keep it simple - function foo(MyClass $bar = NULL) IMHO, PHP has always been a language that can be used very simply, but still has the low-level power to accommodate all the other things that one wishes to accomplish. Let's keep it that way. __________ Jason Garber President & Chief Technology Officer IonZoft, Inc. 814.742.8030 :: [EMAIL PROTECTED] :: http://IonZoft.com __ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints
Hi Marcus, You are totally correct. I should have clarified my statement on the default parameter vs allowing nulls as they are very different. To sum it up, as Andi said: "I think the best solution for now is not to allow null in the regular type hint syntax, and have people who want to allow NULL's not use type hints at all..." +1 ______ Jason Garber President & Chief Technology Officer IonZoft, Inc. 814.742.8030 :: [EMAIL PROTECTED] :: http://IonZoft.com __ At 5/10/2004 06:24 PM +0200, Marcus Boerger wrote: Hello Jason, Monday, May 10, 2004, 5:31:38 PM, you wrote: > Hello, > I've been following this discussion from the beginning. To be pointed, I > think that the whole matter is rather a serious case of "overfunctionality". > Consider allowing a type hint such as > function foo(MyClass $bar) > The only way I see that as being useful is to be able to assume that you > can safely say $bar->DoSomething()from within your function WITHOUT > FIRST HAVING TO write an if() statement that verifies that it is not null. > Even allowing null as a default parameter is somewhat disturbing. The > programmer should ditch the typehint if he needs any behavior other than > the one described above, and use a simple if() statement to find out if it > is the correct class. Until here i very much agree. To clearify: The reason i provided all the patches is that i simply want the descibed behavior as default and if at all a syntax addition to allow NULL explicitly. > If it is deemed necessary to allow a NULL default parameter, then let's > keep it simple - function foo(MyClass $bar = NULL) As i pointed out before this solution comes with a slight disadvantage and it also contains some magic. It is simply semantically very different from secifying the allowed types and setting a default value. Combining them is therefore magic that is hard to understand. > IMHO, PHP has always been a language that can be used very simply, but > still has the low-level power to accommodate all the other things that one > wishes to accomplish. Let's keep it that way. Yes we have very good solution which one must not use. In C++ or Java you are forced to use all the syntax or you will fail. best regards marcus -- 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] Implicit Arrays and E_STRICT
I would view implicit array creation as a slightly negative thing, similar to accessing the value of a variable that does not exist. We run in E_ALL mode and write our code to avoid all E_NOTICEs. For instance, before using an array, I always initialize it using $aItems = array(); I'm in favor of issuing an E_NOTICE in response to this. ~Jason At 5/8/2004 12:43 AM +0200, Marcus Boerger wrote: Hello Sara, i like to see one of those too and i have no preference for one of them. marcus Friday, May 7, 2004, 11:05:15 PM, you wrote: > This topic got quietly dropped last week, but I'd like to make one last > plea. I'd like to see Zend throw an E_STRICT when arrays are implicitly > created. I know there were objections to E_NOTICE, but did anyone have > violent objections to E_STRICT? > -Sara -- Best regards, Marcusmailto:[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] Javascript / Php
Hello,
This is the internal development mailing list. Please repost your question
to the "General users list" at http://www.php.net/mailing-lists.php
FYI, PHP is a server side scripting language, and javascript is a client
side scripting language. Javascript code will not be evaluated until long
after PHP is finished.
~Jason
At 4/28/2004 02:37 PM +0200, Kyle Vorster wrote:
document.write(screen.width);";
$width = "document.write(screen.height);";
if (($height == "640") && ($width == "480")) {
echo "height == 640 & width = 480";
} elseif (($height == "800") && ($width == "480")) {
echo "2";
} elseif (($height == "800") && ($width == "600")) {
echo "3";
} elseif (($height == "1024") && ($width == "576")) {
echo "4";
} elseif (($height == "1024") && ($width == "768")) {
echo "Height = 1024 & width = 768";
}
echo "Height == $height & width == $width";
}
?>
gives me this
Height == 1024 & width == 768
but the html for that is Height ==
document.write(screen.width); & width ==
document.write(screen.height);
and i wanne work with the 1024 in php and not with the html ,, what can
i do to
run the javascript at server side and not on the client side
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
__
Jason Garber
President & Chief Technology Officer
IonZoft, Inc.
814.742.8030 :: [EMAIL PROTECTED] :: http://IonZoft.com
__
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] constant name
Does it output "barfoo" or "bar"?
~Jason
At 5/5/2004 10:01 PM +0200, Mehdi Achour wrote:
Hi !
The manual reads :
"The name of a constant follows the same rules as any label in PHP. A
valid constant name starts with a letter or underscore, followed
by any number of letters, numbers, or underscores. As a regular
expression, it would be expressed thusly:
'[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]'"
I know that this is true when trying to echo a constant directly, as the
parser raise an error, but you can trick it with a constant() call :
define('
(\ /)
{=B0_=B0)
() ()
( )( )
', 'barfoo');
echo constant('
(\ /)
{=B0_=B0)
() ()
( )( )
') . chr(10); // outputs : bar
Is it a feature or a bug ? :)
Mehdi Achour
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
__
Jason Garber
President & Chief Technology Officer
IonZoft, Inc.
814.742.8030 :: [EMAIL PROTECTED] :: http://IonZoft.com
__
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: ZendEngine2 / zend_ini_parser.y zend_ini_scanner.l
It may be worth noting the way MySQL AB has been rolling out MySQL. They released 4.0.0 as a restructured release, did bug fixes and small changes up through 4.0.19, and are approaching the release of 4.1 with significant new features. It sounds like the same might apply here. ~Jason At 5/18/2004 12:03 AM +0300, Andi Gutmans wrote: Thanks Andrei. I'm sorry about this mess (I know it's my fault). I think it's becoming clear things are being held back because of the 5.0 release. As I mentioned I also have some work I'm holding back. I suggest so that we make sure that things aren't being held back for too long we plan on releasing 5.0 ASAP (IMO beginning of July would be a good and reasonable goal. Besides a few bug fixes I don't have anything else on my TODO). Once we release, it's probably best to branch 5.1 where we can start adding the new features which need more testing (like the ones I'm hoping to add) and keep 5.0 for bug fixes. We can then probably release 5.1 within a short period of time. Is that OK? Andi At 01:10 PM 5/17/2004 -0700, Andrei Zmievski wrote: It's reverted. Hope everyone's happy. - Andrei -- 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: PHP 5.0/5.1 (was: ZendEngine2 / zend_ini_parser.y zend_ini_scanner.l)
July 4th? Independence of copy-by-value day? At 5/19/2004 04:48 PM +0300, Zeev Suraski wrote: At 15:22 19/05/2004, Andi Gutmans wrote: At 01:21 PM 5/17/2004 -0700, Sara Golemon wrote: > It's not a big deal either way we go. If everyone is ok with the fact that > this was a one time slip and there aren't going to be any other feature > additions, small or big, so be it. > Long as it doesn't become a habbit :) > I think that in order to prevent PHP 5.0 lingering to oblivion, we should > set a target date for its release, that we can all work towards. About a > week before it we can branch 5.1, at least for the engine and TSRM. Given > the stability of RC2 and the amount of bugs that we need to sort out, I > think that early July makes sense. > I vote for July 17, which'll give us two months from today. Obviously this is contingent on 5.0 being suitably stable/safe, but if we all focus on bugfixes and not features, that should be doable. I'd also like to see at least three RCs between now and then. I think 3 RCs is a bit much. I doubt we need more than 1-2 more RCs. I'd like to release another RC within about a weeks time which include some Zend engine bug fixes we are working on. July 17th is fine with me although with all of the new features people want to work on, I'm not sure we need that much time. Especially if we make an extra effort in June to address as many bugs as possible. I agree. I think that earlier in July would be better, so that we don't have to wait too much longer before we branch 5.1. Maybe July 4? :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php __ Jason Garber President & Chief Technology Officer IonZoft, Inc. 814.742.8030 :: [EMAIL PROTECTED] :: http://IonZoft.com __ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Destructors
Hello,
This is a question relating to the new PHP5 Object Destructor
functionality. Consider the following:
class DB
{
function Query() { ... }
}
class Session
{
function SetVar() {
//sets a variable to be saved in the session
}
function __destruct() {
//Save session variables in database using global $oDB object.
global $oDB;
$oDB->Query(...);
}
}
$oDB = new DB();
$oSession = new Session();
$oSession->SetVar('foo', 'New Value');
//End of script
?>
Based on the above example, the $oSession->__destruct() method relies on
the $oDB object still being usable. How can this be structured to ensure
that the DB object does not get released first?
Thanks,
Jason
__________
Jason Garber
President & Chief Technology Officer
IonZoft, Inc.
814.742.8030 :: [EMAIL PROTECTED] :: http://IonZoft.com
__
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP5 rocks!
To add.. The 18 of us here at IonZoft wish to thank all members of the PHP team and everyone who has helped make it happen. We have built a fast growing company totally focused on solutions based on PHP, and are very excited about the release of PHP5. Thanks! Jason Garber At 6/7/2004 09:51 PM -0400, Hans Lellelid wrote: Hi guys, I just had to take a moment to let you all know just how cool this PHP5 thing is. I know that I've been kinda vocal (and perhaps out of place) in the past about some of the behavior of OO stuff like interfaces, and sure disappointed when __toString() became less magical, etc. Those are all really minor things in the face of just how frickin' cool it is to build applications with PHP5. From my perspective the greatest addition is Exceptions, followed very closely by the new object model, interfaces, etc. The use of libxml2 has made many new things possible -- and has made use of XSLT a much less painful ordeal. The only problem with PHP5 is just how painful it has made it to use PHP4. Anyway, just wanted to take a moment to say great work and thanks for making what I do for a living fun! :) Cheers, Hans -- 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] The open letter to Derick Rethans
Hey Alexander,
It appears from your posts that you are a very knowledgeable coder who
knows how to improve and increase the performance, stability, and security
of the PHP program. I think your input could be very valuable.
I think there would be a more, let's say, graceful, way of giving your
input. I know that it's hard to interpret (and easy to misinterpret)
attitudes from reading plain text, but here is what I see:
*It seems* that the intro to your code patches have somewhat of a superior
attitude. While they may be great patches, you have to remember that real
people busted their rear ends to write the code in the first place, and
probably got no money for it to boot.
Also, you have many people on this list like Derick that really do and have
spent countless hours of time making PHP into what it is. They are the
ones that are in charge of what get's included into this great
language. They are constantly working their tails off to fix the latest
bug, or implement the a new requested feature, or meet the deadline to roll
the next RC.
I would say that the priority on developing PHP is:
1. Bug Fixes from bugs.php.net
2. Features that are slated for upcoming versions of PHP
3. Recoding old functions to make them faster and more stable where needed.
If you want your input to be accepted, you got to play the way the rest of
the crowd is, in order for it to work.
Thanks for your effort, and I hope you direct it to where it can be used to
the fullest.
Sincerely,
Jason Garber
President
IonZoft, Inc.
At 6/15/2004 06:30 PM +0300, you wrote:
On Tue, 15 Jun 2004 12:47:29 +0200 (CEST), Derick Rethans <[EMAIL PROTECTED]>
wrote:
On Tue, 15 Jun 2004, Alexander Valyalkin wrote:
Today I checked file /win32/readdir.c
Below you can view its source with my comments.
Just a little notice that you succesfully made it into my killfilter.
Great job!
Derick
And what about your job?
So, you are author of mcrypt module. Let audit your work:
/ext/mcrypt/mcrypt.c
Can you explain me the sense of the memset() after any memory allocation
in the mcrypt.c. For example:
===
/* missing type casting from (void *) to (unsigned char *) */
pointer = emalloc (length_of_data);
/* sense of the next string? wasting time? */
memset (pointer, 0, length_of_data);
memcpy (pointer, data_pointer, length_of_data);
===
Why you don't wipe keys and initialization vectors before freeing memory?
Leave it for spies from NSA and KGB ? :)
For example:
===
if (key_s != NULL)
efree (key_s);
if (iv_s != NULL)
efree (iv_s);
===
Can you explain me the sense of initialization vector [iv] for ECB mode? :
===
/* {{{ proto string mcrypt_ecb(int cipher, string key, string data, int
mode, string iv)
ECB crypt/decrypt data using key key with cipher cipher starting with
iv */
===
Well, let see documentation of Mcrypt http://php.net/mcrypt/ :
==
MCRYPT_MODE_OFB (output feedback, in 8bit) is comparable to CFB, but can be
used in applications where error propagation cannot be tolerated. It's
insecure (because it operates in 8bit mode) so it is not recommended to
use it.
==
1) What happens with error propagation after deleting/inserting any data
into
encrypted in OFB-mode text? Do you know what means "self-synchronizing"
words
for CFB mode?
2) Do you know that not only 8bit OFB is insecure? OFB mode always have
less
security if size of encrypted text is not equal to blocksize of used
cypher.
For example, the security of 256bit AES cypher in 255bit mode is the
same as for 256bit AES in 8bit OFB mode.
==
MCRYPT_MODE_CFB (cipher feedback) is the best mode for encrypting byte
streams where single bytes must be encrypted.
==
How can I use this mode for encrypting byte streams, if function
mcrypt_cfb() dont return current [iv] value?
The same question for other modes, excepting ECB.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
--
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] Throw Question
Consider the following:
$x = FALSE;
$x || throw new exception('Some Assertion');
I get the following Parse Error:
error: parse error, unexpected T_THROW in /home/.../Z_Record.php on line 153
However, this code produces no errors..
$x = FALSE;
$x || exit;
Why is this?
Thanks,
Jason Garber
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throw Question
That's what I figured. throw is a language construct. However, from the manual (http://php.net/exit): void exit ( int status) Note: This is not a real function, but a language construct. Why does $x || exit; work without a parse error? Thanks, Jason Garber At 6/17/2004 10:22 AM +0400, Antony Dovgal wrote: On Thu, 17 Jun 2004 02:17:26 -0400 Jason Garber <[EMAIL PROTECTED]> wrote: > Consider the following: > Why is this? Take a look at the bug #28727: http://bugs.php.net/?id=28727 --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] || [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] Array Question
Hello, In PHP4 and PHP5 the following syntax works fine (note the last comma): array ( 1 => 'bob', 2 => 'sam', ); Is being able to have a comma at the END of an array definition a supported feature, or an undocumented feature that should not be used? Thanks, Jason Garber ______ Jason Garber President & Chief Technology Officer IonZoft, Inc. 814.742.8030 :: [EMAIL PROTECTED] :: http://IonZoft.com __ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throw Question
Thanks for the good explanation. ~Jason At 6/17/2004 02:10 PM +0200, Hartmut Holzgraefe wrote: Joseph Lee wrote: I guess "exit();" terminates execution within itself without returning to the caller, so that is no chance of getting a runtime error. parse error != runtime error but language constructs like exit, unset and print are especialy ment to be as function-like as possible, thats why you can use them in expressions ... -- Hartmut Holzgraefe <[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] Array Question
Cool. Thanks for updating the docs. I think it will save confusion with others in the future. ~Jason At 6/17/2004 11:34 PM +0200, Mehdi Achour wrote: This is now [1] a fixed documentation bug :) I didn't find anything about it in the ChangeLog, nor bugs.php.net, so I didn't include any version information in the docs. Drop a mail to the documentation list if you figure it out ;) didou [1] - http://cvs.php.net/diff.php/phpdoc/en/reference/array/functions/array.xml?r1=1.11&r2=1.12&ty=u Red Wingate wrote: I guess that was <= 4.1.0 as i get errors at work ( 4.0.x ) and everything went fine as i misstyped today using 5.0.0rc3 :-) --red Adam Maccabee Trachtenberg wrote: On Thu, 17 Jun 2004, Jason Garber wrote: Is being able to have a comma at the END of an array definition a supported feature, or an undocumented feature that should not be used? If I remember correctly, Zeev or Andi specifically added it as a result of a user request, so I'd say it's an undocumented feature. -adam -- 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] keyword arguments?
Hello,
I've been following this thread since it started... In my years of PHP
programming, I never had a problem with passing an array to a function and
using it's keys.
If this is about not typing array(), then I must say I strongly disagree
with the proposal. Shoot, with arrays, it's simple to define default
parameters.
function foo($aArgs)
{
$aArgs += array('SomeID' => 0, 'DoThat' => TRUE);
}
Required keys can even be checked for with a quick array_diff().
For the amount of times that it would *probably* be used, I don't think
it's worth adding new syntax for.
Sincerely,
Jason Garber
At 6/24/2004 10:55 PM +, Daniel Crookston wrote:
Okay, so keyword arguments probably won't be implemented. "Ice cube's
chance in hell" is the phrase I recall being thrown around. I have two
questions:
1. Why not?
2. Where do I start with my own copy of PHP to put it in? (The reason I
asked about it initially is that I thought it'd be a fun first "Let's
modify PHP" project.
And, finally - our messages are logged, aren't they? Why don't we trim
quoted emails? No need to log all those old things.
Dan
--
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 happened to that new isset() like language construct
Hi Marc, What we basically settled on was to use this syntax (as a new language construct): $x = ifsetor(mixed variable, mixed default); If I recall correctly, Marcus had a patch that implemented it and it was going to be plugged in in the 4.1 branch (when it is created). I'm eagerly waiting for it also :) Sincerely, Jason Garber At 7/7/2004 08:26 PM -0400, Marc Richards wrote: On 4/15/2004 Jason Garber asked about a new language construct to simplify testing if a variable isset() and assinging a default value for those that aren't. The thread title was "Construct Request". I rember reading it while the discussion went on, I just went back and browsed through it again. Everyone seemed to agree the it was generally a good idea and there was some minimal amount of consensus on the ?: syntax, but I can't tell if this was ever implemented. Was it? If not did I miss the reason why? Marc -- 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 happened to that new isset() like language
Hi Marc, At 7/7/2004 09:06 PM -0400, Marc Richards wrote: Jason Garber wrote: Hi Marc, What we basically settled on was to use this syntax (as a new language construct): $x = ifsetor(mixed variable, mixed default); So ?: is out then? Or just delayed until it can be tackled. Who am I to say it's out for good? :) I just thought that the general consensus was a function like call, rather than a new operator. I do remember that there was fairly strong support for both, but there were various disadvantages to a new operator vs a new "function" call. On a related note, does anyone know when 5.1 is going to be branched? Shortly after the 5.0.0 release, I assume. If I recall correctly, Marcus had a patch that implemented it and it was going to be plugged in in the 4.1 branch (when it is created). 5.1? Yep. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -Jason -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] what happened to that new isset() like language
The original reason that I asked for this functionality was to make it significantly easier to work with E_ALL error reporting. When I say easier, I mean by reducing duplicate code. //This $foo = (integer) ifsetor($_POST['foo'], 0); //Instead of $foo = (integer) (isset($_POST['foo']) ? $_POST['foo'] : 0); It was also to be useful for accessing array elements that may or may not be there. I strongly agree with Ramsus that ?: is far to close to the ternary operator and would prove to be *highly* confusing to beginners. Marcus made an excellent point about the 2 versions of the function: 1) $a = ifsetor($b) 2) $a = ifsetor($b, NULL) By the way, I'm not stuck on ifsetor() as a name, but a) the name should be short and clear b) the construct must be called with function like syntax Marc, I must ask, why are you so opposed to the function() syntax? There has been quite a few reasons stated against the operator syntax, but I haven't heard any reason why we should not go with the function() syntax? Sincerely, Jason Garber -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Need two simple string funcs for parsing
Hi Joe,
At 7/8/2004 07:07 PM -0400, [EMAIL PROTECTED] wrote:
Hello,
My name is Joe Lapp, and I have written high-speed portal-side parsers in
Java for XML, HTML, and various other XML-related syntaxes (e.g. XQL).
I am planning a series of new parsing technologies that I'd like to
implement in PHP. To allow my parsers to perform with high efficiency in
PHP, I need two new string functions. One is identical to strpbrk() but
would also take a starting-offset parameter.
Here are the two new functions:
/* strpbrk -- Returns the offset into a string of the first occurrence of
any character found in a list of provided characters, optionally scanning
the string starting from a provided string offset. */
strpbrk(string haystack, string char_list [, int starting_offset])
/* strnpbrk -- Returns the offset into a string of the first occurrence of a
character NOT found in a list of provided characters, optionally scanning
the string starting from a provided string offset. */
strnpbrk(string haystack, string char_list [, int starting_offset])
They sound useful for general purpose parsing and string manipulation...
In other words, strpbrk() would function as it does currently, but it would
take a starting_offset. strnpbrk() would be almost identical to this new
strpbrk(), except that it skips over characters found in the provided
character list and returns the position of the first character that is not
in the list.
(BTW, I'm not real fond of C-lib style cryptic names. I'd much prefer
string functions with readable names that are also good mnemonics.
Maybe scan_for_char() and skip_over_chars() would be better names.)
Ideally, these functions would also support a way to specify characters by
their unicode values and a way to specify a range of characters. For
example, "#8230;A-Z<>" would name the ellipsis character ("#8230;"), the
characters from A to Z, and the angle bracket characters.
The significance of these functions is purely processing speed. They would
allow me to create high-speed parsers and distribute them as uncompiled PHP.
If the functions are implemented properly, using them should produce much
faster code than the equivalent compiled PHP. The starting offset is
necessary to avoid creating a proliferation of substrings that would
significantly slow down parsing speed.
How could php code using compiled function calls ever be faster than 100%
compiled code?
What are the odds that we can get such functions into PHP 5? I am planning
a high-speed XML filtering technology for XML-replication servers in PHP. I
want to make this engine free as well as a particular application of this
engine that I think could create a whole new mode of using the net. Speed
is very important because of the amount of XML being processed. I cannot
use existing XML processors for the filtering function I have in mind. In
any case, these two new functions would allow people to easily create any
sort of high-speed parser.
I fear that without these functions, I'd have to distribute this new server
as compiled PHP and perhaps require faster server hardware (more clock cycles
available to the user per unit time) than most users currently have. Maybe
that's not a problem, except perhaps for my wallet. I don't know what sort
of Zend license I'd require to be able to distribute free pre-compiled code.
http://pecl.php.net
I am also an experience C/C++ programmer and can write these functions
myself. Before doing so, though, I'd like to know if I should bother.
Would they make it into PHP 5?
Thanks for your help!
~joe
--
Sincerely,
Jason Garber
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] what happened to that new isset() like language
Hi Marc, To be honest, I don't care at this point. As long as we have something implemented in 5.1 for allowing PHP users to simplify working in E_ALL error mode. This thing: a) it has to base it's decision on the same logic isset() uses b) it should not evaluate the second part unless it is needed c) it should not be confusing This reminds me of the instanceof keyword. What about using something like that? $foo = $bar setor $baz; If that could be implemented, it may be a way to consider. It would a) be easy to recognize b) be easy to chain them together c) not be confusing d) have a short, concise, CLEAR name Comments? Sincerely, Jason Garber At 7/8/2004 07:48 PM -0400, you wrote: Jason Garber wrote: The original reason that I asked for this functionality was to make it significantly easier to work with E_ALL error reporting. When I say easier, I mean by reducing duplicate code. //This $foo = (integer) ifsetor($_POST['foo'], 0); //Instead of $foo = (integer) (isset($_POST['foo']) ? $_POST['foo'] : 0); It was also to be useful for accessing array elements that may or may not be there. I strongly agree with Ramsus that ?: is far to close to the ternary operator and would prove to be *highly* confusing to beginners. I don't think it would be *highly* confusing to someone who has already used a ternary statement. If they haven't then even a ternary statement would be confusing. In either case I think good documentation would be important. I am still on the fence about the asymmetry in that one tests isset() while the other doesn't Marcus made an excellent point about the 2 versions of the function: 1) $a = ifsetor($b) 2) $a = ifsetor($b, NULL) See my response to Marcus' post By the way, I'm not stuck on ifsetor() as a name, but a) the name should be short and clear b) the construct must be called with function like syntax Marc, I must ask, why are you so opposed to the function() syntax? There has been quite a few reasons stated against the operator syntax, but I haven't heard any reason why we should not go with the function() syntax? I am interested in the new construct for the exact same reason, E_ALL development. I am intersted in the ?: operator because it looks alot simpler, especially if you want to chain them together: $user = $_SESSION['user] ?: $_POST['user'] ?: $local_user ?: NULL; I am not even sure if marcus' patch allowed you to nest multiple ifsetor() calls...either way, my main goal is simplicity. I am not just trying to be contentious, I am actually interested in a good solution. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Need two simple string funcs for parsing
Sure, Any recommendations? -Jason At 7/9/2004 09:12 AM +0200, Marcus Boerger wrote: Hello Jason, could you do something about your mail client? It strips off or cuts the mail id so that mail threads loose their connection for all of us. regards marcus -- 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] Segmentation Fault when using interface
Hello,
I discovered this problem tonight while working on a new PHP 5 class that
uses an interface. The code example came from
http://www.zend.com/php5/articles/engine2-php5-changes.php#Heading5
class MyException implements Throwable {
public function getMessage() {
echo "Hello\n";
}
}
$x = new MyException;
$x->getMessage();
?>
--
On this server, I get a Segmentation Fault:
[EMAIL PROTECTED] dev]$ php -v
PHP 5.0.0RC3 (cli) (built: Jun 24 2004 17:35:13)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.0RC3, Copyright (c) 1998-2004 Zend Technologies
with Zend Extension Manager v1.0.2, Copyright (c) 2003-2004, by Zend
Technologies
with Zend Optimizer v2.5.2, Copyright (c) 1998-2004, by Zend Technologies
with Zend Debugger v3.5.0, Copyright (c) 1999-2004, by Zend Technologies
[EMAIL PROTECTED] dev]$ php -f Interface.php
Segmentation fault
--
On this server, It works fine:
[EMAIL PROTECTED] Jason]$ php -v
PHP 5.0.0RC3 (cli) (built: Jun 14 2004 14:04:10)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.0RC3, Copyright (c) 1998-2004 Zend Technologies
[EMAIL PROTECTED] Jason]$ php -f Interface.php
Hello
--
Could it be a problem with the Debugger?
Thanks,
Jason Garber
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segmentation Fault when using interface
Bug #29081 Segmentation Fault when using Interface http://bugs.php.net/bug.php?id=29081 -Jason At 7/9/2004 01:30 PM +0200, you wrote: On Fri, 9 Jul 2004, Jason Garber wrote: > Hello, > > I discovered this problem tonight while working on a new PHP 5 class that > uses an interface. The code example came from > http://www.zend.com/php5/articles/engine2-php5-changes.php#Heading5 Please also file this bug inthe bug system (bugs.php.net). regards, Derick -- 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] Segmentation Fault when using interface
Sorry, The actual bug is http://bugs.php.net/bug.php?id=29080 29081 is a duplicate -Jason At 7/9/2004 05:16 PM -0400, Jason Garber wrote: Bug #29081 Segmentation Fault when using Interface http://bugs.php.net/bug.php?id=29081 -Jason At 7/9/2004 01:30 PM +0200, you wrote: On Fri, 9 Jul 2004, Jason Garber wrote: > Hello, > > I discovered this problem tonight while working on a new PHP 5 class that > uses an interface. The code example came from > http://www.zend.com/php5/articles/engine2-php5-changes.php#Heading5 Please also file this bug inthe bug system (bugs.php.net). regards, Derick -- 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP-DEV] New construct discussion Summary
Hello Marc, MR> I don't think a function named param() really fits, but I do like the MR> idea of adding a type check (or in the case of PHP a type cast) to the MR> function. MR> $level = (int) (isset($_SESSION['level']) ? $_SESSION['level'] : MR> (isset($_REQUEST['level']) ? $_REQUEST['level'] : 1)) MR> becomes MR> $level = value($_SESSION['level'], $_REQUEST['level'], 1, INT); MR> Of course, I have no idea how feasible this is. MR> Marc The concept is desirable, but can be achieved if you need it just as simply using already available syntax (ie a cast): $level = (integer) value($_SESSION['level'], 1); -- Best regards, Jasonmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP-DEV] New construct discussion Summary (was: what happened to that new isset() like language construct)
Hello, RL> $a = value($_GET['index'], $default); value() sounds like more like a "language construct" to me. I'm not sure if it accurately conveys the meaning though (not that it has stopped other functions from being added in the past :) -- Best regards, Jasonmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re[3]: [PHP-DEV] New construct discussion Summary
Sunday, July 11, 2004, 10:48:06 PM, you wrote:
RL> On Sun, 11 Jul 2004, Jason Garber wrote:
>> The concept is desirable, but can be achieved if you need it just as
>> simply using already available syntax (ie a cast):
>>
>> $level = (integer) value($_SESSION['level'], 1);
RL> The problem with that is this:
RL> $level = (int) value($_SESSION['level');
RL> Assume there is no level entry in the session array. This then
RL> effectively becomes:
RL> $level = (int) NULL;
RL> Guess what that gives you? Obviously not what we want here which is why
RL> we are talking about a mechanism to not cast that default value whether it
RL> be the unspecified NULL default, or whatever default is passed in.
What would be the point of casting something unless it was null? You
still have to do a type-check on the resultant value before you used
it for anything useful. It seems that in this case, reverting to the
ternary operator or the good old if() statement may be appropriate.
-- Before --
$level = value($_SESSION['level'], NULL, INT);
if(is_null($level)
{
//Initialize $level
}
-- After --
if(isset($_SESSION['level'])
{
$level = (integer) $_SESSION['level'];
}
else
{
//Initialize $level
}
I don't mean to be argumentative, but I'm just looking for a
application of what you said, as one is not coming to mind.
Thanks!
Jason
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary (was: what happened to that new isset() like language construct)
AG> How about default($var, expr)? I like it. -Jason -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary (was: what happened to that new isset() like language construct)
>> >> The problem with default() is that there will be tons of scripts out >> there >> that will be broken by this. Hence i'd like to see a more non intuitive >> name (like the ifsetor). Probably getvalue() was the best compromise so >> far. GS> what was wrong with nvl() (of oracle fame)? ifset() ifsetor() setor() are 3 short, "construct" sounding, meaningful names to consider (they have all been mentioned before). -Jason -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New construct discussion Summary
MR> $level = value($_POST['level'], NULL, INT);
MR> switch($level){
MR> case 0:
MR> echo "Welcome to level 0";
MR> break;
MR> case 1:
MR> echo "Welcome to level 1";
MR> break;
MR> case 2:
MR> echo "Welcome to level 2";
MR> break;
MR> default:
MR> echo "That level is invalid. Aborting"; /* $level == null or $level
>> 2 */
MR> }
This does not in any way call for a cast exception, it can easily be
rewritten as:
$level = (integer) value($_POST['level'], -1);
switch($level){
case 0:
echo "Welcome to level 0";
break;
case 1:
echo "Welcome to level 1";
break;
case 2:
echo "Welcome to level 2";
break;
default:
echo "That level is invalid. Aborting"; /* $level == -1 or
$level > 2
}
Don't get me wrong, an third parameter that specified a cast would not
hurt (in the way I see it being mainly used):
$x = (int) value($_GET['x'], 0);
$x = value($_GET['x'], 0, INT);
Not much different. I'm just saying that it should not be added if
the same thing can be accomplished with the same effort with existing
syntax. If a *frequent* use can be demonstrated for it, then I'd be
all for it.
Just my thoughts, thanks for reading.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] congrats and thanks
Hello PHPers, On behalf of all 19 of us here at IonZoft, I'd like to add to this letter by saying thank you for providing the *excellent* tool that allows us to make our livelihood this way. PHP 5.0 is a unparalleled release of not only PHP, not only open source, but of great software in general. There's nothing else like it out there. Keep it up, we appreciate it! -- Best regards, Jasonmailto:[EMAIL PROTECTED] Thursday, July 15, 2004, 7:39:39 PM, you wrote: MR> To all, MR> Congratulations are in order. MR> PHP5 is a monumental testament to open source. MR> More importantly, it's also a glowing example of what MR> software _can_ be when you have a dedicated group of MR> committed individuals who take pride in their work, even MR> when there isn't a paycheque or benefits package to MR> compensate for it. MR> My thanks to each and every one of you, the magnificent MR> doc team, and especially the core guys that have shlogged MR> on PHP all these years. PHP has and continues to supply me MR> with the tools I use every day to feed my family. MR> Humbly and sincerely, my thanks to you. MR> Nice stuff. MR> Best, MR> Mike Robinson MR> Torstar Media Group Television -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Chaining __set and __get in an expression
Hello Curt,
From http://us2.php.net/manual/en/language.operators.assignment.php
"The value of an assignment expression is the value assigned.
That is, the value of "$a = 3" is 3."
I take this to mean that ($foo->a = 'bar') will always return 'bar'
and that is a core feature of the language. Remember that $foo->a is
the left hand operand, and is only receiving the value. It is the =
operator that returns the value of the expression.
It may also be worth noting that the Associativity of the `=` operator
is "Right".
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Tuesday, July 20, 2004, 12:26:46 AM, you wrote:
CZ> Given the class definition:
CZ> class Caller {
CZ> private $x = array('a' => false);
CZ> function __set($name, $value) {
CZ> echo "setting\n";
CZ> $this->x[$name] = 'foo'; // intentially ignore value
CZ> }
CZ> function __get($name) {
CZ> echo "getting\n";
CZ> return $this->x[$name];
CZ> }
CZ> }
CZ> $foo = new Caller();
$b = $foo->>a = 'bar';
CZ> echo "b is " . $b . "\n";
CZ> /* output:
CZ> setting
CZ> b is bar
CZ> */
?>>
CZ> I sort of expected both __set and __get to be called. Is it
CZ> concievable to have them both called?
CZ> The other alternative If possible, is allowing a return value
CZ> from __set() and using that value for the rest of the expression.
CZ> Curt
CZ> --
CZ> First, let me assure you that this is not one of those shady pyramid schemes
CZ> you've been hearing about. No, sir. Our model is the trapezoid!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Spammer on Bugs page
Hello, Perhaps we should implement one of the "read this obscure image and type the number into this text box" scheme into all the bug post and update forms? -- Best regards, Jasonmailto:[EMAIL PROTECTED] Tuesday, July 20, 2004, 11:57:25 AM, you wrote: US> There is some spammer on the bugs page who updates all bugs and adds a new US> comment to every bug with a URL to a porn page. What can we do? My mailbox US> gets fuller and fuller... US> - US> Uwe Schindler US> [EMAIL PROTECTED] - http://www.php.net US> NSAPI SAPI developer US> Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_intersect_key
Hello Cristiano,
First, I'd like to say that a function of this type sounds useful.
It's one that I've wanted for some time, particularly for verifying
that an array has the correct keys when it is passed as a function
parameter.
If I understand what you are doing correctly, the same thing can be
accomplished by:
array_intersect(array_keys($records), array(234, 567, 890, 123))
However, I agree that array_diff_key() and array_intersect_key()
would be significantly useful functions to add to the core.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Tuesday, July 20, 2004, 3:16:20 PM, you wrote:
CD> Hi all,
CD> I needed to intersect an array with database records indexed by the primary
CD> key, with an array with keys and there is no php function that will do it
CD> internally.
CD> The database array looks like:
CD> $records = array ( 2587 => array('Name', 'Address', 'zip'), ...);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
Hello,
After thinking about it for a bit, I'm convinced. If goto can be
implemented so that it is fast, and does not adversely affect other
parts of PHP, by all means, do it.
Andrey, you've been very clear why you would not use it, but why do
you want me not to use it? I can think of quite a few times when it
would have made my code much cleaner.
As far as shooting yourself in the foot, how about:
mysql_query("SELECT x,y,z FROM t WHERE id=" . $_GET['id']);
or
include($_GET['header_file']);
or
shell_exec('somecommand ' . $_POST['param']);
There are PLENTY of way's to shoot yourself in the foot with any
language. If joe shoots himself in his foot, does that mean that
I should not be allowed to shoot at all?
+1
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
Hello,
I think we should add an INI option:
php_newbie true|false
;)
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Thursday, July 29, 2004, 8:54:34 PM, you wrote:
AH> Sara Golemon wrote:
>>>do {
>>> .code...
>>> if (something) break;
>>> ...code
>>>} while (0);
>>>...cleanup code...
>>>
>>
>> Are you suggesting a hack is better than the real thing?
>>
>> -Sara
AH> The "hack" is working. The manual says :
AH> " Advanced C users may be familiar with a different usage of the do..while loop,
AH> to allow stopping execution in the middle of code blocks, by encapsulating them
AH> with do..while (0), and using the break statement. The following code fragment
AH> demonstrates this:" (a similar code follows)
AH> " Don't worry if you don't understand this right away or at all. You can code
scripts
AH> and even powerful scripts without using this 'feature'. "
AH> (the manual states that people can code powerful things without goto hack).
AH> Sara, if you need to have the goto, you know how to implement it with do..while.
AH> The average Joe may not need goto in some case but he will find that it simplifies
AH> his job (but making code clumsy, something what he does not realize).
AH> It is not because I don't like the power of goto, I would like not to be given in
the
AH> hands of the newbie.
AH> andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
PG> [snip] i'm somewhat confuzzled why you, of all people, are advocating such PG> mutilation of do-while(), which is *abuse* of the construct. mutilating one PG> construct to emulate another construct, which won't be implemented because PG> it could be abused and mutilated, just doesn't compute for me. I must say that this is my line of thought also... PG> i am onboard with the no-goto-out-of-local-scope argument, which the PG> do-while() kludge imposes as well. no reason this limitation can not be PG> implemented, if it isn't already (it is afair), in the patch. I say restrict it to local scope. Perhaps this borders on opinion, but the mere thought of chasing a goto into other files and functions and classes - blah. It seems that it would make it easier and faster to do at least several common operations within local scope. When all you want to do is move the execution pointer to a specific place in the LOCAL scope, it really beats wacked out loops and multi level break's. I say give the programmers the choice of what to use, and make it a personal mission to "spread the good news" about proper coding methodologies to the very large and less experienced group of php users out there. Hey, I got a good idea... Let's just implement it and not put it in the manual. Then only the "privileged internals list members" will know about it!:) Just kidding. ~Jason -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
Hello Andi, Sorry for being unclear on this, but what is the exact definition of an "execution block" in this context? Thanks! -- Best regards, Jasonmailto:[EMAIL PROTECTED] Friday, July 30, 2004, 9:08:09 PM, you wrote: AG> Hi Jason, AG> I think that in any case, if it is implemented it will have to follow two AG> basic rules: AG> a) The goto has to be local. AG> b) You can't jump into an execution block but only out of one. AG> Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
Hello Andi, That being said, I TOTALLY agree with your 2 rules. Thanks. Also, by limiting it to local scope and not being able to jump into an execution block would limit it's ability to make really nasty spaghetti code -AND- in my understanding provide the desired "professional" functionality as well. Thanks for answering my question. -- Best regards, Jasonmailto:[EMAIL PROTECTED] Friday, July 30, 2004, 9:24:13 PM, you wrote: AG> At 09:19 PM 7/30/2004 -0400, Robert Cummings wrote: >>On Fri, 2004-07-30 at 21:16, Jason Garber wrote: >> > Hello Andi, >> > >> > Sorry for being unclear on this, but what is the exact definition of >> > an "execution block" in this context? >> >>Can't jump into an "if" block or "while" block etc. Only out. AG> Yep exactly. Other examples are switch(), foreach() etc... AG> Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Date Support
Hello internals, Not to take away from the wonderful and lively "GOTO" discussion, but... I've got a couple simple questions. 1. Is there a particular reason that PHP does not have a really good set of functions for dealing with true date and time types (i.e. not timestamps)? 2. I think that good date and time handling in PHP would be a large plus. MySQL provides, imho, a very effective set of tools for handling dates. I think that this style of date handling, where the standard format was -MM-DD HH:MM:SS would be an ideal way to go. Comments? 3. If there is no good reason for not adding this set of functions to the PHP core, what would be the method of designing an acceptable set of functions? PHP is a feature packed language, but it's strange that this does not exist in the core. Thanks for your time. -- Best regards, Jason Garber mailto:[EMAIL PROTECTED] IonZoft, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Date Support
Hello Wez, I must be missing something... I went to the link and couldn't find any documentation. I downloaded it and all the .tgz contained were a couple of .php scripts? -- Best regards, Jasonmailto:[EMAIL PROTECTED] Monday, August 2, 2004, 10:41:09 PM, you wrote: WF> http://pecl.php.net/package-info.php?package=Date WF> It's not in the core because it is still relatively young. WF> Maybe in a future release... WF> --Wez. WF> On Mon, 2 Aug 2004 22:36:14 -0400, Jason Garber <[EMAIL PROTECTED]> wrote: >> Hello internals, >> >> Not to take away from the wonderful and lively "GOTO" discussion, >> but... I've got a couple simple questions. >> >> 1. Is there a particular reason that PHP does not have a really good >> set of functions for dealing with true date and time types (i.e. not >> timestamps)? >> >> 2. I think that good date and time handling in PHP would be a >> large plus. MySQL provides, imho, a very effective set of tools for >> handling dates. I think that this style of date handling, where the >> standard format was -MM-DD HH:MM:SS would be an ideal way to go. >> Comments? >> >> 3. If there is no good reason for not adding this set of functions >> to the PHP core, what would be the method of designing an acceptable >> set of functions? >> >> PHP is a feature packed language, but it's strange that this does not >> exist in the core. Thanks for your time. >> >> -- >> Best regards, >> Jason Garber mailto:[EMAIL PROTECTED] >> IonZoft, Inc. >> >> -- >> 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] Date Support
Hello George,
Because they both operate on an integer timestamp...
two things:
SELECT CURDATE() + INTERVAL 7 MONTH;
echo strtotime("7/12/1900");
Timestamps are fine for things that are happening within a very limited
range of dates. How do you add a given number of months to a date?
how do you get the day of week for a given date? These are the
types of functions that I am thinking of.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Monday, August 2, 2004, 10:40:45 PM, you wrote:
GS> On Aug 2, 2004, at 10:36 PM, Jason Garber wrote:
>> Hello internals,
>>
>> Not to take away from the wonderful and lively "GOTO" discussion,
>> but... I've got a couple simple questions.
GS> What's insufficient in strtotime() and strftime()?
GS> George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
Hello,
ALthough I'm in support of a local scoped static GOTO, I did not see
myself using it much.
However, I find myself this afternoon implementing a huge
do { switch { case: break 2; } while (true) structure.
It would be much "cleaner" to use goto in this case.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Protected methods in interfaces
Hello Marcus,
Can abstract methods be protected?
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Thursday, August 5, 2004, 1:32:05 PM, you wrote:
MB> Hello Ferdinand,
MB> Thursday, August 5, 2004, 5:01:42 PM, you wrote:
>> Trying to write a singleton interface:
>> interface Singleton {
>> // Disallow public construction
>> protected function __construct();
>> public static function getInstance();
>> }
>> I got an error saying I was not allowed to declare the constructor
>> protected - I should either use public or omit it.
>> Why can't I instruct Singleton-classes to use protected constructors?
>> Is this expected behavior or may I file a bug report?
MB> All interface methods must be public - that's the point behind interfaces.
MB> regards
MB> marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Modulo Function returns incorrect results
Hello Matthew, 3/4 = (0*4)+3 --> 3%4 = 3 9/4 = (2*4)+1 --> 9%4 = 1 20/10 = (2*10)+0 --> 20%10 = 0 4 goes into 3 a total of ZERO times with a remainder of 3. 10 goes into 20 a total of TWO times with a remainder of 0. Take a look at a standard (integer) long division problem with remainders. -- Best regards, Jasonmailto:[EMAIL PROTECTED] Thursday, August 5, 2004, 9:02:04 PM, you wrote: MB> Found some weird behavior in the built in mod function (%): MB> $a = 4; MB> $b = 3; MB> print ( $a % $b ); (returns 1 as it should) MB> Now swap $a and $b: MB> $a = 3; MB> $b = 4; MB> print ( $a % $b ); MB> This returns 3. 3?! 3/4 is 0.75. Shouldn't this return 0? MB> Try this one: MB> $a = 20; MB> $b = 10; MB> print ( $a % $b ); MB> Shouldn't that return 2? It returns 0; MB> $a = 11; MB> $b = 21; MB> print ( $a % $b ); MB> Returns 11. What is going on? Was my C.S. Professor wrong in telling us MB> that the % function returns the left side of the decimal in a division? MB> This is PHP 4.3.4 MB> Any help would be appreciated. MB> Thanks, MB> Matthew MB> -- MB> MB> Matthew Boehm MB> [EMAIL PROTECTED] MB> The University of Texas at Austin, Department of Geography MB> "Why did the prison use Windows2K as a guard? Because it always locks up!" MB> MB> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method/Function chaining?
Hello Dan,
The answer that you are looking for can be found on the Zend site:
http://www.zend.com/php5/articles/engine2-php5-changes.php#Heading13
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Friday, August 13, 2004, 6:59:44 PM, you wrote:
DO> Hello.
DO> Excuse my ignorance on this, but I can't seem to find the answer I'm
DO> looking for online... Will PHP5 be able to do "chaining" as some other
DO> languages are able to do?
DO> In other words...
DO> --
DO> class A
DO> {
DO> function A() { print "made an A...\n"; }
DO> function getB() { return new B(); }
DO> }
DO> class B
DO> {
DO> function B() { print "made a B...\n"; }
DO> function shout() { print "hey!!"; }
DO> }
DO> $a = &new A();
$a->>getB()->shout();
?>>
DO>
DO> This kind of polymorphism is something I'm used to, and I'm hoping it
DO> won't result in a parse error in PHP5. =)
DO> --
DO> Dan Ostrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: setcookie() and Max-Age
Hello, +1 on the array parameter. It's flexible, easy to document (as dan put it), and should accommodate future options. Also, throwing E_NOTICES would be good to notify you if you mis-type something, and they can always be suppressed if you want to send an "unsupported" option. -- Best regards, Jasonmailto:[EMAIL PROTECTED] DC> bool SetCookie( string $name, [string $value], [array $options]) DC> The $options array is an associative array which can contain DC> any combination of the following elements: DC> Max-Age integer blah blah DC> Comment string blah blah DC> etc... DC> Then provide a usage example. DC> --Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process
Hello Zeev, Makes sense to me. -- Best regards, Jasonmailto:[EMAIL PROTECTED] Friday, August 27, 2004, 3:26:25 AM, you wrote: ZS> I would like to get some feedback about my suggestion to move away from the ZS> simple 'experimental' status and dividing it into two - quality rating, and ZS> 'API subject to change' tagging. Does this make sense to anybody else? ZS> Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] #29416 - ob_include
Hello Stuart, Patch didn't come through... -- Best regards, Jasonmailto:[EMAIL PROTECTED] Wednesday, September 1, 2004, 3:50:30 PM, you wrote: SD> Hi All, SD> This is my first attempt at submitting a patch so please be gentle :). SD> The feature requested in #29416 is something I've wanted to see for a SD> while, so I decided to have a go at adding it. SD> I decided name ob_include described the method by which the function SD> did it's job rather than what it was for. I have implemented it as SD> eval_file_get_output which I feel is a better description of its SD> purpose. The requester suggests require and _once variations but those SD> make little sense to me so I haven't implemented those. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unserialize() data from untrusted source
Hello Harry, This is an interesting point you bring up. When we have large registration processes or similar multi-page forms, we write our data array to a hidden field using. base64_encode(serialize($aData)) and read it in with unserialize(base64_decode($_POST['aData'])) passing it from page to page with POST. If I understand you correctly, someone could alter the content of the serialized array so that it would load a class upon unserialization? If you are auto-loading classes, this might be even worse. That being the case, I would be much in favor of an optional second array parameter to unserialize that would be a list of accepted classes, or an empty array to that would (obviously) allow no classes (if you were working with simple data types). mixed unserialize ( string str[, array classes]) I'd be interested to hear other comment on this. -- Best regards, Jasonmailto:[EMAIL PROTECTED] Sunday, September 5, 2004, 11:29:53 AM, you wrote: HF> Hi All, HF> Have a situation where I want to unserialize a string received from an HF> untrusted source over HTTP (a Javascript client in this case). For HF> basic types this is no concern but when it comes to objects, would be HF> nice to be able to restrict the class of object to a member of a known HF> list, to prevent "unplanned objects" being created from classes which HF> happened to be defined but were not intended for unserialization (such HF> as the growing number pre-loaded classes in PHP5), and the possible HF> security issues that might introduce. HF> Checking the type of class once the object has been created might be HF> too late, depending on what the constructor does. That leaves manually HF> parsing the serialized string in PHP, before called unserialize, as HF> the only really safe option. HF> Could be this is outside of the scope of intended use of unserialize() HF> but PHP's serialized representation of data makes a pretty nice HF> encoding for exchange with other systems and I notice others doing the HF> same e.g.; HF> http://www.aagh.net/projects/ruby-php-serialize HF> http://hcs.harvard.edu/~pli/code/serialPHP.pm HF> http://www.cpan.org/modules/by-module/PHP/JBROWN/php-serialization/ HF> http://hurring.com/code/perl/serialize/ HF> Serialized data is also often used with sessions which means the usual HF> issues with shared hosts and session files (OK - smarter users avoid HF> this but...) HF> Perhaps unserialize could take a second (optional) argument which is a HF> list of allowed classes to validate against. HF> Many thanks, HF> Harry -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unserialize() data from untrusted source
Hello Markus, I've done both many times. There are many ways to do this type of thing, but the way I described it is very clean because the data is always in sync with the page (due to the fact that the data is on the page). If you save the data to a session, and then click back a couple times, it can really mess with things, creating a much more complex scenario to deal with. As I said, over the years I've done both, and this is what I've settled on as the most practical. -- Best regards, Jasonmailto:[EMAIL PROTECTED] Monday, September 6, 2004, 1:28:22 AM, you wrote: MF> Jason Garber wrote: >> This is an interesting point you bring up. When we have large >> registration processes or similar multi-page forms, we write our >> data array to a hidden field using. >> >> base64_encode(serialize($aData)) >> >> and read it in with >> >> unserialize(base64_decode($_POST['aData'])) >> >> passing it from page to page with POST. MF> I fail to understand, in your scenario, why you don't simply save the MF> data in a session? MF> You're effectively generated some data server and send it to the client MF> only to get it back on the next request; typical session scenario, if MF> you ask me. MF> cheers, MF> - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] Zend/zend_objects_API.c - bug #29980 (segfault while executing __destruct())
Hello Antony, Maybe this was assumed, but wouldn't this be a per-request flag, rather than a global flag? -- Best regards, Jasonmailto:[EMAIL PROTECTED] Tuesday, September 14, 2004, 10:18:29 AM, you wrote: AD> Sounds nice: we should not call destructors after they were already called =) AD> I could propose a simple solution: add a global flag, which will indicate AD> that shutdown_destructors() was called, and do appropriate check in AD> zend_objects_store_del_ref(). AD> Comments/objections? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Bug #30230 exception handler not working with objects
Hello Andi, reset_exception_handler() :) -- Best regards, Jasonmailto:[EMAIL PROTECTED] Tuesday, October 12, 2004, 5:40:34 PM, you wrote: AG> I see Marcus has already attempted to fix this even though the bug report AG> is still open. AG> Marcus, what exactly did you do? It seems you allow only NULL to reset AG> exception handler and not empty string. Right? AG> So it seems like you agree with me that "" is ugly but the question is if AG> we're breaking something now. AG> It's probably early enough in the game to do so. AG> Andi AG> At 11:44 PM 10/11/2004 -0700, Robert Silva wrote: >>The problem is that set_exception_handler allows you to reset the handler by >>passing an empty string as argument. It did not check to make sure it was a >>string before checking strlen, therefore when passed an array, it assumed >>the user was resetting the handler. This patch only resets when an empty >>string is passed in (an array will set a new handler). >> >>Bob Silva >> >> >>-- >>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] CLI Constant
Hello internals,
What is the best way, from within a php script, to tell that the
script is being run on the command line?
I've used if(defined('STDIN')) but that seems kind of kludgey.
If there is no better way, perhaps we could add constant called
(SAPI_TYPE = 'CLI') or something like that to the language to
facilitate this?
--
Best regards,
Jason Garber mailto:[EMAIL PROTECTED]
IonZoft, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI Constant
Hello Marcus,
Ok, Ok. I admit it.
I made the POINT of reading the CLI manual page before posting this,
but I just missed it.
Sorry for the trouble, and, thanks for the help.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Thursday, September 30, 2004, 5:50:34 PM, you wrote:
MB> Hello Jason,
MB> you lazy doc reader :-)
MB> php -r 'var_dump(php_sapi_name());'
MB> best regards
MB> marcus
MB> Thursday, September 30, 2004, 11:10:01 PM, you wrote:
>> Hello internals,
>> What is the best way, from within a php script, to tell that the
>> script is being run on the command line?
>> I've used if(defined('STDIN')) but that seems kind of kludgey.
>> If there is no better way, perhaps we could add constant called
>> (SAPI_TYPE = 'CLI') or something like that to the language to
>> facilitate this?
>> --
>> Best regards,
>> Jason Garber mailto:[EMAIL PROTECTED]
>> IonZoft, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Small addition to Apache 1.3.x
Hello Manuel, After reading your motivations, it seems to me that you need mod rewrite. from: http://httpd.apache.org/docs/mod/mod_rewrite.html "Welcome to mod_rewrite, the Swiss Army Knife of URL manipulation! This module uses a rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly. It supports an unlimited number of rules and an unlimited number of attached rule conditions for each rule to provide a really flexible and powerful URL manipulation mechanism. The URL manipulations can depend on various tests, for instance server variables, environment variables, HTTP headers, time stamps and even external database lookups in various formats can be used to achieve a really granular URL matching. This module operates on the full URLs (including the path-info part) both in per-server context (httpd.conf) and per-directory context (.htaccess) and can even generate query-string parts on result. The rewritten result can lead to internal sub-processing, external request redirection or even to an internal proxy throughput." Check it out. -- Best regards, Jasonmailto:[EMAIL PROTECTED] Wednesday, October 6, 2004, 9:45:23 PM, you wrote: MVA> Hi internals: MVA> I made an addition to Apache 1.3.x SAPI; and I would like you to take a look MVA> at it, so you can evaluate if it has a chance to go official. MVA> Basically, the new feature lets Apache users to set a PHP Script Handler, MVA> this is, for each request made to the server the PHP Script Handler is MVA> execute, the only necessary configuration stuff looks like this: MVA> MVA> ... classical stuff ... MVA> php_sethandler /path/to/handler.php MVA> SetHandler application/x-httpd-php MVA> MVA> I made patches for both PHP 4.3.8 and 4.3.9, they are in: MVA> http://www.chasqui.cu/staff/manu/2004/php-4.3.8-m3.patch.bz2 MVA> http://www.chasqui.cu/staff/manu/2004/php-4.3.9-m3.patch.bz2 MVA> (A list of few motivations for this add is in MVA> http://www.chasqui.cu/staff/manu/2004/apache.sapi.motivations.txt) MVA> I have tested both patches only on a Linux (LFS 5.1.1) with Apache 1.3.31. MVA> Some things I have not done yet: MVA> 1. Currently, I'm not making any checks for the PHP Script Handler file to MVA> exists. I will. MVA> 2. I have not modified the config.m4, I'm not familiar with M4, so I need to MVA> read some docs before I can do it. MVA> 3. I have not tested the DISABLE_SCRIPT_HANDLER branch yet, this is, compile MVA> with -DDISABLE_SCRIPT_HANDLER in order not to include the new feature. MVA> I would like to receive feedback on this. I'm very new to C coding, and I MVA> would like some of you to test it. Please don't let me holding on. MVA> Regards, MVA> Manu. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] switch() and default:
Hello, Ergh. I also hope that it can easily be restored to work the way it did, even if that was undocumented. The thought of looking through ~ 5,000 php scripts before our upgrade is a bit overwhelming :) -- Best regards, Jasonmailto:[EMAIL PROTECTED] Friday, October 8, 2004, 11:52:54 AM, you wrote: AG> I will look into the reason this seems to have changed. AG> However, I can assure you that from day 1 this was not supposed to work AG> and was documented as such for years already (since the days of PHP 3). If AG> it worked at some point then it was by chance! AG> Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hints with null default values
Hello, Consider this: public function foo(MyClass $o) If you allow null, false, or anything else, you must CHECK it before using it or you will get a "calling a method on a non-object" first. The whole point of having a type hint, from my point of view, is so the majority of time I DO NOT have to check the incoming parameter before using it. If nulls or false's are allowed, without explicitly saying they are, such as function foo(nullable MyClass $o), then I'll have to either do an is_null() or instanceof check on each parameter. I'm all for it if we have an option added to the function syntax such as nullable, but otherwise, it's usefulness is minimized. -- Best regards, Jasonmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: isset() and the new VM
>> isset($arr[0]['id']) used to return false if $arr[0] is undefined, but >> with the new VM it throws a warning. Doesn't sound right to me either... -- Best regards, Jasonmailto:[EMAIL PROTECTED] SG> I'd call it bugish, since part of the point of isset() is that it's never SG> supposed to throw notices on undefined vars/indices. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] SimpleXML marked as EXPERIMENTAL
Hello Rasmus, It seems that it should be marked as a depreciated feature IN PHP5, but not excremental in PHP4. This would let everyone know what the real deal is... -- Best regards, Jasonmailto:[EMAIL PROTECTED] Thursday, December 2, 2004, 12:04:41 PM, you wrote: RL> On Thu, 2 Dec 2004, Philip Olson wrote: >> > > As long as we are in "dropping EXPERIMENTAL Mode": >> > > Shouldn't we drop EXPERIMENTAL from php4 domxml living in PECL? >> > > AFAIRC once Cgristian Stocker said, it is stable, obviously no API >> > > changes will happen etc. >> > > Any reason not to drop EXPERIMENTAL from docs and pecl source for domxml? >> > >> > Please don't drop it there because that would sooner or later mean that >> > people will start using it a lot. The idea was to drop domxml once we >> > have dom - we have dom now. >> >> Experimental is not a synonym for Deprecated. It sounds >> like DomXML is deprecated and not experimental. RL> Since dom is only for php5 we can't deprecate domxml in php4 without RL> deprecating all of php4 which would be a bad idea. RL> -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Isset question
Hello internals, If anyone has a moment to answer this, it'd be appreciated... -- isset($x); => false is_null($x) => Notice: undefined variable $x -- $x = null; isset($x); => false is_null($x) => true The question is *why* does isset() report false on a variable that is set to NULL? Is there any way to tell if a variable isset and is_null without generating an error? It doesn't seem that this behavior is consistent with the meaning of isset(), or the errors that are generated when a variable is not set. Thanks. -- Best regards, Jason Garber mailto:[EMAIL PROTECTED] IonZoft, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Hello Andi, >>However i'd like to see the 'ifsetor' or '?:' operator since it makes >>many things much faster and easier to read. AG> I am not sure if the security filter functions aren't enough because they AG> will be used to gather and verify input which is the main purpose of ifsetor. AG> Also, we never found a great implementation but that's another story :) ifsetor() has many uses other than input filtering although it is one of the main uses. ifsetor($var, default) is the very clean, simple syntax that I think should be used. I do not believe that input filtering should be built into ifsetor. Thanks. PS (The name, as long as it's fairly short, is not important to me at all) -- Best regards, Jasonmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Before March 1st aka PHP 5.1 beta
Hello Andi, >>4) php 5.1 is aiming to increase performance and security => ifsetor >> >> It is nice and easy and fast...only it's name. Well guys come on that's >> the stupiest reason to reject. The name is selfspeaking, you're all only >> not so used to its name as you are with foreach for now. AG> It wasn't only the name but also the implementation. Actually, I was hoping AG> that the input filter API would resolve this issue once and for all even if AG> in a bit of a different (and IMO better) way. Input filtering does not solve the problem ifsetor() is designed to solve. It tackles a small part of it, but ifsetor() is a general purpose construct that is used for $_GET, $_POST, as well as ANY OTHER array element or variable in your script. $x = ifsetor($somearray[$foo][$bar], 0); Is a lot cleaner than: $x = isset($somearray[$foo][$bar]) ? $somearray[$foo][$bar] : 0; -- ifsetor()'s purpose is simple and clear: To return a variable value if it exists or a default value if it does not exist WITHOUT generating any error. Thanks. -- Best regards, Jasonmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Before March 1st aka PHP 5.1 beta
Hello, Speaking of these matters, how about implementing functions within interfaces? -- Best regards, Jasonmailto:[EMAIL PROTECTED] Thursday, February 17, 2005, 5:46:08 PM, you wrote: RK> Okay, I'll accept the "no" of course, but I am curious.. Is it an RK> implementation problem with the current engine? Saying that using interfaces RK> discards the MI issue is nonsense imho, because I can't implement any RK> functions in an interface. RK> So why is this such a big "no"? Implementation problem or is it against a RK> certain PHP philosophy? RK> Ron RK> "Marcus Boerger" <[EMAIL PROTECTED]> wrote in message RK> news:[EMAIL PROTECTED] >> Hello Ron, >> >> Thursday, February 17, 2005, 11:10:55 PM, you wrote: >> >> > A little offtopic, but I'm still curious.. is multiple inheritence RK> something >> > we might see appearing in 5.2 ? >> >> Definitively not. >> You may raise this question prior to PHP 6, >> However still getting the answer 'no'. >> The concept simply doesn't match with PHP >> and since we have multiple inheritance for >> interfaces that's enough. >> >> Best regards, >> Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Construct Request
Hello Internals team,
Thank you for taking a moment to evaluate a serious request by a serious
php developer that is responsible for a development company of 15 employees.
In order to keep our code as clean and error free as possible, we opt to
develop in the E_ALL error mode, and register_globals = off. This comes
with several challenges that one does not normally encounter.
We define and cast incoming script data variables at the top of each script,
so they are always defined and contain a valid value. Before E_ALL was
used, the form of this was:
$nCustID = (integer) $_POST['nCustID'];
and from that point on, the variables $nCustID and $sName would be used.
However when we started using E_ALL, these lines of code would throw
E_NOTICE level errors when the variable did not exist in the $_POST array.
So now, we use the form:
$nCustID = (integer) (isset($_POST['nCustID']) ? $_POST['nCustID'] : 0));
I know that writing a line like the following would be a solution, but when
evaluated closely, it is a very slow and clumsy one, especially if you are
using a custom error handler.
@ $nCustID = (integer) $_POST['nCustID'];
There is nothing wrong with writing lines of code like
$nCustID = (integer) (isset($_POST['nCustID']) ? $_POST['nCustID'] : 0));
everywhere, but it does tend to make the code very messy.
The feature that I am proposing is a language construct, and therefore would
need integrated into the ZEND engine. It is very simple, and would be
modeled after isset().
Function:
setor(arg1, arg2) -- if parameter 1 is set, then return it, else evaluate
and return parameter 2.
Example:
$nCustID = (integer) setor($_POST['nCustID'], 0);
I would imagine that the ( ? : ) operator only evaluates the second or third
argument if they are actually used, and the setor() function should behave
the same. Therefore, it would allow for expressions such as:
echo setor($required_variable, die('error...');
or
echo setor($error, '');
or
echo setor($sMessage, $sDefaultMessage).
or
$z = setor($_GET['z'], 'Default');
As you can see, it would reduce and un-duplicate quite a bit of code, making
PHP an even more easy to use language. Please evaluate this request
carefully, and then let me know your thoughts on it.
Sincerely,
Jason Garber
President and Chief Technology Officer
IonZoft, Inc. :: 814.742.8030
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Construct Request
At 4/15/2004 11:28 AM -0400, Justin Hannus wrote:
> echo setor($required_variable, die('error...');
> or
> echo setor($error, '');
> or
> echo setor($sMessage, $sDefaultMessage).
> or
> $z = setor($_GET['z'], 'Default');
> $z = setor($_GET['z'], 'Default');
Whats wrong with defining a user-level function?
function setor_array(&$array, $key, $default = 0)
{
return isset($array[$key']) ? $array[$key] : $default;
}
$nCustID = (int) setor_array($_GET, 'nCustID', 0);
My issue with defining a user level function is:
a. the actual variable in question could not be passed
b. it incurs the overhead of calling a user-level function
I do admit that this may be a plausible solution for the majority of my
examples in initializing the incoming script variables, but does not
address the general problem of developing with E_NOTICE turned on - for
instance, accessing globals or deep arrays that may or may not exist.
It is one of the great features of PHP - accessing an undefined variable,
but one that is completely removed when E_NOTICE is turned on.
What is the overhead of calling a simple UDF in php?
~Jason Garber
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Construct Request
The best functionality would be for it to return the value, not re-assign it. Many of the things being talked about would modify the sent parameter, rather than return selected value. For instance (using the isset_or_default()) call: $nCustID = (int) isset_or_default($_POST['CUST_ID'], 0); That would give the developer flexibility on how he used it, and could reassign it to the $_POST array if he wanted to. $_POST['CUST_ID'] = (int) isset_or_default($_POST['CUST_ID'], 0); I agree that it would be helpful not to evaluate the second parameter unless needed, which is why I originally proposed a language construct. Also, I think that using an operator would add to the complexity of thoroughly understanding the PHP language, which is something that I understand we do not want to do. ~Jason Garber At 4/15/2004 02:34 PM -0400, Ilia Alshanetsky wrote: On April 15, 2004 02:15 pm, Andi Gutmans wrote: > It could be implemented but I don't see the big advantage over $bar ? 0 : > $base It's one character... Well, currently to check the value and assign the default you need to do the following: $_GET['foo'] = isset($_GET['foo']) ? (int) $_GET['foo'] : 0; Which can get quite annoying if you need to repeat that many times and it's just easier to disable notices and do $_GET['foo'] = (int) $_GET['foo']; I think if anyone of the following would work it would be quite convenient isset_or_default($_GET['foo'], 0); /* if $_GET['foo'] is set leave as is, otherwise assign 0 to it */ $_GET['foo'] = isset_or_default($_GET['foo'], 0); /* same as above, but the variable is not passed by reference */ isset($_GET['foo']) ? : 0; /* Sascha's proposal */ Ilia -- 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] Construct Request
Hi Derick,
I see. I was basing the spec on the functionality of isset() which does
not (obviously) throw an E_NOTICE when you pass an undefined variable to
it. However, do you see any reason that this would not reliably work?
function setor(&$param, $default)
{
return (isset($param) ? $param : $default);
}
I tested it on 4.3.4 and 5.0 RC1, and it worked. Is passing an undefined
variable as a reference parameter a legal thing to do in PHP?
~Jason
At 4/15/2004 09:54 PM +0200, Derick Rethans wrote:
On Thu, 15 Apr 2004, Jason Garber wrote:
> $_POST['CUST_ID'] = (int) isset_or_default($_POST['CUST_ID'], 0);
>
> I agree that it would be helpful not to evaluate the second parameter
> unless needed, which is why I originally proposed a language construct.
You'll need something more clever, because an undefined
key 'CUST_ID' in $_POST['CUST_ID'] will strill throw a warning, even if
you pass it to a language construct. Changing that behavior is not
trivial.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Construct Request
I wrote this (I underlined the relevant parts for you):
> >You'll need something more clever, because
> >an undefined key 'CUST_ID' in $_POST['CUST_ID'] will strill throw a
Consider this:
---
error_reporting(E_ALL);
function setor(&$param, $default)
{
return (isset($param) ? $param : $default);
}
$x = setor($x, 10);///Should Produce an E_NOTICE
echo gettype($x) . ':' . $x . "\n";
?>
---
This DOES NOT produce an E_NOTICE like you said (notice the &). However,
$param1 is defined and NULL inside the function, even though $x was not a
defined variable outside the function??
~Jason
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
