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 beha
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, th
> 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
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 amon
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 sup
Ok, this was my mistake in missing the "Ternary operator enhancement
for fluent code"
(http://marc.theaimsgroup.com/?t=9622016834&r=1&w=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
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 op
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.
T
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 bug.phptbug17123.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 bug.phptbug17123.p
Hello,
to make easier maintenance and checking possible I would suggest to name
our tests more appropriate:
Class: Name: Example:
Tests for bugs bug.phptbug17123.phpt
Tests for functions .phptdba_open.phpt
General tests fo
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 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
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
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
I'm pretty new to this list, and I'm not actively partaking in the
development of PHP [yet] (i'm learning though ;), and I figured I might
voice my opinion as an average PHP user (2 years or so, started with
php3). Feel free to ignore me. :)
I've been following this thread for the past few day
cs/manuals/js/core/jsguide/obj2.htm#1008342
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 aggre
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 yo
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;
librar
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 synta
On 10/04/02, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> I'll sum up my proposal again.
> Support the following:
> class MyClass extends MyParent aggregates Timer, FooBar
> {
> }
>
> $obj = new MyClass; // Creates $obj->Timer and $obj->FooBar
> $obj->method(); // Searches MyClass, MyParent if not
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, slightl
At 23:25 10.04.2002, Lauri Liinat wrote:
> > 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 clas
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 fo
> 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.
n
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
we'll solve all possible scenarios for the first time in
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 future
> >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.
At 23:11 10/04/2002 +0300, Andi Gutmans wrote:
>At 13:07 10/04/2002 -0700, brad lafountain wrote:
>> > I was thinking that we could have an explicit way of calling the right
>> one.
>>
>> hmm what would this look like?
>>
>> $a->c::print();
>> i guess that's not that bad. and its kinda consist
At 13:07 10/04/2002 -0700, brad lafountain wrote:
> > I was thinking that we could have an explicit way of calling the right
> one.
>
> hmm what would this look like?
>
> $a->c::print();
> i guess that's not that bad. and its kinda consistant
>
> but i do like
> $a->c->print();
> too..
>
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
>
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
--- 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 :)
> > >
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
--- 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 would be interface delegation to an implicit property.
Nearly what delphi allows but with simple syntax.
The difference to delphi is that you have to declare the property.
For me it is o.k. A simple solution.
marcus
At 19:35 10.04.2002, you wrote:
>Hey guys,
>
>I still haven't finished rea
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 c
> > 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
> > chan
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
> 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 re
> > 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
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
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
'
> 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, S
> 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
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
> configurati
> 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 sam
> 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
> 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 installe
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
> 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) but I am not really
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 discus
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
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 is
[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
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
_
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 Lis
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 sta
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
wi
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
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 ha
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). Th
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
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 t
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 be
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 releas
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
eleases
>that are properly tested and released (and yes I do keep up on CVS much of
>the time to test and contribute to the code- I am one of those properly
>testing it)
>
>--
>--
>Mike
>
>
>
>- Original Message -
>From: "Jani Taskinen" <[EMAIL
n" <[EMAIL PROTECTED]>
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 h
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
rele
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
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
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) are approved by somebody with
cvs commit powers. Otherwise, let's discuss how to fix it some other
way. Right now magic beh
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 shall
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
> super-
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-sty
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: i
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 sup
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 ha
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 her
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
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
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 altho
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. I
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 support prefix globbing, other types of
> globbing are prone to
> 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
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
> // sli
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 writ
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 t
hi,
> >There are probably other points which need to be discussed like
> >what a function should return if it fails. Many php functions return
> >false but pdflib's api requires to return -1.
>
> Again, we should be consistant within PHP the language.
> ie. if function fails -> RETURN_FALSE.
>
>
> I agree. PHP doesn't need to map the C API's one-to-one but implement PHP
> functions in the PHP spirit and in a consistent way. That consistent way is
> returning false.
> We've talked about this numerous times. When we implement an extension
> module for a C library we don't even necessarily n
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 th
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
As far as I am concerned this is Uwe's decision to make. I would be happy
to see you guys have direct CVS access to maintain this extension and make
whatever changes you deem necessary. Uwe?
Many of the things you mention are things people have been asking for, and
if it can't be implemented wi
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 pdflib api doesn't use th
+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 consi
On Wed, Jan 24, 2001 at 03:07:09PM +0100, Cynic wrote:
> maybe they should be pdf_find_font, pdf_add_local_link etc?
> that would be more consistent with the func-naming convention,
> I guess, but I'm in no position to decide this.
> but I definitely think that it should be either underscore
> e
maybe they should be pdf_find_font, pdf_add_local_link etc?
that would be more consistent with the func-naming convention,
I guess, but I'm in no position to decide this.
but I definitely think that it should be either underscore
everywhere, or just between the ext. prefix and the rest of
the n
1 - 100 of 101 matches
Mail list logo
