Etienne Kneuss wrote:
It's always dangerous to introduce a new keyword, as it can/will break
BC (i.e what if somebody has defined a function derived(), the parser
would choke on that).
I'm personally fine with static, even if it may eventually introduce
some confusion.
Regards
Perhap
> Bart de Boer wrote:
>> Ken Stanley wrote:
>>
>
> ...
>> That's not right. Accessing the child class would only be possible from
>> within an instantiated object. Unlike parent::, you will never be able
>> to use static:: in a purely static context.
Ken Stanley wrote:
As for parent/self:: and even static::, what makes
them static is the scope resolution operator (::), not their name.
Their name just implies the context in which they are to be used.
That's right. And that's exactly why it's such a bad idea to call it
static::. It's the
Richard Lynch wrote:
On Wed, May 30, 2007 9:54 am, Jochem Maas wrote:
Richard Lynch wrote:
Maybe I'm just confused (well, I'm always confused...) but if a
Class
has multiple children, how the heck would PHP know which child:: to
call?...
the use of the name 'child' is very confusing, I would p
static function getTableName() { return 'PRODS'; }
What a great idea! You can just do:
$tableName = $this->getTableName();
...from within the base class. No need for static:: or super:: keywords
anymore... It may be not as elegant as having a special keyword for
it... But, for now, this appr
static function getTableName() { return 'PRODS'; }
What a great idea! You can just do:
$tableName = $this->getTableName();
...from within the base class. No need for static:: or super:: keywords
anymore... It may be not as elegant as having a special keyword for
it... (Or if this is the inte
This subject has some correlation with my previous suggestion. Except I
totally forgot about the "late static binding" discussion.
I'd like to give another real life example. This is an oversimplified
version of what I'd currently like to do (without a bunch of workarounds):
'Address');
k some
existing PHP feature that already allows me to do this. :|
Cheers,
Bart de Boer
Hi,
this doesnt work because static vars are bound to his class and are not
inherited by a child class.
maybe this would be work with php6 or a other 5.x version.
(Same behavior like the singleton pattern
ons would be. Just thought it would
be a nice addition to the language. :) Hope I didn't overlook some
existing PHP feature that already allows me to do this. :|
Cheers,
Bart de Boer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
eature that already allows me to do this. :|
Cheers,
Bart de Boer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Anyone care to comment?
Bart de Boer wrote:
Hello all,
I couldn't find if this is already implemented somehow. But I thought it
would be a nice idea to let the PHP http streams understand HTTP
caching. This could come in particularly handy when PHP is used to
consume REST-
uture plans of the php group.
Regards,
Oliver
- original Nachricht
Betreff: Re: [PHP-DEV] dropping asp_tags in HEAD
Gesendet: So, 15. Apr 2007
Von: Bart de Boer<[EMAIL PROTECTED]>
The XML standard...
HTML 4.01 compliance seems a bit trivial since there's already so m
The XML standard...
HTML 4.01 compliance seems a bit trivial since there's already so much
forgiveness going on around that spec anyway...
Oliver Block wrote:
Am Samstag, 14. April 2007 11:49 schrieb Bart de Boer:
PHP's convention is currently
responsible for people creating non
t
weekend!
-Bart
Rasmus Lerdorf wrote:
Bart de Boer wrote:
I feel I can't disagree with my hero. :) But is that really so?
The XML spec says:
PI ::= '' Char*)))? '?>'
Doesn't Char* mean any char?
All the parsers seem to accept '>' inside PI&#
low literal entities
inside the PHP blocks, because that is also not standards compliant.
That means you cannot write:
10) foo() ?>
You would have to change it to:
And that's just a simple example of that.
-Rasmus
Bart de Boer wrote:
And let me stress that this is something w
uments... And
I think we should take that responsibility and clean up the mess we
made... The XML spec is outside our scope... What's inside our business...
Tijnema ! wrote:
On 4/14/07, Bart de Boer <[EMAIL PROTECTED]> wrote:
I think ASP tags should go too... Simply because it's
I think ASP tags should go too... Simply because it's not standards
compliant and I think it's good if people are forced to make nice
standards compliant documents... I'd even go so far as to favor dropping
short tags too...
\n"; ?>
What a mess!...
Guilherme Blanco wrote:
I really can'
Hello all,
I couldn't find if this is already implemented somehow. But I thought it
would be a nice idea to let the PHP http streams understand HTTP
caching. This could come in particularly handy when PHP is used to
consume REST-based webservices. (Perhaps in the future also for SOAP 1.2
GET
+1 for goto
-1 for jump
Wez Furlong wrote:
My vote is +1 for goto, just because that largely describes what it
does and how it is used. I don't mind if it winds up being called
jump, I just think it will be easier for people to find it when they
need it if it is called 'goto'. 'goto' also c
Steph Fox wrote:
If someone is searching for "goto" he/she most likely knows what
he/she is looking for. So this also helps experienced developers who
are new to PHP.
An experienced developer would know how to use it...!
That was kind of the point.
- Steph
The reason for using jump is "bec
Steph Fox wrote:
BdB>>Even though I like "jump", people will most likely be searching for
BdB>>"goto" (PHP manual) or "goto PHP" (Google) when they're trying to
BdB>>find out if PHP has such a functionality. So, maybe it's better to
BdB>>just call it "goto".
For such people we might have a page
Greg Beaver wrote:
Dmitry Stogov wrote:
Hi,
The solution (2) - "goto only" is the winner.
So in case of no serious objections, I'll commit the "goto.diff" patch in 24
hour.
The last question:
What do you thin about Andi's solution about using "jump" instead of "goto"?
It may make sense, beca
Rasmus Lerdorf wrote:
Michael Wallner wrote:
Dmitry Stogov wrote:
1) goto and break label
+0
3) break label only (like Java)
+1
You do realize that this is:
label:
while(condition) {
break label;
}
As a C programmer this confuses me to no end. When I see "label:" I
expect c
+1 for this::
Andi Gutmans wrote:
Yep. I was thinking mainly of methods not of static variables. I still
think this:: is the best way (better than class::)
At 12:12 PM 3/2/2006, Jeff Moore wrote:
On Mar 2, 2006, at 2:23 PM, Andi Gutmans wrote:
Do you expect significant BC breakage?
Hel
final::foo();
Dmitry Stogov wrote:
-Original Message-
From: Andi Gutmans [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 02, 2006 5:51 AM
To: Dmitry Stogov; 'Marcus Boerger'; 'Mike Lively'
Cc: 'PHP-DEV'
Subject: RE: [PHP-DEV] [PATCH] Late Static Binding
At 06:37 AM 3/1/2006, Dm
Kevin Waterson wrote:
This one time, at band camp, Jeff Moore <[EMAIL PROTECTED]> wrote:
To give SplObjectStorage a better name. My best suggestion is
SplUniqueObjectContainer. There may be a better choice.
Why not just call it Betty.
Kevin
+1 for Betty!
--
PHP Internals - PHP Runtim
Bart de Boer wrote:
Mike Naberezny wrote:
Bart de Boer wrote:
Maybe introduce an optional second argument "decodetype" to
json_decode() where you could pass on a constant like JSON_ARRAY or
JSON_OBJECT?
For example:
$assoc_array = json_decode($json_string, JSON_ARRAY
Mike Naberezny wrote:
Bart de Boer wrote:
Maybe introduce an optional second argument "decodetype" to
json_decode() where you could pass on a constant like JSON_ARRAY or
JSON_OBJECT?
For example:
$assoc_array = json_decode($json_string, JSON_ARRAY);
$object = json_decode($j
Daniel Convissor wrote:
Exactly what I was going to say.
The one thing I'd like to see change is having JSON "objects" decoded into
PHP associative arrays, not PHP objects, as is done in the current PECL
implementation. Here's what happens now via PECL JSON:
Maybe introduce an optional sec
Bart de Boer wrote:
Stefan Walk wrote:
Just a small suggestion - what do you all think of creating an array
implicitely on function calls like db_connect('host' => $host, 'port'
=>$port), or funcname($param1, $param2, 'foo' => 'bar'). Those parts
Stefan Walk wrote:
Just a small suggestion - what do you all think of creating an array
implicitely on function calls like db_connect('host' => $host, 'port'
=>$port), or funcname($param1, $param2, 'foo' => 'bar'). Those parts
would have to be on the very end of the argument list. Would eliminate
Sönke Ruempler wrote:
Bart de Boer <mailto:[EMAIL PROTECTED]> wrote on Friday, December 16, 2005
10:19 AM:
...until they are supported by the major browsers.
Maybe never if M$ tries to push InfoPath ;-(
Although I'm sure we'll find a way to use, whatever technology Micr
...until they are supported by the major browsers.
Ilia Alshanetsky wrote:
Bart de Boer wrote:
However, XForms will have numeric datatypes. :|
http://www.w3.org/TR/2003/REC-xforms-20031014/slice5.html
And no one in their right mind uses them.
Ilia
> Don't forget that one fundamental aspect of PHP is, that it's a web
> language and thus receives most of its input from the web.
> Therefore it usually only gets strings as input.
>
> Consider ($_POST['intfield1'] == $_POST['intfield2'])
>
> Both variables would be strings. Still if someone would
Don't forget that one fundamental aspect of PHP is, that it's a web
language and thus receives most of its input from the web.
Therefore it usually only gets strings as input.
Consider ($_POST['intfield1'] == $_POST['intfield2'])
Both variables would be strings. Still if someone would input '01'
Robert Cummings wrote:
This sample on the bug report is actually a very whittled down version
of where I first experienced the problem. In practice my error class is
loaded on first error and subsequently acts as a singleton. My thoughts
on the problem are that PHP encounters an E_STRICT excepti
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 obtuse :(
http://bugs.php.net/bug.php?id=35634&edit=2
Thanks,
Rob.
It looks like each time yo
> I really do not see the point is worrying all too much about multi
> threading in PHP. Writing proper multi threaded code is hard and why
> bother? Your server is going to be busy doing tons of other things at
> the same time. So all your CPU's and cores should have plenty of things
> to do. Also
Thank you all, for the feedback. Some solutions are new to me. So, I'll
be taking a deeper look into those options.
I have to say that they all still sound a bit like work-arounds.
(Although this could very well be due to my unworthy knowledge. ;) ) I
still think it would be nice if there woul
fork() works on windows as well, but on Win32 forking is MUCH slower
then threads.
Ilia
With fork() you mean using exec() to call php with another script,
right? Because I can't seem to find the fork() function anywhere. :|
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
Sara Golemon wrote:
I've got two...well...threads... going on this concept One is a very
non-true-threading apprach which involves a combination of ticks and
Runkit_Sandbox which I hope to get around to sooner rather than later.
The other is a longer-range plan designed to work specifically
Ilia Alshanetsky wrote:
You don't need threads, you can use fork() for that. On *nix systems it
is very fast, nearly as fast as threads and much safer to boot. And you
can already do forking in PHP via PCNTL extension's pcntl_fork() function.
Ilia
That sounds sufficient enough. Although I gues
Rasmus Lerdorf wrote:
Bart de Boer wrote:
Are there any future (or current) plans for multithreading in PHP?
There are no plans for this. Asynchronous mechanisms are generally a
much more efficient way to do this stuff.
-Rasmus
With asynchronous I'm asuming you mean mechanisms wher
Dear PHP creators,
I was wondering. (And I'm probably the 1000th person asking this.) With
all the multiple-core processors and servers popping up lately, are
there any future (or current) plans for multithreading in PHP?
It's not unlikely to have a PHP script that, for example, needs to send
Furthermore. The problem with echo 'a::b::c();' would only
occur if the code structure would be like this:
namespace a {
namespace b {
function c() { }
}
class b {
function c() { }
}
}
However, should it be legal to give a class the same name as
a namespace that's in the same s
Bart de Boer wrote:
What was the argument against '::' again?
Jessie Hernandez wrote:
Found it...
BTW, "::" is out the question (yes, I did try it). It created ambiguity
in the case of calling a function in a namespace and calling a method of
a class in a namespace:
What was the argument against '::' again?
Jessie Hernandez wrote:
Oliver,
Like I mentioned in another thread, ":" cannot be used, even if only
classes are allowed in namespaces. Look at this example:
$x = $y?a:b::c();
The above can be parsed either as the first argument being "the result
This is part of the definition of namespaces.
And yes, I want the INI option to just provide aliases.
If these are implemented by injecting
class a_A2 extends a::A2 {}
as interface classes or by internally providing a hash table alias is
only different from a technical point of view. The resul
> /*
> * this encounters a namespace. The auto-prefix-import option
> * is active so EVERYTHING is inside the namespace is imported
> * with a prefix of "JessieStuff_".
> */
> require 'JessiePackage.php';
> $x=new JessieStuff_SimpleClass();
So let's say we've got a package like this:
namesp
> Of course it is meaningful for PHP as well.
>
We're talking about the PHP language. Not the PHP engine. You're right that
the PHP engine needs to be capable of finding its processing instructions.
So it's capable of doing a little XML. Thus it needs to understand the
meaning of whitespace in XM
Let's say: Mike doesn't want to use namespaces but he wants to use a
package from Jessie. Jessie uses namespaces. Mike has his PHP configured
to "auto-prefix-import" everything. So if he uses your file foo.php
containg
namespace JessieStuff{ class Foo { ... } }
in conjunction with this setti
But that whitespace is meaningfull at XML level and not at PHP level.
Processing Instruction: phpecho
Sean Coates wrote:
Sara Golemon wrote:
oh, that's easy to solve '
Marcus-
You give me greif over ;; and ** as namespace separators then you
suggest meaningful whitespace? *tsk*tsk*tsk*
-S
Sorry... Forget I said that...
Bart de Boer wrote:
Hi Jared,
If probably don't understand named arguments correclty but couldn't you
do something like:
function(array('name1' => 'val1', 'name2' => $var));
In the function you could then
Hi Jared,
If probably don't understand named arguments correclty but couldn't you
do something like:
function(array('name1' => 'val1', 'name2' => $var));
In the function you could then check which keys (names) have values,
thereby simulating a form of named agruments?
On Nov 29, 2005, a
That would be a mandatory whitespace then. Which may be a bit confusing.
Marcus Boerger wrote:
Hello Hartmut,
oh, that's easy to solve '
best regards
marcus
Wednesday, November 30, 2005, 10:44:37 AM, you wrote:
Mike Hall wrote:
Just FYI, the lack of
as far as i remember the only a
devils advocate:
what happens when I want to place a 'goto' label just before a while or
foreach
loop (upon which I haven't put a label)? I ask because I assume that the
following 2
statements should be identical no:?
I think there would be no such thing as a 'goto' or 'break' label. There
'would brake standards compliance for PHP scripts.
If you want to be able to use 'where the XHTML/XML specs are defined.
If people change their code from 'it, they might just as well change it to 'little bit more code but it makes sure that your documents remain
standards compliant.
If you r
Sounds good from a syntax perspective... :)
Sara Golemon wrote:
This "break LABEL" construct does exactly the same as "break NUM",
May be I missed something? I didn't look into patch deep.
Your take is spot-on. This isn't an extension of functionality, just a
"numbered breaks with a name" w
I wasn't thinking about goto or break. I was thinking about *labels* and
using them in a consistent manner with PHP.
For example:
while (cond) {
LABEL:
while (cond) {
if (cond) {
break LABEL;
} else {
some_command OTHERLABEL;
}
}
}
OTHERLABEL:
Or Sara's way:
whi
Sara++ :)
Although I prefer BAR:while (This would go better with goto if someone
would want to implement that some day.) I'd settle for while BAR since I
don't care about goto anyway.
So:
foreach BAZ ($arr as $val) +1
BAZ: foreach ($arr as $val) +2
foreach as BAZ ($arr as $val) -2 ('as'
nstants/functions, PLEASE show me a
_valid_ example that cannot be accomplished by just simply
putting the constant/function inside a class in the namespace.
Bart de Boer came up with a good reason for them so I'd like to re-post
his statement.
Namespace constants can be handy if you'
It may be so that you can use exceptions as a sort of goto mechanism.
And from some perspective you may even find some similarities. However,
exceptions weren't invented for this purpose. (And they aren't
introduced into PHP for this reason.)
The main difference is that exceptions work with
Just wondering. There's another thread about goto and labels running as
well. If they vote for something like:
LABEL:while (cond) {
}
Wouldn't this add another technical diffuculty with using ':' as a
namespace seporator?
Oliver Grätz wrote:
Lukas Smith schrieb:
Oliver Grätz wrote:
I agree.
Although there's aanother thread running about namespaces that are about
to do something with ':' as well. Watch out that there aren't conflicts?
Ron Korving wrote:
I agree. Like you I couldn't really care about a 'goto', I'd probably never
use it. But labeled breaks would really ad
I feel we're comparing apples with oranges here.
Break; is for breaking out of loops. It shouldn't have anything to do
with jumping to somewhere else. Let's say *if* PHP supported jumping
through the code. The following should then be two different things:
while (loop) {
goto LABEL;
}
:LAB
Have a fresh look :)
name1:::name2:::class::func();
name1::name2::class::func();
name1\name2\class::func();
I think there are way too many dots with ':::'.
Looking at this example I must say '\' looks cleanest. And it's the most
intuitive since namespaces are sort of like directories anywa
I personally never use constants anyway. But at least functions and
variables should work with namespaces:
namespace name1 {
$var = 3;
function func();
}
From a language perspective those should exist only in that namespace.
I also think '\' as a seporator is nice. It has this nice filesys
I thought that was the whole point of namespaces. That you can include
stuff without worries that things will conflict:
namespace name1 {
define("CONSTANT", "Hello world.");
}
namespace name2 {
define("CONSTANT", "Hello mars.");
}
Would produce seporate constants because they're defined in
Namespace constants can be handy if you'd want to include some library
that uses predefined constants and classes that might conflict with
other classes and constants in the script.
namespace someLib {
include('huge_conflicting_library_that_I_dont_want_to_reverse_engineer');
}
Stanislav Ma
I'm sorry if I say stupid stuff. My previous post actually was the first
post I've ever made to a newsgroup! Please bare with me while I adjust
to the etiquettes. :)
Anyway. Somebody has probably already suggested this. But how about:
namespace1}{Date::myfunction();
namespace2}{Date::Otherfunc
Well, the problem is: '->' isn't used for classes. It's used for
objects! An object is an instance of a class. '~>' Would be more
appropriate if there would be such a thing as an instance of a
namespace. But not for accessing the namespace itself. (In my opinion)
This is why I think it should
71 matches
Mail list logo
