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.
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
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
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
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
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.
Err
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
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,
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 impossible
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
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
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
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
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
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
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 -derror_reporting=8191
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
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. Instance
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 error
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
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
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
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
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
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:
] (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));
all other RDBMS extension we
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
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
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?
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
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
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
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
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
Marcus Boerger wrote:
offtopic
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
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:
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
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
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
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
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
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
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,
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:
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 -
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
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
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
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
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 prepared is therefore wrong
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 a
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
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. its
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
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 be included
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
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
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).
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
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
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
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 with
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
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
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
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
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
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
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
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
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
Andi Gutmans wrote:
In my opinion, as Ilia stated passing an associative array does the job
quite well for the use-case where named arguments would be useful.
Sure it might be a tad-bit sexier that you don't have to write array()
but the truth is that the implementation would probably still use
Hartmut Holzgraefe 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.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To
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
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 orders all the time
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
Ilia Alshanetsky wrote:
I think we should avoid complicating an already complex OO
functionality. Borrowing concepts from other languages is fine, but to a
degree.
I think the PHP real world (not the guys porting Java APIs to PHP)
requires support binary only:
public API
my break at any time
Andrei Zmievski wrote:
If you get to the point where your function has a dozen parameters, I
would suggest re-thinking the purpose and design of such a function,
because you are likely trying to make it do too much.
Obviously for most methods you should not require more than say 5
Stanislav Malyshev wrote:
MB but that is a way of having __call that obviously doesn't fit the real
MBworld. In a real world application i only implement a few things with call
MBand dislike having all the others implemented automatically also. And the
MBi have to care about error generation
Stanislav Malyshev wrote:
LSI think its obvious that you can implement things in userland or inside the
LSengine. The main advantage of doing it inside the engine is that it then
LSbecomes the standard way of doing things, where as with userland its likely
LSthat several competing standards will
1 - 100 of 283 matches
Mail list logo
