Hi,
I would like first to see some bugs closed, like:
* #30641 - PHP 5.1 doesn't compile on Solaris 9
* #31725 - PHP is always segfaulting when using sqlite
* upgrade sqlite and PCRE libraries
Maybe also upgrade GD.
Also, can I humbly suggest we add the Progress Meter / Upload Status
Patch for ve
Hello,
has the Upload progress meter patch finally been applied?
(http://pdoru.from.ro/)
If so, what are the functions that I need to use it?
Thank you, Rob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
would it be possible to add the patch for 5.04?
(I'm not a C coder, I only know PHP)
I think people would appreciate such an addition to PHP,
Thanks,
Rob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello Edin,
This was already considered and rejected. No need to start the discussion
again.
All I saw is that the discussion stopped, not that it was rejected.
Rob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
otherwise this is an E_STRICT error.
I do not entirely agree here since what you are proposing is not to introduce
contravariance for parameters (which I would support) but remove the check
entirely.
In this sense it is an LSP violation (you cannot substitute A with B and
guarantee the correc
> -Ursprüngliche Nachricht-
> Von: Robert Stoll [mailto:p...@tutteli.ch]
> Gesendet: Mittwoch, 4. Februar 2015 20:24
> An: 'Nikita Popov'; 'PHP internals'
> Betreff: AW: [PHP-DEV] Allow dropping typehints during inheritance
>
>
> > -Urs
hing like?
function foo($x, $y){
if(validateFoo($x, $y)){}
//do something
$result = 'some value';
if(postValidateFoo($result){
return $ result;
}
}
Actually putting everything in one function seems even worse from a single
responsibility point of view. But I suppose I am missing something essential
here.
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
de work ?
>
> interface A { }
> interface B extends A { }
>
> class C {
> public function foo(A $a) { }
> }
>
> class D extends C {
> public function foo(B $a) { } // E_STRICT }
>
> This is wrong IMO.
>
>
> Julien.P
Because this would be covariance and violates LSP. Considering the following:
function foo(C $c){
$c->foo(new A);
}
if you substitute C with D then suddenly the code would not work anymore.
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
example why strict typing has its merits. It is
funny to see how confusing it seems to be that you passed 1 instead true but
anyway...
I already mentioned once that we could handle number literals as different
types depending on its context (like Haskell does it).
For instance:
sin(1)
i
7;$this->a >
100');
Cheers,
Robert
> -Ursprüngliche Nachricht-
> Von: Dmitry Stogov [mailto:dmi...@zend.com]
> Gesendet: Dienstag, 10. Februar 2015 08:06
> An: Joe Watkins
> Cc: Yasuo Ohgaki; PHP Internals; Stanislav Malyshev
> Betreff: Re: [PHP-DEV] Design by C
ass Logger{
public log(){
$this->_log($x);
}
private function _log(Foo $f){
//..
}
private function _log(Bar $b){
//..
}
//...
private function _log($x){
throw new Exception("type ".gettype($x)." not supported");
}
}
Which is cleaner IMO.
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Donnerstag, 12. Februar 2015 17:50
> An: Robert Stoll
> Cc: Nikita Nefedov; Pavel Kouřil; PHP Internals
> Betreff: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> Hey Robert,
>
&
Hi François,
> -Ursprüngliche Nachricht-
> Von: François Laupretre [mailto:franc...@tekwire.net]
> Gesendet: Donnerstag, 12. Februar 2015 18:01
> An: 'Robert Stoll'; 'Nikita Nefedov'; 'Andrea Faulds'
> Cc: 'Pavel Kouřil'; 'PHP
> -Ursprüngliche Nachricht-
> Von: François Laupretre [mailto:franc...@php.net]
> Gesendet: Samstag, 14. Februar 2015 07:17
> An: 'Yasuo Ohgaki'
> Cc: 'Dmitry Stogov'; 'Joe Watkins'; 'Stanislav Malyshev'; 'PHP Internals'
> Betreff: RE: [PHP-DEV] Design by Contract
>
> I will try to explain
o Unit in scala)
3. instead of void a function can be declared to be of type null -> almost the
same behaviour as your RFC but without the inconsistency
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Samstag, 14. Februar 2015 22:38
> An: Robert Stoll
> Cc: PHP Internals
> Betreff: Re: [PHP-DEV] [RFC] Void Return Type
>
> Hi Robert,
>
> > On 14 Feb 2015, at 21:23, Rober
Hi Yasuo
> -Ursprüngliche Nachricht-
> Von: yohg...@gmail.com [mailto:yohg...@gmail.com] Im Auftrag von Yasuo Ohgaki
> Gesendet: Samstag, 14. Februar 2015 23:54
> An: Robert Stoll
> Cc: francois; Dmitry Stogov; Joe Watkins; Stanislav Malyshev; PHP Internals
> Betreff: Re
Hi François
> -Ursprüngliche Nachricht-
> Von: François Laupretre [mailto:franc...@php.net]
> Gesendet: Sonntag, 15. Februar 2015 11:43
> An: 'Robert Stoll'; 'Yasuo Ohgaki'
> Cc: 'Dmitry Stogov'; 'Joe Watkins'; 'Stanislav M
> -Ursprüngliche Nachricht-
> Von: Zeev Suraski [mailto:z...@zend.com]
> Gesendet: Mittwoch, 18. Februar 2015 08:00
> An: Nikita Popov; Rasmus Lerdorf
> Cc: Sara Golemon; PHP internals
> Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4
>
> > -Original Message-
> > From: Nikita Popov [
> -Ursprüngliche Nachricht-
> Von: Zeev Suraski [mailto:z...@zend.com]
> Gesendet: Mittwoch, 18. Februar 2015 14:03
> An: Robert Stoll
> Cc: Sara Golemon; PHP internals
> Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4
>
> > -Original Message-
>
o bool should also not
be a BC break in 7.1
Another example:
function foo(int $x){
var_dump($x);
bar($x);
}
function bar(string $x){
var_dump($x);
}
foo(false);
bar(false);
and output:
int(0)
string(1) "0"
string(0) ""
I think you get the inconsistency I am writing abo
after the
error_handler was called (after user was able to log etc.) - at least in
strict mode.
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ur proposed change because static analysers are no
longer able to deal with positional arguments. As far as I remember it was
proposed initially in the unpacking RFC but was changed later on.
https://wiki.php.net/rfc/argument_unpacking
Maybe Nikita can give further information about the reasons behind it.
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, probably too strict for PHP
Back to this RFC. think this RFC goes in the right direction with the
specified conversion rules. Only thing to get rid of are the implicit
conversions to bool from string, float and int IMO.
Moreover, I like that the RFC already has different steps for adding the new
b
Hi Pavel,
> -Ursprüngliche Nachricht-
> Von: Pavel Kouřil [mailto:pajou...@gmail.com]
> Gesendet: Sonntag, 22. Februar 2015 15:54
> An: Robert Stoll
> Cc: Zeev Suraski; PHP internals
> Betreff: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> On Sun, Feb 22, 2015
> -Ursprüngliche Nachricht-
> Von: Pavel Kouřil [mailto:pajou...@gmail.com]
> Gesendet: Sonntag, 22. Februar 2015 20:02
> An: Robert Stoll
> Cc: Zeev Suraski; PHP internals
> Betreff: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> On Sun, Feb 22, 2015 at 7:30
> -Ursprüngliche Nachricht-
> Von: Pavel Kouřil [mailto:pajou...@gmail.com]
> Gesendet: Sonntag, 22. Februar 2015 22:18
> An: Robert Stoll
> Cc: Zeev Suraski; PHP internals
> Betreff: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> On Sun, Feb 22, 2015 at 9:42
oo($a);
Maybe I am wrong and there is a possibility, if so, please let me know, would
be interesting to know.
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Heya Anthony,
> -Ursprüngliche Nachricht-
> Von: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Gesendet: Montag, 23. Februar 2015 14:53
> An: Robert Stoll
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
>
> Rob
Hey Anthony,
> -Ursprüngliche Nachricht-
> Von: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Gesendet: Montag, 23. Februar 2015 15:28
> An: Robert Stoll
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
>
> Robe
tations in the compiler design.
>
> Thanks,
> Nikita
>
> [1]: https://wiki.php.net/rfc/engine_exceptions
Sorry, I am a little bit late with this one and I think it should not obstruct
the vote in any way.
Will it be possible for a user to instantiate the new Exception classes?
Cheers,
R
> -Ursprüngliche Nachricht-
> Von: julienpa...@gmail.com [mailto:julienpa...@gmail.com] Im Auftrag von
> Julien Pauli
> Gesendet: Donnerstag, 26. Februar 2015 10:27
> An: Dmitry Stogov
> Cc: Alexander Lisachenko; PHP internals list
> Betreff: Re: [PHP-DEV] [Discussion] Last chance for cas
s
>
> There's a little RFC + patch that Joe Watkins put together, and as before
> with the ArrayOf RFC, I'll be helping out.
>
[Robert Stoll]
I like the RFC +1 :)
Can I also use traits in combination with anonymous classes?=3D20
--
PHP Internals - PHP Runtime Dev
> -Ursprüngliche Nachricht-
> Von: Philip Sturgeon [mailto:pjsturg...@gmail.com]
> Gesendet: Mittwoch, 4. März 2015 16:49
> An: Robert Stoll
> Cc: PHP Internals
> Betreff: Re: [PHP-DEV] [RFC] Anonymous Classes
>
> On Tue, Mar 3, 2015 at 12:03 PM, Robert Sto
tunately, the manual as such is not precise enough for my needs.
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> -Ursprüngliche Nachricht-
> Von: Patrick Schaaf [mailto:p...@bof.de]
> Gesendet: Samstag, 7. März 2015 08:22
> An: Philip Sturgeon
> Cc: internals; Robert Stoll
> Betreff: Re: [PHP-DEV] [RFC] Anonymous Classes
>
> Am 06.03.2015 20:14 schrieb "Philip Sturgeo
t think there's anything sinister here. It's just the natural result
> of the voting rules.
>
> --
> Matthew Leverton
>
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
> http://www.php.net/unsub.php
I agree with Matthew her
> -Ursprüngliche Nachricht-
> Von: Pierre Joye [mailto:pierre@gmail.com]
> Gesendet: Montag, 23. März 2015 06:57
> An: Juan Basso
> Cc: Stanislav Malyshev; PHP Internals
> Betreff: Re: [PHP-DEV] Serializing exceptions
>
> On Mon, Mar 23, 2015 at 12:31 PM, Juan Basso wrote:
> > Maybe
Borrowing from C#, I would suggest the names implicit and explicit argument
> types. There is nothing "weak" about them,
> they just do an implicit conversion which can be quite powerful if used
> correctly.
>
[Robert Stoll]
It's probably hard to come up with something wh
internals-sc.1433947309.aboompejibidapgjdfhe-robert.devanna=nospammail@lists.php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hi
I'm building PHP7 on linux/64
git checkout PHP-7.0.0
cd PHP-7.0.0
git log | head
commit dbf30365aa15b9044d75b8f77db570bf8fdf2726
Merge: 9cb8cb4 5ff259e
Author: Ferenc Kovacs
Date: Wed Jun 10 10:49:51 201
Hi Patrick
On Wed, Jun 10, 2015, at 08:15 AM, Patrick ALLAERT wrote:
> ereg_*() functions are deprecated since a long time and has been removed in
> PHP 7.
Understood.
Since I'm simply attempting to build PHP7 from source, not, as yet, 'use it',
what do I *do* about it?
Is this something cura
> -Ursprüngliche Nachricht-
> Von: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Gesendet: Montag, 13. Juli 2015 02:12
> An: Larry Garfield; internals@lists.php.net
> Betreff: Re: [PHP-DEV] PHP7 and types
>
> On 07/12/2015 12:37 PM, Larry Garfield wrote:
> > I don't know why we're even ta
On Dec 22, 2011, at 18:59, "Will Fitch" wrote:
> Would you prefer to allow methods with type hinted return values to return
> null at will, or add a marker noting that it *may* return null?
My preference would be to have a marker, and when null is not allowed, if the
function tries to return i
h return types
would provide an important bit of consistency.
Regards,
Bob
--
Robert E. Williams, Jr.
Associate Vice President of Software Development
Newtek Businesss Services, Inc. -- The Small Business Authority
https://www.newtekreferrals.com/rewjr
http://www.thesba.com/
Notice: This commun
eneral. I know, it's
an OS problem, but we could work around this problem very quickly and
improve the usability of cli scripts alot.
Robert
sier-to-maintain) code since it
means variables can be named to best reflect their usage in both parents
and closures.
-Bob
--
Robert E. Williams, Jr.
Associate Vice President of Software Development
Newtek Businesss Services, Inc. -- The Small Business Authority
https://www.newtekreferrals.com/r
On Apr 17, 2012, at 5:39, "Hartmut Holzgraefe"
mailto:hartmut.holzgra...@gmail.com>> wrote:
Same here, i never even knew that this worked in a string context
until recently. Autocast/comparison rules are already complicated
enough as they are documented now, and i failed to find anything
in the m
#x27; code. Even
better, though, might be to add a flag parameter that would give the
programmer explicit control over its behavior, including which bases to
allow (and including the bases currently MIA).
-Bob
--
Robert E. Williams, Jr.
Associate Vice President of Software Development
Newtek Bu
On 12-04-20 07:56 PM, Johannes Schlüter wrote:
On Sat, 2012-04-21 at 01:16 +0200, Stefan Neufeind wrote:
I think we might possibly add a
special kind of "deprecation" where the non-matching case would still
work but (if you activate those deprecation-warnings) would trigger
warnings so you can c
e libs into
the jails. So, is there an easy way to link the needed dns libs statically
to PHP? For ease of use, this could be a nice configure parameter, like
"link it chroot compatible". It must, of course, be made clear that the
user is responsible for security updates of the libraries.
Thanks
Robert
On Jul 14, 2012, at 22:58, "Stas Malyshev" wrote:
> The question is - should we apply it to 5.3/5.4? It is a behavior
> change, even though current code behavior does not match documented
> behavior.
I understand the concerns of BC, but I don't understand our general reluctance
to break BC to f
On Aug 25, 2012, at 17:24, "Guillaume Rossolini" wrote:
> What you say is true, versions get old. But as Lester pointed out, they
> work. that is why some computer systems that have been outdated for years
> are still functioning today. It is hard to make a case for rewriting code
> that already
On Mon, 2005-04-18 at 12:40, Hendy Irawan wrote:
> Does anybody want named parameters?
>
> These are handy as template functions (like in Smarty), and these are
> achievable since the oldest PHP by using associative arrays. It's
> purely syntactic sugar, but it's a very convenient thing I guess (a
On Mon, 2005-04-18 at 13:02, Hendy Irawan wrote:
> On 4/18/05, Robert Cummings <[EMAIL PROTECTED]> wrote:
> > On Mon, 2005-04-18 at 12:40, Hendy Irawan wrote:
> > > Does anybody want named parameters?
> > >
> > > These are handy as template
On Mon, 2005-04-18 at 13:34, Wez Furlong wrote:
> > the power features of Power-PHP (not that it could be called Power-PHP
> > without the blessing of Zend :)
>
> The PHP Group, not Zend.
My bad and my apologies to the PHP Group.
Cheers,
Rob.
--
.
On Mon, 2005-06-06 at 15:47, Jared Williams wrote:
> >
> > JC>>Since when did anyone care that we were giving users
> > enough rope to
> > JC>>hang themselves with?
> >
> > There's rope and rope. Giving rope is one thing, giving a
> > pack of explosives is another.
> >
> > JC>>I don't think w
On Tue, 2005-06-07 at 22:01, Andrei Zmievski wrote:
> Godwin's Law.
Quirk's exception.
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An
On Wed, 2005-06-08 at 11:25, Andrei Zmievski wrote:
> On Jun 7, 2005, at 7:31 PM, Robert Cummings wrote:
>
> > On Tue, 2005-06-07 at 22:01, Andrei Zmievski wrote:
> >
> >> Godwin's Law.
> >>
> >
> > Quirk's exception.
>
> Doe
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 do
On Tue, 2005-06-14 at 01:31, Ron Korving wrote:
> Jason, you are absolutely right.. this is not about input filtering at all.
> It's about replacing:
>
> $x = (isset($ANY_var) ? $ANY_var : 'Default Value');
> by
> $x = ifsetor($ANY_var, 'Default Value');
>
> So, Robert's solution is no real solut
On Tue, 2005-06-14 at 09:45, Sebastian Mendel wrote:
> Robert Cummings wrote:
>
> > [...]
> >
> > On that note, how comes there's a $GLOBAL array and not a $LOCAL array
> > for vars declared in the immediate scope :)
>
> you can use get_defined_vars()
On Wed, 2005-06-15 at 13:21, Rasmus Lerdorf wrote:
> Andi Gutmans wrote:
> > Personally, I don't think there's a significant benefit to adding
> > support for public. There are so many differences and new features that
> > the gain of just being able to change "var" to "public" would be
> > margina
On Thu, 2005-06-16 at 12:51, Zeev Suraski wrote:
> Why would you enable it then? You have to very explicitly enable it, as
> it's off by default, and doesn't get enabled even if you switch to E_ALL.
>
> I think it can help, and I don't see how it can hurt given the fact it's
> not on unless you
I think the reference notice stuff is a bit ridiculous. I mean I can
understand the concern behind:
function &foo()
{
return $fee.$fii;
}
But I mean the following gives errors too which is a bit too anal
retentive even for my liking:
function &foo()
{
$fee = '
On Sun, 2005-07-17 at 19:07, Matthew Charles Kavanagh wrote:
> Either way, I really don't think it's worth any fuss. It's just a
> notice, and whether it is there or not shouldn't really matter that
> much. This doesn't deserve all the attention it's been getting on this list.
That's your opinion
On Sun, 2005-07-17 at 18:06, Matthew Charles Kavanagh wrote:
> It's a notice. Your soul won't curdle and fall out of your ears just
> because your code produces a notice which you can easily prevent from
> being output.
My soul didn't curdle and fall out of my ears before the notice was
added eith
On Sun, 2005-07-17 at 19:25, Matthew Charles Kavanagh wrote:
> Enjoy your presumptions, I'm sure they're great fun at parties.
Yes, one of my favourites is that jaws are made of glass.
Cheers,
Rob.
--
..
| InterJinn Application Framewor
On Sun, 2005-07-17 at 19:52, Rasmus Lerdorf wrote:
> Yes, we know there are still some issues here. People are working on
> it. Or there is at least intent to work on it. See
> http://bugs.php.net/bug.php?id=33643
Ahhh, very cool. Thanks.
Cheers,
Rob.
> Robert Cummings wrote:
On Sun, 2005-07-17 at 20:47, Wez Furlong wrote:
> If you think its so easy, why haven't we seen a patch to fix it coming from
> you?
Because I don't have time *pthththth*.
> Now, stop wasting our time with your continued ranting (that applies
> to *everyone* who keeps going on-and-on-and-on-and-
On Sat, 2005-08-13 at 23:53, Sara Golemon wrote:
> > I really doubt this will change.
> > It would be a *huge* mess in the docs
> > and peoples scripts and brains
> > if we did change it--it wouldn't really
> > win anyone anything:
> >
> At the risk of someone taking this as a worthwhile idea:
>
>
On Sun, 2005-08-14 at 00:28, Sara Golemon wrote:
> >> PHP_FUNCTION(strpos)
> >> {
> >> ...
> >> /* Swap needle and haystack if they appear to be backwards */
> >> if (needle_len > haystack_len) {
> >> char *t; int t_len;
> >> t = needle; needle = haystack; haystack = t;
> >>
Did you find someone yet?
Cheers,
Rob.
On Sat, 2005-09-03 at 11:27, Daniel Flick wrote:
> I humbly apologize for posting to this forum without more knowledge. I
> did look for the faq and was unable to find it. If this is not the
> correct forum, please let me know. There is an ambulance compa
On Sat, 2005-09-03 at 15:18, Robert Cummings wrote:
> Did you find someone yet?
Sorry Internals, I didn't mean to respond to this list since this is
off-topic for here.
Cheers,
Rob.
--
..
| InterJinn Application Framewor
On Mon, 2005-10-03 at 09:49, Derick Rethans wrote:
> On Mon, 3 Oct 2005, Richard Mann wrote:
>
> > Hmmm I agree about the reassigning of $this, but not the passing of
> > $this by ref.
>
> Why are you passing an object be reference? Never heard that in PHP 5
> objects are always references?
On Mon, 2005-10-03 at 10:40, Robert Cummings wrote:
> Either way I'm not weighing in on the $ref = &$this issue
Actually, I think I will.
I think $ref = &$this is perfectly legal and
I think $this = &$ref or $this = $anything is perfectly i
On Sun, 2005-10-30 at 15:57, Ron Korving wrote:
> The function I used in my post does not generate an E_NOTICE, because a
> call-by-reference can be done with an unset variable (that can be set from
> the function).
>
>error_reporting(E_ALL);
>
> function ifsetor(&$var, $value)
> {
>
On Thu, 2005-11-17 at 16:42, Rasmus Lerdorf wrote:
> Andreas Korthaus wrote:
>
> > Can someone tell me the reason for this decision?
>
> Very few people converted to using {} so the argument about reading old
Ugh, so those of us that did are going to have to comb back through our
code and rever
On Thu, 2005-11-17 at 18:33, Ilia Alshanetsky wrote:
> Andreas Korthaus wrote:
> > OK, but by dropping {} for strings you also remove the possibility to
> > have a convention like "[] for arrays and {} for strings".
> > If I could decide I would drop {} for arrays and [] for strings, but I
> > fear
On Thu, 2005-11-17 at 18:51, Robert Cummings wrote:
> On Thu, 2005-11-17 at 18:33, Ilia Alshanetsky wrote:
> > Andreas Korthaus wrote:
> > > OK, but by dropping {} for strings you also remove the possibility to
> > > have a convention like "[] for arrays and {
On Thu, 2005-11-17 at 19:05, Rasmus Lerdorf wrote:
> Robert Cummings wrote:
> > On Thu, 2005-11-17 at 18:33, Ilia Alshanetsky wrote:
> >> Andreas Korthaus wrote:
> >>> OK, but by dropping {} for strings you also remove the possibility to
> >>> have a
On Fri, 2005-11-18 at 03:12, Derick Rethans wrote:
> On Thu, 17 Nov 2005, Robert Cummings wrote:
>
> > On Thu, 2005-11-17 at 16:42, Rasmus Lerdorf wrote:
> > > Andreas Korthaus wrote:
> > >
> > > > Can someone tell me the reason for this decision?
>
On Sun, 2005-11-20 at 08:50, Derick Rethans wrote:
> On Sun, 20 Nov 2005, Matthias Pigulla wrote:
>
> > Changing language syntax that way back and forth again will cause a loss
> > in credibility - once again after the 4.4.0 release.
>
> If you prefer a PHP which causes strange crashses and memor
On Sun, 2005-11-20 at 09:37, Derick Rethans wrote:
> On Sun, 20 Nov 2005, Robert Cummings wrote:
>
> > On Sun, 2005-11-20 at 08:50, Derick Rethans wrote:
> > > On Sun, 20 Nov 2005, Matthias Pigulla wrote:
> > >
> > > > Changing language syntax that
On Fri, 2005-11-25 at 20:07, Ken Tossell wrote:
> Not to start a flame war, but...
>
> How about STD, Std, or something similar? It certainly works for... that
> language... that has multiple implementations of the standard classes.
> It can't hurt to play to people's comfort when the change doesn
I'd almost rather have %% over <-, and even that looks kinda messy.
I think if I had to, I'd pick :>, although there still isn't any that
stands out to me as "Hey, this is definately a good choice"
--
--Robert Deaton
On Sun, 2005-11-27 at 07:54, Zeev Suraski wrote:
> Guys,
>
> Laughter has nothing to do with it.
>
> However, as discussed between those who attended the meeting in
> Paris, goto earned its bad connotations for a reason.
Goto got it's bad name from when it was used to jump to line numbers. I
ca
On Sun, 2005-11-27 at 15:54, Zeev Suraski wrote:
>
> We *can* screw it if we go in the wrong
> direction, and adding redundant features which
> are useful in rare cases and much more likely to
> be abused than to be properly used is a good step
> in that direction. A lot of people are saying w
On Tue, 2005-11-29 at 20:40, Sara Golemon wrote:
> But first, this word from our sponsor:
> Group A wants anything resembling goto to burn in the fires of hell
> Group B wants full non-crippled goto or nothing at all
> Group C wants partial goto (non-backward jumping) or nothing at all
> Groups B a
On Fri, 2005-12-09 at 00:21, Alan Pinstein wrote:
>
> And, if it's just lucky, then what is the solution to the problem? Am
> I just SOL? Is the answer simply that if you *need* to create
> circular references in PHP, then you *must* accept memory leakage?
If you know you have a circular refe
Could someone explain to my feeble mind how the bug reported at the
following link is bogus? The added comment is pretty obtuse :(
http://bugs.php.net/bug.php?id=35634&edit=2
Thanks,
Rob.
--
..
| InterJinn Application Framework - ht
On Sun, 2005-12-11 at 17:26, Robert Cummings wrote:
> Could someone explain to my feeble mind how the bug reported at the
> following link is bogus? The added comment is pretty obtuse :(
>
> http://bugs.php.net/bug.php?id=35634&edit=2
I'd just like to add before a sec
On Sun, 2005-12-11 at 19:02, Bart de Boer wrote:
> Robert Cummings wrote:
> > On Sun, 2005-12-11 at 17:26, Robert Cummings wrote:
> >
> > Could someone explain to my feeble mind how the bug reported at the
> > following link is bogus? The added comment is pretty
Help debug and fix continuing issues with respect to PHP + Solaris. In the
position of debugging and fixing Solaris + PHP issues almost exclusively for my
job. In particular, I would like to contribute to code fixes and configuration
checks for the many issues PHP is facing with respect to So
On Sat, 2007-11-17 at 01:21 -0500, Sam Barrow wrote:
> True. What if we created a php.ini directive that defaulted to off that
> would determine the ability to declare superglobals,
> "allow_superglobals" or something.
Does your code live in a bubble? Allowance of of arbitrary super global
definit
On Sat, 2007-11-17 at 01:40 -0500, Sam Barrow wrote:
> I don't understand, people keep telling me this can cause problems so
> it's trash. Really? Functions and variables can cause problems too. Not
> to mention user input. Programming is not easy, but the more flexible it
> is the better. I think
On Sat, 2007-11-17 at 18:03 -0800, Stanislav Malyshev wrote:
> > You say that superglobals were not designed to be user defined, think
> > about it, the concept of a superglobal is present in C and C++, two of
> > the maturest and strictest languages around.
>
> Concept of inserting assembly code
I raised bug http://bugs.php.net/bug.php?id=43480 noting that the behaviour
of the array functions next, current, prev had been changed in 5.3.
Previously (5.2 and before) it was possible to use these as a crude iterator
over object properties. In 5.3 this behaviour has been removed.
The bug has b
On Tue, 2007-12-04 at 22:26 -0600, Larry Garfield wrote:
> On Tuesday 04 December 2007, Derick Rethans wrote:
>
> > 4. What is wrong with simple prefixes in the first place? Both PEAR_*,
> >Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
> >'namespaces'. We could opt
On Wed, 2007-12-05 at 09:34 -0800, Stanislav Malyshev wrote:
> > Namespace support is for people who didn't name their classes/functions
> > properly.
>
> Here's a claim so weird I don't know how to parse it.
I think you're confusing parsing for grokking. Namespace support is
merely candy coatin
1 - 100 of 863 matches
Mail list logo
