I have recenlty posted on this topic but got no response, probably because
I didn't phrase it well.
I would like to implement this proposed feature if I can get some feedback
to know if it would be accepted for inclusion.
Here is the proposal:
* Add a '-M' option to sapi/cli/php that would
Ok, this was my mistake in missing the Ternary operator enhancement
for fluent code
(http://marc.theaimsgroup.com/?t=9622016834r=1w=2) discussion
thread from last year in the archives. It was not my intention to
reopen a dead thread. I did make best effort to do prior research in
the
My apologies if this has been brought up before, but I searched the
archives and couldn't find a reference to it.
I'm sure this is the sort of thing that would have already been
implemented if there was any desire for it among the developers, but I
was wondering if anyone had considered adding
On Sun, Jan 12, 2003 at 12:53:12PM -0600, Michael Sims wrote:
My apologies if this has been brought up before, but I searched the
archives and couldn't find a reference to it.
I'm sure this is the sort of thing that would have already been
implemented if there was any desire for it among
On Sun, 2003-01-12 at 20:47, Sara Golemon wrote:
[...]
This has been discussed (recently in fact) and won't be done. However,
you *can* give your code the type of readability you're looking for with:
($condition) || {
/* This will only run if $condition evals to false */
}
Nope, that
This has been discussed in the past and won't be done.
PHP behaves like C where the result of the boolean or operation is true
or false.
Andi
At 12:38 AM 1/11/2003 -0500, Nyk Cowham wrote:
As a convert from Perl one of the 'features' I miss from Perl is the
short-circuit behavior of the or
As a convert from Perl one of the 'features' I miss from Perl is the
short-circuit behavior of the or operand (||) and how it can be used to
set default values if a passed value is false (0 or ). Thus, in a
passed parameter you can write:
$result = $value || $default;
In perl if the $value
Hi,
I am curious what's is the opinion of the devs about adding new additional
parameter to gettype which won't be compulsory. Using it instead of
returning a string the function will return an int which. As an addition new
consts will be registered - something like IS_STRING, IS_LONG and so on.
Hello,
to make easier maintenance and checking possible I would suggest to name
our tests more appropriate:
Class: Name: Example:
Tests for bugs bugbugid.phptbug17123.phpt
Tests for functions functionname.phpt
+1
Moriyoshi
Derick Rethans [EMAIL PROTECTED] wrote:
Hello,
to make easier maintenance and checking possible I would suggest to name
our tests more appropriate:
Class: Name: Example:
Tests for bugs bugbugid.phptbug17123.phpt
On Fri, Oct 25, 2002 at 11:57:34AM +0200, Derick Rethans wrote:
to make easier maintenance and checking possible I would suggest to name
our tests more appropriate:
Class: Name: Example:
Tests for bugs bugbugid.phptbug17123.phpt
Some know I'm working to improve swig-php to make module generation easy and
satisfying.
The final hurdle remains in handling and generating callbacks from the
module to PHP. Or rather from the library the module wraps to PHP.
This requires some kind of callback wrapper that can convert from a
On Wed, 2002-04-10 at 22:58, Andi Gutmans wrote:
I still prefer to keep PHP a relatively easy to learn, simple yet powerful
language.
I think this is a huge overkill and prefer going with something like I
proposed.
Anyway the inheritance debates have been going on for years and I doubt
At 00:12 12/04/2002 +0200, Stig S. Bakken wrote:
* Dealing with possible loops:
class a aggregates b {}
class b aggregates a {}
$a = new a;
$a-unknown_method();
Should it be illegal to loop-aggregate classes, or should it be
detected at runtime? I'm not sure.
It can't really be detected but
On Fri, 2002-04-12 at 00:42, Andi Gutmans wrote:
At 00:12 12/04/2002 +0200, Stig S. Bakken wrote:
* Dealing with possible loops:
class a aggregates b {}
class b aggregates a {}
$a = new a;
$a-unknown_method();
Should it be illegal to loop-aggregate classes, or should it be
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit PHP
very nicely.
My main concern with MI is that there are many problems with it including
namespace
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit PHP
very nicely.
My main concern with MI is that
At 12:46 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit
--- Andi Gutmans [EMAIL PROTECTED] wrote:
At 12:46 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a
At 12:46 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit
BTW:
Have you looked at my patch to handle method calls differently?
Yes and I don't like it. I haven't had time to do timings yet. I was very
busy and will try and do it in the next few days.
hmm
The patch wasn't just for speed it was more for sloving 2 main problems.
class a
At 13:07 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
At 12:46 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on
aggregation vs.
MI
some thoughts concerning member name collisions:
(i will also demonstrate a common shortcoming that i personally
consider a design flaw that exists both in C++ and in Java - it sure
would be good to avoid the same flaw in PHP - even if MI doesn't
get into ZE2, keep this in mind for the
If you want to access an aggregated object directly you can do:
$obj-Timer-method();
well, that's exactly what shouldn't be done and what polymorphism
is trying to eliminate... consider a huge code library which operates
on an object of class Timer and that we want to reuse this library.
now
PHP isn't a compiled language and we aren't going to start adding casting,
v-tables and so on.
PHP is extremely loosely typed and doing $obj-foo calls the method foo
on $obj. This also allows for things like:
$blah = foo;
$obj-$blah;
and so on.
I really think that people who are looking for
On 10/04/02, Lauri Liinat [EMAIL PROTECTED] wrote:
big_hairy_library_call( (Timer) $MI_obj );
(insert_the_name_of_your_class_here) might be tricky to implement
in the ZE, but I agree with the principle, hence my suggestion
for:
big_hairy_library_call($MI_obj as Timer);
Same thing, slightly
On 10/04/02, Marcus Börger [EMAIL PROTECTED] wrote:
At 23:25 10.04.2002, Lauri Liinat wrote:
If you want to access an aggregated object directly you can do:
$obj-Timer-method();
big_hairy_library_call( (Timer) $MI_obj );
Where is the big difference (first is postfix syntax, second is
i'll try to answer both Marcus and Wez here:
Where is the big difference (first is postfix syntax, second is prefix syntax).
the difference is between whether you have to change *lots* of existing code
or do exactly *one* cast in new code while you write it:
$timer = (Timer) $MI_obj;
On 10/04/02, Lauri Liinat [EMAIL PROTECTED] wrote:
so, Wez - why would you want to introduce yet another
cast operator - the as keyword? while PHP already has
adopted the C-style (new_type)... operator?
Since we don't have a real type system, (type) casting doesn't
actually do what you were
where it goes in more details.
Fab.
- Original Message -
From: Lauri Liinat [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, April 10, 2002 6:15 PM
Subject: Re: [PHP-DEV] Proposal for aggregation vs. MI
i'll try to answer both Marcus and Wez here:
Where
The real IP address can be tracked in most cases (say, using the
HTTP_X_FORWARDED header an others) but I am not really sure that we
should put the logic for that in the PHP engine itself. Users can
add the additional PHP code to their libraries. Anyway, you can
change the
Ivan Ristic wrote:
Also, ISPs (like AOL) who use farms of proxy caches will change a users
apparent ip during a single session. (i.e. concurrent requests may come
from different ips).
The real IP address can be tracked in most cases (say, using the
HTTP_X_FORWARDED header an others)
Hi,
But unfortunately a dedicated server does not cost much more than virtual
hosting anymore (just have a look at http://powerraq.com/ ). PHP is
mostly pre-installed (with dev settings and not production settings -
many admins even forget to switch on safe_mode) and this lazyness
leads to
How about that we use the SERVER_NAME environment variable when
generating session filenames? Instead of name like sess_, the name
could be sess__, where is a server fingerprint? I
understand that this is not foolproof (say, for applications
that run on the
This will secure the default configuration and yet make things
work for people who want to use sessions over several domains.
But I admit that this improvement can be seen as meaningless
since any user on a shared server can write a script to list
all sessions in a directory and then
[PROBLEM]
Sessions can easily be taken over by other, malicious users. All you
need is the session-id and you're done.
User who have read-access to the directory where PHP stores it's
session-data, can read the ids directly from the filenames. I don't
think many administrators are aware of the
Bringing the user's ip into the mix is going to cause all sorts of hard to
track down problems as many many people do not have static ips. Having a
session break because their lease expires and they are assigned a new one
will confuse everyone.
As far as I am concerned this is a documentation
Also, ISPs (like AOL) who use farms of proxy caches will change a users
apparent ip during a single session. (i.e. concurrent requests may come
from different ips).
George
On Friday, February 1, 2002, at 11:58 AM, Rasmus Lerdorf wrote:
Bringing the user's ip into the mix is going to cause
Hi,
i fully support rasmus, saying that we should mention the default
configuration
as unsafe in the documentation.
Unlike Mr. Lorch or similiar people i do not think its our resposibility to
configure
the server for the admin. And i am a little bit tired about this whole
session
takeover
The only reason session data is stored in /tmp is that we want sessions to
work out of the box and /tmp is the only place we can be semi-sure that we
will have write access to. People who run large servers with multiple
sites that all use sessions should of course change the session directory
on
The general philosophy of PHP has always been to make PHP easy for the
beginner yet flexible enough for advanced users. This fits that rule.
Give the advanced users the tools to configure PHP to have per-virtualhost
session handling, while sessions still work for the guy who just installed
That is fine for a philosophy. I would still like to try to make
the default setup more secure. I agree, the least we can do is to
document this.
How about that we use the SERVER_NAME environment variable when
generating session filenames? Instead of name like sess_, the name
How about that we use the SERVER_NAME environment variable when
generating session filenames? Instead of name like sess_, the name
could be sess__, where is a server fingerprint? I
understand that this is not foolproof (say, for applications
that run on the same
Hi,
This topic was already discussed in bugtraq and there should also be an
entry in the PHP bug database about this:
http://www.securityfocus.com/archive/1/250196
http://www.securityfocus.com/archive/1/250593
i fully support rasmus, saying that we should mention the default
But unfortunately a dedicated server does not cost much more than virtual
hosting anymore (just have a look at http://powerraq.com/ ). PHP is
mostly pre-installed (with dev settings and not production settings -
many admins even forget to switch on safe_mode) and this lazyness
leads to
Why would you switch on safe_mode if you have a dedicated server? That
makes no sense.
It can be useful to minimise the damage in case someone finds a hole
in your PHP scripts, and the hole allows them to access files on
the server.
--
Ivan Ristic, [EMAIL PROTECTED]
[ Weblog on PHP,
based on something nasty i did with cookies a while back
Session id
[][bb]
eg. first 32? chars are the standard md5, the remainder is a variable
length key.
aaa - the standard session id. (eg. the filename)
bbb - an simple key overlay
say the session file contains
On Wed, Dec 12, 2001 at 04:58:27PM +0900, Yasuo Ohgaki wrote :
php_error(E_WARNING, %s expects size 0,
get_active_function_name(TSRMLS_C));
I prefer %s() ...
- Markus
--
Please always Cc to me when replying to me on the lists.
--
PHP Development Mailing List
Markus Fischer wrote:
On Wed, Dec 12, 2001 at 04:58:27PM +0900, Yasuo Ohgaki wrote :
php_error(E_WARNING, %s expects size 0,
get_active_function_name(TSRMLS_C));
I prefer %s() ...
It should be %s() ... :)
--
Yasuo Ohgaki
Hi all.
We need consistent error levels and handling for all modules. I suppose
all of us can agree with this.
[PROBLEM]
1) Use of error levels are not consistent. Some function returns error
status, yet displays/raises warning message for non faital errors. Other
function just returns error
I think we should be realistic about what we can and cannot pull. Using
this approach as the standard release process is simply not going to work -
we barely manage an RC branch and a dev branch properly, and having to
maintain an old release branch sync'd with bug fixes is not going to be
Andi Gutmans wrote:
At 01:36 AM 11/14/2001 +0100, Stig S. Bakken wrote:
I didn't quite understand what you mean :)
All I said was that if you create a branch say 4.1.0 and you want to
release 4.1.x from that branch later on whilst HEAD has already moved a
couple of months you're
Andi Gutmans wrote:
At 12:31 AM 11/11/2001 +0100, Stig S. Bakken wrote:
Andi Gutmans wrote:
Jani,
I think in theory what you writes makes sense but it just doesn't work in
the PHP project. (I'm talking about the minor versions coming out of
branches). There are always cries
At 01:36 AM 11/14/2001 +0100, Stig S. Bakken wrote:
I didn't quite understand what you mean :)
All I said was that if you create a branch say 4.1.0 and you want to
release 4.1.x from that branch later on whilst HEAD has already moved a
couple of months you're going to have a hard time
At 05:28 12/11/2001, Jani Taskinen wrote:
Zeev suggested at some point
that we should drop the last number altogether.
I *what*? Perhaps I was high on that Kossu :) I was never in favour of
dropping the 3rd digit.
That indeed would
make the current way of doing things more correct but
At 05:28 AM 11/12/2001 +0200, Jani Taskinen wrote:
On Sun, 11 Nov 2001, Andi Gutmans wrote:
I didn't quite understand what you mean :)
I didn't get it first either. :)
All I said was that if you create a branch say 4.1.0 and you want to
release 4.1.x from that branch later on whilst HEAD
Andi Gutmans wrote:
Jani,
I think in theory what you writes makes sense but it just doesn't work in
the PHP project. (I'm talking about the minor versions coming out of
branches). There are always cries to go with HEAD because it's got new
goodies (I think it often makes sense) and then
Jani Taskinen wrote:
On Sat, 10 Nov 2001, Zeev Suraski wrote:
Guys,
We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on
which 4.1.0 is currently scheduled to be based on, has branched away a few
months ago. Some people have expressed concern that releasing 4.1.0
At 12:31 AM 11/11/2001 +0100, Stig S. Bakken wrote:
Andi Gutmans wrote:
Jani,
I think in theory what you writes makes sense but it just doesn't work in
the PHP project. (I'm talking about the minor versions coming out of
branches). There are always cries to go with HEAD because it's
Guys,
I mentioned this in the conference. Version numbers aren't going to change
anything significant. If we're concerned about the users' perception of
what the version number means, moving to Jani's versioning scheme, I'm
pretty confident it'll mean less to more people. The reason being
On Sat, 10 Nov 2001, Zeev Suraski wrote:
Guys,
We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on
which 4.1.0 is currently scheduled to be based on, has branched away a few
months ago. Some people have expressed concern that releasing 4.1.0 based
on that branch is not a
Jani,
I think in theory what you writes makes sense but it just doesn't work in
the PHP project. (I'm talking about the minor versions coming out of
branches). There are always cries to go with HEAD because it's got new
goodies (I think it often makes sense) and then people don't want to
]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, November 10, 2001 4:34 PM
Subject: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)
On Sat, 10 Nov 2001, Zeev Suraski wrote:
Guys,
We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on
which 4.1.0
No compatibility issues but fixing two annoying safe-mode limitations?
Go ahead :-)
- Stig
Arcady Genkin wrote:
This refers to bug 18843 ( http://bugs.php.net/bug.php?id=13843 )
I'm willing to give a shot at coding the fix for this bug, provided
that the proposed resolutions (below)
UNSUBSCRIBE ME PLEASE!!
Rasmus Lerdorf schrieb:
The best thing about PHP is that it has such a shallow
learning curve that
non-programmers can write web apps.
The worst thing about PHP is that it has such a shallow learning curve
that non-programmers write web apps.
That is of course
UNSUBSCRIBE ME PLEASE!!
Heikki Korpela schrieb:
On Sat, 28 Jul 2001, Rasmus Lerdorf wrote:
> // And perhaps some globbing:
> // Import any variable with abc in
its name from anywhere.
> // Could alternatively use SQL-style
or perhaps real regex
> // expressions here although I think
UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
It's pretty close to what I had in mind:
At 22:17 28/07/2001, Rasmus Lerdorf wrote:
>The best thing about PHP is that it has such a shallow learning curve
that
>non-programmers can write web apps.
>
>The worst thing about PHP is that it
UNSUBSCRIBE ME PLEASE!!
Phil Driscoll schrieb:
On Sunday 29 July 2001 07:57, Zeev Suraski wrote:
> I'm against a global function like this, but in favour of the 2nd
flavour,
> where you have to explicitly pass a list of variable names to import.
I
> also think that it should only
UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
At 00:48 29/07/2001, Rasmus Lerdorf wrote:
> > I'm against a global function like this, but in favour of the 2nd
flavour,
> > where you have to explicitly pass a list of variable names to import.
>
>Actually, I mostly had something like:
UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
At 00:27 29/07/2001, Heikki Korpela wrote:
>On Sat, 28 Jul 2001, Rasmus Lerdorf wrote:
>
> > // And perhaps some globbing:
> > // Import any variable with abc in
its name from anywhere.
> > // Could alternatively use SQL-style
or perhaps
UNSUBSCRIBE ME PLEASE!!
Stephen van Egmond schrieb:
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
> How to get there...
>
> For 4.0.7:
>
> - We leave all default configuration settings as they are now.
> - We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps
make them
>
that all makes a lot of sense to me!
re,
tc
On Sat, Jul 28, 2001 at 10:17:42PM -0700, Rasmus Lerdorf wrote:
The best thing about PHP is that it has such a shallow learning
curve that
non-programmers can write web apps.
The worst thing about PHP is that it has such a shallow
It's pretty close to what I had in mind:
At 22:17 28/07/2001, Rasmus Lerdorf wrote:
The best thing about PHP is that it has such a shallow learning curve that
non-programmers can write web apps.
The worst thing about PHP is that it has such a shallow learning curve
that non-programmers write
On Sat, 28 Jul 2001, Rasmus Lerdorf wrote:
// And perhaps some globbing:
// Import any variable with abc in its name from anywhere.
// Could alternatively use SQL-style or perhaps real regex
// expressions here although I think full regex support would be
//
I'm against a global function like this, but in favour of the 2nd flavour,
where you have to explicitly pass a list of variable names to import.
Actually, I mostly had something like: import_globals(ES) in mind for
the import all variety. Importing all server and environment variables
when
At 00:48 29/07/2001, Rasmus Lerdorf wrote:
I'm against a global function like this, but in favour of the 2nd flavour,
where you have to explicitly pass a list of variable names to import.
Actually, I mostly had something like: import_globals(ES) in mind for
the import all variety. Importing
At 00:27 29/07/2001, Heikki Korpela wrote:
On Sat, 28 Jul 2001, Rasmus Lerdorf wrote:
// And perhaps some globbing:
// Import any variable with abc in its name from anywhere.
// Could alternatively use SQL-style or perhaps real regex
// expressions here although I
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
How to get there...
For 4.0.7:
- We leave all default configuration settings as they are now.
- We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps make them
super-globals like $GLOBALS
+1
- We add a new function, somewhat like
The best thing about PHP is that it has such a shallow learning curve that
non-programmers can write web apps.
The worst thing about PHP is that it has such a shallow learning curve
that non-programmers write web apps.
That is of course oversimplifying things quite a bit, but it is the root
of
+1 for PHP way on both questions. The language should be consistent.
I think one of the goals - a major one - of PHP (or any other
programming language, for that matter) should be:
provide a single, consistent interface to many different areas
of programmer's life. In other words, I think
Jani Taskinen wrote:
On Wed, 24 Jan 2001, Uwe Steinmann wrote:
On Wed, Jan 24, 2001 at 03:07:09PM +0100, Cynic wrote:
confuse folks. and the consensus (at least I got it it's agreed
on) is pdf_add_local_link-like names.
From the php point of view there should be underscores but
the
At 05:43 PM 1/24/2001 +0200, Jani Taskinen wrote:
On Wed, 24 Jan 2001, Uwe Steinmann wrote:
On Wed, Jan 24, 2001 at 03:07:09PM +0100, Cynic wrote:
confuse folks. and the consensus (at least I got it it's agreed
on) is pdf_add_local_link-like names.
From the php point of view there should
82 matches
Mail list logo
