it, but I know I'm not the one coding it. :-)
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which
not the one coding it.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively
, what?
I'm reluctant to trust any benchmarks from this script until I figure out why
it's behaving like that, so any advise would be appreciated.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all
mechanism.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long
forget, it won't work.
And yes, you will grumble a bit at that, but that is nothing compared to
trying to find a bug caused by a global side effect in someone else's
code. Trust me, you will grumble a lot more at that.
-Rasmus
--
Larry Garfield AIM: LOLG42
[EMAIL
that is going to make me want to kill the programmer who wrote it should be
difficult, not easy. :-)
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property
, and I don't want to duplicate any code
(dbField and inputField are both pretty big, and any modifications will
also have to be replicated).
And no, I don't want to use interfaces. Interfaces will barely do
anything for me, I'll still have to duplicate my method bodies, and
properties.
--
Larry
to use interfaces. Interfaces will barely do
anything for me, I'll still have to duplicate my method bodies, and
properties.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive
On Monday 19 November 2007, Edward Z. Yang wrote:
Larry Garfield wrote:
It sounds like you want to be using decorators instead.
The decorator pattern is inappropriate for this case, because Sam wants
to extend the interface, not change the behavior of an existing one.
class AbstractField
);
}
static public function set($name, value) {
self::$data[$name] = $value;
}
}
summary: why fix what ain't really broke...?
Cheers!,
--
Carl
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature
,
$generator_of_some_sort, 'MyIterableClass');
Would that alleviate the oh god it's two things problem without
causing too many other issues?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the passing semantics for objects
and we survived that, and it was a big boon to the language. Perhaps
that could be rolled into bigger changes later? (There's a PHP 6 thread
right now I've not looked at yet...)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
looking at someone's code; I can't even read it otherwise anymore. Any
respectable coding standard requires the otherwise-optional braces.
And yes, I always close my /p tags as well, and so should you! :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
There is no such thing as an optional closing tag or brace. There's
only lazy and sloppy coders, and parsers that encourage them.
--Larry Garfield
On 7/19/12 10:52 AM, Andrew Faulds wrote:
Always close p, but never close li :)
On Jul 19, 2012 4:44 PM, Larry Garfield la...@garfieldtech.com
should use
this gap to break BC and add new cool ideas like this one, we seem all
to agree with.
Julien.P
Agreed. We survived Objects becoming, er, Objects in PHP 5.0. Arrays
changing would be a major version change, but if the benefits are
enough, we could survive that, too.
--Larry Garfield
as single page where you point people when to
convince them
to upgrade.
+ =)
--Kris
Speaking as someone who has to deal with vendors that are still being
stubborn about upgrading from PHP 5.2, and who was the lead organizer of
the GoPHP5 project years ago, dear god please yes!
--Larry
unreachable?
(I have no clue what the behavior should be in these cases, just that
it should be sorted out sooner rather than later.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, with the engine
internal implementation details completely irrelevant. (Which means
they can be changed later if needs be.)
I don't know which mental model is intended, nor which one would be
better, but that is, I believe, the question that should inform the rest
of these discussions.
--Larry
On 10/26/2012 05:43 AM, Clint Priest wrote:
I'm opening up several new threads to get discussion going on the
remaining being debated categories referenced in this 1.1 - 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
On 10/27/2012 09:38 PM, Larry Garfield wrote:
On 10/26/2012 05:37 AM, Clint Priest wrote:
I'm opening up several new threads to get discussion going on the
remaining being debated categories referenced in this 1.1 - 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
is the worst case
scenario.
--Larry Garfield
On 10/27/2012 10:59 PM, Clint Priest wrote:
Hey Larry,
Glad you chimed in here on this. I my opinion (author of thingy),
they are separate and distinct from data members. More specifically
they are getter and setter code that is called when the property
There are still use cases for __get(), when the list of internal
properties is dynamic. We're actually leveraging that for Drupal 8's
entity system. Removing it would be a big problem. :-)
But that still doesn't resolve the mental model question.
--Larry Garfield
On 10/30/12 3:05 AM
, is there?
There is not. This is a task for the FIG group, not Internals.
--Larry Garfield, Drupal rep to the FIG group
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
try to avoid using them myself, including large enterprise hosting
services.
(I'd love to be pushing to PHP 5.4 faster, but the lag time for
distributions and hosts is painful.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
$replacements-next();
},
'word word word word word'
);
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
if anyone in userspace is using
DateTimeImmutable...
--Larry Garfield
On 12/17/12 2:52 PM, Lars Strojny wrote:
Hi Derick,
I would go with DateTimeValue or DateTimeImmutable as well.
Am 17.12.2012 um 19:42 schrieb Benjamin Eberlei kont...@beberlei.de:
On Mon, Dec 17, 2012 at 5:48 PM, Derick
On 12/19/12 10:30 PM, Christopher Jones wrote:
On 12/19/2012 03:18 PM, Larry Garfield wrote:
You could likely simplify the code even further using an infinite
iterator:
http://us1.php.net/infiniteiterator
$result = preg_replace_callback(
'/word/',
function($matches) use
the next 6 hours tracking it down, until he
realizes what he did and proceeds to bang his head against his desk in
frustration for missing such a simple error.
Let's not subsidize the headache drug manufacturers with PHP syntax
decisions. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime
to
be successful. It could certainly go farther, but it cannot go less-far.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
would be beneficial.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
or group that leads.
Relevant:
http://www.jofreeman.com/joreen/tyranny.htm
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
there is, I suppose, a mystery for
the ages.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
next year it will be time for a GoPHP5.5 project. :-) Hopefully by
then WP will have become less conservative enough to join the effort.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to Palm OS.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 1/29/13 12:31 PM, Steve Clay wrote:
On 1/29/13 11:55 AM, Larry Garfield wrote:
[3] We have a CI system in place but it's home grown, doesn't have
enough human resources
maintaining it, and I don't think it supports multiple variants of the
PHP environment
Dunno if this was mentioned here
the barrier to testing new
versions by several orders of magnitude. (Yeah yeah insert RPM vs. Apt
debate here; both are good to have.) That would be *sweet*. +1
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
things, that is the gulf that needs bridging.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
/
If you're using Composer to manage dependencies, it includes a fully
capable PSR-0 autoloader that just works, as well as a classmap-based
option. If you're not using it yet, you should. All the cool kids are.
http://getcomposer.org/
--Larry Garfield
--
PHP Internals - PHP Runtime Development
://socketo.me/
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
).
Naturally some optimizations are harder to do than others given PHP's
architecture, but trading more expensive compile for cheaper runtime,
even if not a 1:1 trade, would be a win IMO.
--Larry Garfield
On 4/10/13 9:16 AM, Dmitry Stogov wrote:
For now, the optimizations we do are quite chip.
They may
. Trying to expand beyond that
will run right smack into the ancient battlefield of strict typing
discussions, and the ghosts of brave souls that have fought and died
upon it. :-) I'm pretty sure that would kill the proposal in OT chatter.
--Larry Garfield
--
PHP Internals - PHP Runtime
. If
anything, if properly used it makes it easier for forks to come back
into the fold later if all parties agree to do so. It's really all a win.
Our Windows-based developers also have not really had an issue. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
be a smart move for PHP; any limitations that
the GitHub model imposes are just that, impositions of the GitHub
model. There's no reason that Git has to be used in that fashion if
some other model would fit PHP better.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
that the outside world saw). That sort of practical experience should
be helpful in determining some of the finer points of how you'd actually
DO that for a project like PHP.
--Larry Garfield
On 8/17/11 3:13 AM, Lester Caine wrote:
At the risk of being criticised again, I will lay out a couple of
problems
.)
I can't second Pro Git enough as a fantastic resource.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
yourself immune to prosecution by taking down an
allegedly infringing work immediately, without bothering to check to see
if the claim is bogus or not.
It's a wonderful world we live in.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
of PHP's
great weaknesses. I think this entire thread has shown that very well.
That is something that needs to be addressed, just as much as
inter-framework communication does. Perhaps moreso.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
that it is happening, what do
we do? 'No thanks', for whatever reasons. That's so wrong.
Actually it's the second. The first big agreement was GoPHP5, which is
how we finally buried PHP 4. :-) Sadly that momentum didn't continue
(in part my fault).
--Larry Garfield
--
PHP Internals - PHP Runtime
strict adherence to a doc page. However, PHP has always been an
implementation is the standard language, which means this is a
language API change.
Please roll it back to avoid breaking a crapton of existing, legitimate,
non-buggy code.
--Larry Garfield
--
PHP Internals - PHP Runtime
the interfaces of an object it decorates?
That's... I don't know if that would work, honestly. :-) It also goes
to the inevitable tug-of-war behind being a strict language vs. a
dynamic language.
What are your thoughts?
Anthony
Cautiously positive on the concept.
--Larry Garfield
--
PHP Internals
from inheriting it
from PDO.
If that doesn't change, then I rescind my previous panic attack.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
reasons.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, and 'not our problem' from yawk
- SEP (Someone else's problem) from cjones
I was recently introduced to the concept of the Level 8 error. (Let's
see who gets that one...)
Anyway, +1 from me as well to friendlier, less accusational issue statuses.
--Larry Garfield
--
PHP Internals - PHP Runtime
is normally rather memory hungry.)
--Larry Garfield
On 2/6/12 1:52 AM, Dmitry Stogov wrote:
Hi,
I've just rerun some synthetic and real-life benchmarks.
All the test were run on the same box (Linux, Core2 Duo 3GHz, 4GB RAM).
5.3 and 5.4 where configured and build with the same options and ran
. An exception would make a lot more sense, and allow us
to centralize handling of such exceptional cases rather than throwing
if-checks everywhere. (Which is exactly what exceptions are for.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
are for.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Seems to me this change would encourage bad habits (breaking the law of
Demeter) which would personally put me against it.
Regards
Peter
How? What bad habit
, and
something sorely missing in the language today) should be based on one
of those, where there's already existing work done to work out the
kinks. Simply throwing $_GET onto a property of a superglobal object
does not accomplish anything useful.
--Larry Garfield
--
PHP Internals - PHP Runtime
On 2/24/12 4:34 PM, Richard Lynch wrote:
On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote:
On 2/24/12 3:28 PM, Richard Lynch wrote:
Because GET and POST are not even remotely the same thing and treating
them as completely interchangeable is a bug in the first place.
We'll have to agree
.
I am genuinely curious to see how you managed to interpret anything I
said as POST is secure because it won't be cached.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
data should be
viewed as a threat until proven otherwise, regardless of what part of
the HTTP request it comes from or what superglobal PHP marshals it into
by default.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
,
and made worse by the existence of $_REQUEST, but is the assumption that
PHP makes.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
That, at least, no one has any pre-conceived definition of.
--Larry Garfield
On 2/27/12 4:31 PM, Kris Craig wrote:
Would firm work better?
--Kris
On Mon, Feb 27, 2012 at 2:27 PM, John Crenshawjohncrens...@priacta.comwrote:
-Original Message-
From: Kris Craig [mailto:kris.cr
?
Please un-confuse me!
(Note: Sending this to internals since this is an engine question, and I
am more likely to reach whoever it was that un-sucked readfile()
sometime in the silent past that way. g)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
, the readfile() will kill your memory, don't use
it line is a persistent urban legend that belongs on Snopes as
debunked. Looping on fread() for performance is a red herring.
Is that an accurate summary? If so, I will blog my benchmark results
and this conversation.
--Larry Garfield
On 4/30
fine.
Let me re-create with a simple test script and share my server details
before we call snopes :)
Fascinating. I even verified the md5sum of the file I got on the other
end just to be sure. I'll hold off on the blog post then. :-) I look
forward to your test setup.
--Larry Garfield
the output buffer explodes. :-)
So, I think we're back to urban legend territory.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 05/01/2012 11:40 AM, Larry Garfield wrote:
On 5/1/12 10:01 AM, Paul Reinheimer wrote:
Hi All,
Unfortunately, you've ignored Uwe's e-mail... The problem is not the
PHP
version; the problem is that you're buffering unlimited amounts of
data.
Check your configuration and make sure
it directly. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, which currently we cannot do. And closures/lambdas
could/should support the same syntax for globals.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
resolve the issue you're describing.
--Larry Garfield, not a git expert by any means, just repeating what he's been
told by people who know more than him
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, a sort of sideways extends,
that would become much simpler. I'm not sure what that would look like,
though.
Or perhaps this is a good time to revisit the traits proposal from a few
months back?
--Larry Garfield
On Monday 15 March 2010 12:36:32 pm Hector Virgen wrote:
I also ran
, or at least ameliorates, these sorts of
issues.
Or perhaps there's a different approach besides traits that would work better.
I dunno. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
I'm not against a more planned, frequent release cycle but I want to make sure
that the upgrade treadmill is kept walkable or else it won't matter that PHP
has new features.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
every so often. Otherwise they just won't upgrade ever.
Most run on very thin margins.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
is integer data because that column is an int in the
database itself. Requiring an extra blind (int) stuffed in there is pointless,
and if anything just trains people to blindly cast data without thinking about
what it really is. I can see that introducing more bugs than it avoids.
--Larry
that
falls into the really suck category and should also explode. (float(5),
however, has no data loss in that operation so it's safe.)
I don't know if there's performance issues to address with that addition that
may nix it, but that would be the ideal.
--Larry Garfield
--
PHP Internals
at all.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
amazing what a little wording can mean, especially to new contributors.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
by ::$ that I can recall.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
Best regards,
--Matthew
Especially given how common it is to use hex constants as bit flags, being
able to define them in binary to begin with would help readability. (Yes, I
just said writing in binary would help readability. God help us all. g)
+1
--Larry Garfield
--
PHP Internals - PHP
-space?
I think that's the missing piece here: The practical ever-day example of how
*my* code would get better because of annotations.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
not quite yet. Off-by-default is absolutely necessary if they're
kept. (Dear god, you mean they aren't off by default already?)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
for the past year or so on various projects.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
more complex (for
me visually scanning it, for an IDE parsing it, etc.) in order to save a few
characters. Bad trade-off.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
developers writing
code that fails both of the above.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
introduce inheritance. If a child class has a
[property|class member] of the same name as a parent's [class member|
property], then what?
That's all I got for now. Once again, nice RFP but still needs some thinking.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
The Drupal project's decision making process for moving to Git is documented
extensively here:
http://groups.drupal.org/node/48818
Just another data point.
--Larry Garfield
On Wednesday, December 01, 2010 2:52:53 pm dukeofgaming wrote:
Hi,
I was following this path to push the adoption
enough without introducing wave/particle duality.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
DateTimeValue class that subclasses
off DateTime (or even better, introduce a new interface that they both
implement) that is essentially identical but is immutable. That would make it
much easier to code against.
--Larry Garfield
On Saturday, December 04, 2010 6:11:37 pm Benjamin Eberlei wrote
I'm done harping on this point now, I hope... :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-class code
structures, don't they? Autoloading a variable doesn't even make sense to me,
and include files are already handled by include[_once].
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to the super-globals:
http://us3.php.net/manual/en/book.http.php
Note: I have not actually used said library, just drooled over having a
properly abstracted HTTP object for incoming and outgoing communication.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
of a method) so that it can
provide what the trait needs, or a trait needs to be able to carry around its
own implementation details.
So it seems to me like we can't not let traits carry properties, which means
we need to resolve them some how.
--Larry Garfield
--
PHP Internals - PHP Runtime
traits?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
separate them I can see a use for clustered autoloading,
certainly, and namespace is a not-unreasonable definition of cluster.
Cons :
- none
- well, one : I don't speak C, so I dont have any patch...
I sadly have the same problem. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime
it is. (In practice my use case has a vastly larger
array, so any inefficiencies are multiplied.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
,
poink/narf = 8 ZVals? (That seems logical to me because each its its own
variable that just happens to be an array, but I want to be sure.)
--Larry Garfield
On Wednesday, January 19, 2011 1:01:44 am Ben Schmidt wrote:
It does the whole of $b. It has to, because when you change 'baz', a
reference
of a general algorithm.
Thanks again!
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, and provide an easy way for different
PHP projects to share backend code without needing lots of C developers.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
101 - 200 of 1363 matches
Mail list logo
