Marian Kostadinov wrote:
Yes, that's my idea - to ignore keys that are not defined as placeholder.
And not only for objects but for arrays also.
I do not know the implementation in PDO, but the implementation I made
in MDB2 only tries to parse the placeholders if it has to emulate or
detects
Michael Wallner wrote:
Derick Rethans wrote:
On Wed, 9 Aug 2006, Marian Kostadinov wrote:
But that is not executed because we have some additional key/value pairs.
So the idea is to allow this. Also I suggest we allow using object along
with an array. This is a common situation also.
Actuall
Jeff Moore wrote:
On Aug 4, 2006, at 3:23 AM, Derick Rethans wrote:
- Add a new flag to methods (at the implementation level) that will
allow to flag them as 'strict'
Hello,
Would exposing this flag to the user at method level get a bit verbose
for those who want to use it? Perhaps a c
Zeev Suraski wrote:
It's my list actually, so I'm definitely +1 on that :)
Sorry, did not want to take away credit from you Zeev :)
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans wrote:
- Add a new flag to methods (at the implementation level) that will
allow to flag them as 'strict'
- In case such a strict method is improperly overridden - error out
(E_ERROR)
- In case a non-strict method is improperly overridden - emit E_STRICT
i am fine with tha
Derick Rethans wrote:
On Thu, 3 Aug 2006, Lukas Smith wrote:
I still think that a flag on a per class basis would be the better
solution, but I guess I can accept this change.
I don't think it is better as it would require somebody (in one of the
teams) to modify their source files.
Hi,
well it seems that the initial vision of E_STRICT to denote future
deprecation is no longer valid. Then again it might have been a
misunderstanding from the beginning as E_DEPRECATED would have been the
more obvious name in that case.
I still think that a flag on a per class basis would
Rasmus Lerdorf wrote:
Sure, and I agree that we should find a comfortable middleground, I'd
just like to see a little less criticism of Marcus and some more
civilized discussion. As far as I am concerned, Marcus' approach of
Nobody has criticized Marcus work. I have not heard anyone claim t
Jared Williams wrote:
PS: An real-life example from those wo prefer the old
behavior would be
nice ;-)
-soenke
Yes, I having a hard time imaging one, other than some quick fix.
I'd much rather have some decent refactoring tools.
The fact of the matter is you do not need the old behavio
Derick Rethans wrote:
On Wed, 2 Aug 2006, Lukas Smith wrote:
again i feel that people who want to use PHP as a "proper" OO language will
definately benefit from a strict mode if they are willing to put in the extra
planning. however alienating the userbase for this by making it imp
Derick Rethans wrote:
On Tue, 1 Aug 2006, Robert Cummings wrote:
On Tue, 2006-08-01 at 23:41 +0200, Marcus Boerger wrote:
Hello Michael,
nobody forces you to use OO if you don't like it but it is as it is. And
It is as it is, but not as it was. PHP4 allowed signature mismatching.
Yeah,
Rasmus Lerdorf wrote:
Relax people. There are certain paradigms and expectations people have.
The original PHP design met the expectations and paradigms of a
loosely typed procedural language. Now, some 12 years later we are
trying to meet a new class of expectations. We have kids coming
Richard Lynch wrote:
So what exactly is the purpose of enforcing the same args here?
Does it make the C code under the hood simpler?
Does it make PHP an order of magnitude faster?
I'm honestly just sitting here asking myself WHY anybody wants this,
and not finding any benefit at all.
I thin
Dmitry Stogov wrote:
Right now memory_get[peak_]usage() show the amount of REAL memory that PHP
(Zend Memory Manager) takes from system.
Previous memory manager showed size of emalloc()-ed memory without malloc()
overhead.
Also it didn't consider internal caches.
Shouldn't we make the old beha
Hi,
so it seems to me like several core developers think its a worthwhile
addition to core if the class is renamed to ZipArchive (if I understood
Pierre correctly in a private IRC exchange he is ok with renaming the
class).
The idea of a PDO for archives does not seem to generate much suppor
Hi Stefan,
I will put rfc1867 updating on my PHP6 todo list so in case it somehow
is forgotten I can try to remind you.
As for PHP 5.2 the key question is if you deem this production ready and
also if Ilia thinks its still in time to add this. From the words you
used I think it sounded a lot
Andrei Zmievski wrote:
FWIW, I'm fine with moving it into core if EXPERIMENTAL is removed and
it's renamed to ZipArchive.
Is that a new (double) standard? It used to be common practice to add
new extensions as EXPERIMENTAL to core. IIRC all the last PECL
extensions that got moved to core wer
Lukas Smith wrote:
Lukas Smith wrote:
Ok I see 2 options:
1)
Obviously one solution would be to disallow making anything an
E_STRICT notice that is not available since the first release of the
given major version.
Pierre and Anthony seem to favor this solution.
So it sounds like Derick
Edin Kadribasic wrote:
Richard Quadling wrote:
So where does this leave adding pecl/zip to 5.2? PDO is not core for
Windows so should zip?
PDO is bundled in the core PHP distribution. Pierre was not asking for
Zip to be enabled by default, just to be a part of the distro.
Yes, exactly.
As f
Derick Rethans wrote:
On Fri, 21 Jul 2006, Lukas Smith wrote:
Richard Quadling wrote:
I agree with this point. The sub class is a valid entity in its own
right. The methods (and the parameters) it has are part of that class.
If they overwrite a parent class's method, then fine. Instan
Richard Quadling wrote:
I agree with this point. The sub class is a valid entity in its own
right. The methods (and the parameters) it has are part of that class.
If they overwrite a parent class's method, then fine. Instance of
either class would have different parameters for the same named
met
Michael Wallner wrote:
Hi (Marcus),
unfortunately I'm not very happy with the direction OO strictness takes
in PHP. I'm sure I'm not alone and many people second this feeling.
Precisely, let's have a look at the following:
[EMAIL PROTECTED]:~/build/php-5.2-debug$ cli -d"error_reporting=8191"
Derick Rethans wrote:
On Thu, 20 Jul 2006, Pierre wrote:
Do you really ask me what Zip say?
You miss the point. If you do "new Zip" ... then I've no idea what the
object you get represents. However, doing "new ZipArchive" makes sense
as then you know the object represents a ZipArchive for e
Sean Coates wrote:
From my experiences the problem with this is many shared hosts wont install
non core modules, so the more modules moved from core to pecl the less
flexible php will be and the less use it will be.
I understand the need to keep the core code maintained and as clean and
lean
as
Ilia Alshanetsky wrote:
Class names are not case sensitive, so it does not matter if it is
FooBar or fooBar or even FoObAR.
Ilia, since PHP5 we are case preserving. So it does matter, though only
stylistically, not technically.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Maili
Michael Wallner wrote:
Andi Gutmans wrote:
I agree completely. Can't we just call the damn thing DateTime stick
it into
RC1 of PHP 5.2, and move on?
+1 for DateTime and DateTimezone; the flame was funny, but let's move
on, please.
+1
regards,
Lukas
--
PHP Internals - PHP Runtime Developm
Steph Fox wrote:
I already agreed with Pierre over this, and offered to support him in
giving PEAR support for upgrading. So long as it goes in from the start
of 5_3 branch, why not? (Like it should've done at the start of 5_2
already.) I think it's worth holding out for a few more months to g
Rasmus Lerdorf wrote:
I can see Andrei's argument for the iterator stuff where you do actually
have to type it often, but his identifiers are already unlikely to clash
and we could probably make an exception there.
Well then we need to document this!
In my proposal I also noted:
Iterators an
Marcus Boerger wrote:
All that nonsense above said. I just would like to see that we agree on
having an official todo thing like lukas' site. Actually we should do
that on php.net somewhere and have a selected group get cvs access right
to that and have changes mailed to internals@ so that peopl
Steph Fox wrote:
Yep, that's a fair point. But at the same time, PEAR should be
namespacing their classes - and in fact the date class in PEAR is
breaking PEAR's own coding standards in that respect. Why should classes
Steph stay on topic. Date follows current PEAR naming standards just
fin
Rasmus Lerdorf wrote:
I think we need to rename it. php_date or _date or something. I don't
really care what the name is, but I think we are too late in the game to
get the 'date' identifier. The other functions enabled are fine and
quite necessary actually. Both timezone_abbreviations_list
Ilia Alshanetsky wrote:
It's been quite sometime since 5.2 was branched and looking over our
"todo" majority of planned changes were made. Therefor I'd like to make
an RC1 on Thursday next week and start the stabilization cycle of 5.2,
so we can get a final in about 2 months. Once we start stab
Lukas Smith wrote:
Ok I see 2 options:
1)
Obviously one solution would be to disallow making anything an E_STRICT
notice that is not available since the first release of the given major
version.
Pierre and Anthony seem to favor this solution.
2)
Adding such a filter API into PHP internals
Pierre wrote:
if foo-1.2.1 is E_STRICT compliant with 5.1.4 and foo-1.2.2 with
5.2.0, update to 1.2.2 must be the way. It is the safest way, the past
shown us that some E_STRICT can be related to (sometimes critical)
bugs and we should treat them as bugs. Also, I do not like the
additions of ped
Antony Dovgal wrote:
Well, that's what major versions are for, right?
Bugfix releases are for bugfixes, while major versions may introduce new
things and features.
Err we add features in minor (and even patch level) versions all the time.
Sorry, I still fail to see a reason to "filter" erro
Antony Dovgal wrote:
Lukas, I thought we already discussed and agreed that the only
acceptable solution is NOT to add any E_STRICT messages if the
recommended way didn't exist in first release of the major version.
This apparently requires versioning and its support in PEAR.
And personally I t
Hi,
PEAR is currently in the process of deciding from when on we want to
mandate PHP5 as the target platform. Currently it looks like sometime in
the next 3-6 months we will likely only accept PHP5 only packages.
We are also pondering how to best approach E_STRICT. It is not feasible
for us
Marcus Boerger wrote:
Hello Michael,
yep, here too. track_errors is an optimizations when you don't
want to debug but simply use your app.
thats why i said that i would like to atleast be able to get the last
error without having to mess/check track_errors ini setting. i think
this is an a
Michael Wallner wrote:
- error_get_last()
Get the last error message.
my wish would be that this one should work even if track_errors is not
enabled.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hannes Magnusson wrote:
Hi all
I am sure this was decided upon long time ago, but there seem to be
few out there that do not want this...
should I revert array type hinting for internal functions or continue
adding them were appropriate while I add the argument info?
Just to be clear; I'm intro
Igor Feghali wrote:
I had my proposal about PEAR::MDB2_Schema accepted on SoC 2006. Lukas and
Pierre told to request an account here to be able to commit what I already did
in pear and peardoc. I also already introduced myself to the pear-dev list:
http://www.beeblex.com/lists/index.php/php.pe
Andi Gutmans wrote:
Yeah API docs is useful, but still we should have the end-user docs in
the PHP manual. I don't think once comes instead of the other. The
end-user docs is especially useful as people in the community can give
comments, etc...
Err, you misunderstood what I was trying to say
Andi Gutmans wrote:
Hey,
I'm obviously not an expert on this stuff so I don't have much added
value to add. However, I think from a high-level I think it's important
that we have one PHP manual and that the manual covers both functional
and oo extensions. I think the last thing we want is to
] (Lukas Smith)
To: [EMAIL PROTECTED]
Newsgroups: php.pecl.dev
Hi,
the following script outputs "false" (at least on whatever pdo version
is bundled with 5.1.4):
$sql = 'SELECT 1 FROM dual WHERE 1=0';
$stmt = $dbh->query($sql);
var_dump($stmt->fetch(PDO::FETCH_ASSOC));
al
Nathan Fredrickson wrote:
To assist Lukas Smith maintaining the PEAR MDB2 package. In particular, Lukas
has asked me to maintain the MDB2_pgsql and MDB2_mssql drivers. Thank you.
Yes he needs CVS karma for pear/MDB2
And he also needs developer rights for the MDB2_Driver_pgsql and
Marcus Boerger wrote:
As a follow up I've attached my initial patch for this. Can people
please review?
Without having looked at the implementation:
Does this implementation also deal with changes in the client encoding?
http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-St
Zeev Suraski wrote:
Marcus,
For the sake of world peace, let's say you're absolutely right. Let's
be done with this compat mode case study.
The important point is for the future - announce compatibility breaking
changes (removal of features, major changes to features) clearly on
internals@
Phil Driscoll wrote:
To move this process forward, is there any chance that you could make a few
changes to http://oss.backendmedia.com/ReleaseChecklist?
I have added a link to your post as a comment in the page. Since I am
not an RM I will leave it to Ilia and Derick to incorporate these ide
Jasper Bryant-Greene wrote:
I'm not necessarily suggesting that a release be delayed because *my*
application doesn't work, I'm just offering to test RCs against it and
report any bugs that it turns up. If the bug is found to be with PHP and
is sufficiently serious, then perhaps the release will
Ilia Alshanetsky wrote:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
I do not like the idea of changing the constants in a minor release. I
know "ALL" implies includes everything but I prefer to keep E_ALL like
it is and add an E_PEDANTIC (and default to that in the sample ini fi
Marcus Boerger wrote:
To rephrase Andi "So people screw up. I prefer having the occasional
screw up then less people helping out." We are a community [...]
What we need is more helping hands and less comlaining notes. Actually
we are constantly working on increasing or QA efforts. And from my
po
Ron Korving wrote:
Wouldn't it be nice to start a PEAR2 (or 5) then, with PHP5-ready code,
where PHP5 features will actually be used and backwards compatibility for
PHP4 is lacking. The current PEAR could gradually be ported into this, and
PHP4-users can continue to use PEAR (version 1, if you
Marcus Boerger wrote:
Sorry i have to say that but PEAR is no argument here as still after
years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing
a PHP 5 version here.
PEAR is PHP5 compatible. But you probably meant E_STRICT compatible.
Yes, I agree that PEAR needs to become
Derick Rethans wrote:
On Sun, 14 May 2006, Marcus Boerger wrote:
That said i am about to not remove E_STRICT from E_ALL and MFH the php
6.0 to item just now.
See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE (dmitry))
Since this is for the benefit of the users to prevent issu
Pierre wrote:
On Thu, 11 May 2006 14:15:53 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
Hello!
While I welcome new developments in either procedural or OO
interfaces in PHP I do not agree with breaking BC (between 5.1 and
5.2 in this case) just for the sake of OO purity. In this exam
Ilia Alshanetsky wrote:
discontinued. Over the last week a list of planned changes for the 5.2
have been compiled on Lukas' wiki (http://oss.backendmedia.com/PhP52).
I have updated the wiki page with Ilia's list. I added a few items that
I still marked as todo in my email client into the "o
Hi,
I would like to add two other project ideas:
1) Expand PEAR::MDB2_Schema to cover all aspects of schema evolution:
http://pooteeweet.org/files/phptek06/database_schema_deployment.pdf
2) Create a new set of classes to create/read/modify OpenDocument files
I would be interested in mentoring
Hi,
I updated my phptodo wiki for the next planned release. Ilia also send
me a bunch of items that I threw on there:
http://oss.backendmedia.com/PhP52
If you want me to be your personal secretary let me know what items you
are missing from the list, what items should be assigned to specific
Rasmus Lerdorf wrote:
Has someone been keeping a list of the ideas posted so far? If so,
please give me a URL for that so I can add it to the profile.
Nobody has added things to my wiki, but I can plow through the archive
over the course of the day and make a list available on the wiki.
re
Derick Rethans wrote:
On Sat, 15 Apr 2006 [EMAIL PROTECTED] wrote:
The following is a direct excerpt from the PHP manual on empty, and isset:
bool *empty* ( mixed var )
bool *isset* ( mixed var [, mixed var [, ...]] )
Is there a reason empty does not allow multiple variables at a time, as
isset
Gabor Hojtsy wrote:
Nuno Lopes wrote:
Google is doing their Summer of Code thing again this year. You can
read more about it here: http://code.google.com/summerofcode.html
This year I might participate. I would like to do something in the core
or even in the zend engine. I'll think in somethin
Lukas Smith wrote:
A few days ago I started a wiki for PEAR to get organized for this. But
BTW .. here is the URL
http://oss.backendmedia.com/PEARSummerCode/
The wiki can be used for other php.net projects of course as well.
Maybe just open a new page if needed.
regards,
Lukas
--
PHP
Steph Fox wrote:
Steph Fox wrote:
I wasn't thinking of writing something in PHP... there'd be no way
for userland code to 'see' half the stuff that needed changing.
I was not implying it would have to. But I also do not see why it
should not be possible to do it in PHP.
If you wrote somethi
Steph Fox wrote:
I wasn't thinking of writing something in PHP... there'd be no way for
userland code to 'see' half the stuff that needed changing.
I was not implying it would have to. But I also do not see why it should
not be possible to do it in PHP.
regards,
Lukas
--
PHP Internals - PH
Rasmus Lerdorf wrote:
I think we can lump them all together under PHP. And while having
suggestions is definitely good, we also need to stay open to interesting
proposals.
Ok, how do we get on that list?
Do we have friends inside google?
I poked some more and the stuff I first found seemed
Steph Fox wrote:
Is it a really stupid idea to suggest a script upgrading program a la
'autoupdate' (for 4/5 -> 6)?
It's something I hoped to tackle myself, but am unlikely to find the
time for.
Well if it works it could solve some issues. Like handling stupid BC
breaks (array_merge, class_
Rasmus Lerdorf wrote:
Google is doing their Summer of Code thing again this year. You can
read more about it here: http://code.google.com/summerofcode.html
A few days ago I started a wiki for PEAR to get organized for this. But
not much content has been generated so far. Only some ideas have
Andrei Zmievski wrote:
5.1.4?
I have the following items as future todos:
1. new functions: ext/date: date_sun_info (derick)
2. Switch for disabling/enabling materialized cursors in mysqli (georg)
3. fix __toString() (marcus)
4. add support for files >2GB (wez)
5. Add input fil
Yasuo Ohgaki wrote:
Wez Furlong wrote:
Regardless of whether it's a good idea or not, you should not just go
ahead and commit such a big behaviour change to the stable branch
during the release process.
Please revert your commit.
That's good point.
Any people should not depend on pg_execute's
Yasuo Ohgaki wrote:
> @ operator is ok, but usually @ operator is not recommenned.
> Don't you think so? I try not to use @ as much as possible.
>
> pg_execute() does not have to raise error just like file_exists().
> It may be good idea to raise error when connection is bad, etc.
the problem is
Yasuo Ohgaki wrote:
> Lukas Smith wrote:
>> Just to make it clear: calling pg_execute() on a not yet prepared
>> statement will cause your transaction to be rolled back on the next
>> commit. Encouraging the use of pg_execute() to find out of the statement
>> has been
Yasuo Ohgaki wrote:
> Lukas Smith wrote:
>> Yasuo Ohgaki wrote:
>>
>>> 3) add bool parameter to pg_execute()
>>>e.g. pg_execute(resource connection, string stmtname, array params, bool
>>> ignore_error)
>> how would you intent to implement this
Yasuo Ohgaki wrote:
> 3) add bool parameter to pg_execute()
>e.g. pg_execute(resource connection, string stmtname, array params, bool
> ignore_error)
how would you intent to implement this?
AFAIK there is currently no catalog to find out the prepared statements
in the current sessions (I hea
Lukas Smith wrote:
Ilia Alshanetsky wrote:
I'd consider it for PHP6, but not for PHP5.1 at least not at this time.
what exactly is the big deal with adding a new optional parameter?
i dont really see the huge impact that should push this feature back to
the next major php version
Ilia Alshanetsky wrote:
I'd consider it for PHP6, but not for PHP5.1 at least not at this time.
what exactly is the big deal with adding a new optional parameter?
i dont really see the huge impact that should push this feature back to
the next major php version. its something that could go int
Lukas Smith wrote:
Steph Fox wrote:
Where would you want to start UPGRADING from?
The main problem I faced with the 5.1.0 version was not knowing how
far back to go... or what to count 'in'. E.g. something that was only
in CVS for a few weeks and no releases - should that b
Steph Fox wrote:
Where would you want to start UPGRADING from?
The main problem I faced with the 5.1.0 version was not knowing how far
back to go... or what to count 'in'. E.g. something that was only in CVS
for a few weeks and no releases - should that be included?
Needs some thought for 6.
Nick Mitin wrote:
I was trying to create 2 mysql connections.
this is a user question and should therefore not be directed at the
internals list..
1) persistent connections have issues:
http://de2.php.net/manual/en/features.persistent-connections.php
2) use the new link parameter to get a n
Dmitry Stogov wrote:
We already have exceptions, so we don't need another longjump :)
"jump" or "goto"? Just make common decision and I will change it.
Dmitry, maybe I have overlooked a single post, but I have yet to see a
single post favoring "jump" over "goto". The common decision is here a
Hi,
I am wondering why does defining a php5 style and php4 style constructor
in a class result in an E_STRICT warning, where as only defining a php4
style constructor does not?
class foo {
function __construct() {}
function foo() {}
}
class foo2 {
function foo2() {}
}
I could
Steph Fox wrote:
Perhaps there could be just the one hard rule. 'If it's possible to
implement it as an extension, do so.' There'd be nothing to prevent
co-opting essential functionality into the core, but also nothing
preventing fly-by-night technologies from having support in PHP. The
bigge
Dmitry Stogov wrote:
Hi,
Because of some confused people I reverted "break label" patch and post it
for discussion once again together with GOTO patch.
Please reviw and vote.
1) goto and break label
+1
2) goto only (like C)
+1
3) break label only (like Java)
+1
4) nothing
-1
reg
Zeev Suraski wrote:
The point is that breakage is aggregated, not binary. The more stuff we
break, the more difficult it is to port, and frankly, it's quite likely
that a non OO app could migrate fairly cleanly even to PHP 6 with
unicode disabled (perhaps with minor fixes). get_magic_quotes_
Sean Coates wrote:
it's not the problem of the second foreach, any usage of $j after the
1st foreach as &$j will hurt
Yes. I thought it was clear that I understand this. I guess not.
My point is that foreach is doing something that isn't immediately
obvious. The same is true of your for loop,
Ilia Alshanetsky wrote:
It has been a while since our last release and we have a fair number of
bug fixes and minor improvements accumulated, so it's time for 5.1.3. My
goal is to have the release out by March 30th, with 2 RCs between now
and then to let us test everything out.
I have updated
Derick Rethans wrote:
On Thu, 2 Mar 2006, Jeff Moore wrote:
Unfortunately, the problem with making self late binding is that that there
are potential BC breaks. Is that possibility on the table?
I don't think we should break any BC over this.
Neither do I.
regards,
Lukas
--
PHP Internals
Marcus Boerger wrote:
Hello Lukas,
no the way things are now are just as expected.
my point was this:
why even bother with self:: ? you could just as well use the class name.
its just syntactical sugar .. however late static binding actually gives
you a useful feature (well one could argue
Dmitry Stogov wrote:
Patched PHP will modify zend_function->caller_scope at runtime.
This can break ZTS version and probaby opcode caches.
Storing runtime information in zend_function is bad decision.
maybe stating the obvious here .. but opcode caches are important to
everybody on this list
Zeev Suraski wrote:
1. I don't think it's a very important feature, even though like any
other feature we could possibly think of, we can come with use cases
where it would be useful. In terms of complexity vs. usefulness, I
think it's more complex than useful.
So how about this ... make
Jochem Maas wrote:
rather than an alternative form of static method calling or a new class
related keyword, maybe a new magic constant would be sufficient? e.g.
__CCLASS__ (C for 'Called')
or
__OWNER__ (the class the 'owns' the method? [from the view point of
the caller])
i dont re
Zeev Suraski wrote:
I actually don't recall there was consensus on even adding this feature
in the Paris meeting, let alone how to name it.
To quote the meeting results as linked in Mike's original post:
1. We re-use the "static::" keyword to do runtime evaluation of statics.
2. Marcus
Dmitry Stogov wrote:
Yes I like not a sintetic test but real life example (singleton, factory or
something else).
(I tried to write generic singleton but it wasn't exelent.)
Yeah a singleton method that calls a factory method is a prime example.
Now if you want to inherit that class you will
Dmitry Stogov wrote:
1) I would very like to see some real example where "static" is necessary?
I think Mike illustrated this in his post. Or do you want a "real" world
example?
2) "static" is really bad name. I suggest "caller", Marcus thought about
"class".
I dont really see an issue wi
Mike Lively wrote:
As far as current userland code impact, there is very little as far as I
can tell. No keywords have been added, just another use for an existing
one. No changes were made to self:: or parent:: so the change should be
pretty transparent. The only thing that I see remotely causi
Hartmut Holzgraefe wrote:
Wez Furlong wrote:
I think not many people use it because it's difficult to use.
Having real labels might change that.
Personally, I'd prefer real goto, as I've stated in the past.
Just for the record again, I'm +1 for goto, and +0.5 for labelled
breaks only if we've to
Andi Gutmans wrote:
Yes, this was by design. Via class it should be ::method() and via
object it should be ->method().
Why do you think this is wrong? I think it actually makes a lot of sense
and don't see what we gain from allowing to call self->method(). If
there's a good reason, I'd be open
Andi Gutmans wrote:
At 04:25 AM 1/21/2006, Jared Williams wrote:
What are the security implications of doing this?
Creating objects based on a string from a untrusted source seems not
good idea, unless can prevent tampering (with an HMAC or
something).
Well I think the right thing to do is p
Ilia Alshanetsky wrote:
Each programming & scripting language has its strengths and areas of
focus. Just because another language implements a feature, does not mean
the rest should follow suit. What you fail to realize that every feature
adds to the language complexity, making it more difficult
Hartmut Holzgraefe wrote:
Lukas Smith wrote:
Its sole purpose is to deal with situations where you have a
considerable number of parameters.
well, i for one would love to write something like
$pos = strpos(haystack=$str, needle="foobar");
instead of looking up parameter orde
Hartmut Holzgraefe wrote:
Lukas Smith wrote:
- all internal and PECL functions need to be recoded as the API
right now doesn't know any concept of parameter names at all
I was thinking that this would a userland only feature.
do we really want to add even more inconsistencies t
1 - 100 of 318 matches
Mail list logo