ints, but they sound valid from the outside, at least. Not
steering people toward "well just throw casts around" is something to
keep in mind.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
n address the issue people are
talking about for the 5th time. :-(
An exact replica of FIG's process is probably not going to fly for
Internals for various good reasons, but it can hopefully serve as a
source of ideas.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that preceded it, but I don't
think many people would disagree that adding such structure has greatly
improved PHP and the tone of this list. Structure is not a bad thing;
bad structure is a bad thing. It's important to understand the difference.
Your opinion of FIG is noted, but don&
On 02/17/2015 12:48 AM, Sara Golemon wrote:
Don't mistake me for hack. -Sara
No one could ever mistake you for a hack, Sara. :-)
--Larry Garfield
(Sorry, it was just sitting there...)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
in some cases.
I started this email planning to ask Anthony how flexible strict
checking could get without losing the benefits of it, but I think I've
just convinced myself the answer is "not very". Which then leaves only
the question of internal functions that Rasmus raised, which... it looks
like is discussed in later emails so I will try to catch up on those. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 02/19/2015 04:13 AM, Zeev Suraski wrote:
-Original Message-
From: Larry Garfield [mailto:la...@garfieldtech.com]
Sent: Thursday, February 19, 2015 9:00 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Reviving scalar type hints
On 02/17/2015 01:30 PM, Zeev Suraski wrote:
Yes, I
On Feb 20, 2015 11:08 AM, Anthony Ferrara wrote:
>
> Zeev,
>
> On Fri, Feb 20, 2015 at 10:24 AM, Zeev Suraski wrote:
> >
> >> On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara wrote:
> >>
> >> verification and static analysis aren't enough?
> >>
> >
> > Anthony,
> >
> > While IMHO they're n
the proper name for "the thing that
corresponds to a URL" in REST. I would be shocked if there aren't
classes named Resource (namespaced or not) floating around in web
services code. I actually started writing one myself at one point on
the side but got distracted by something
ny
That makes me very sad, as whether the strict option is there or not I'd
*really* love to see scalar hints in PHP 7 to complement return type
hinting.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
k I'd need to first cast all of the elements in that array to
ints... which I'm not actually sure how to do cleanly.
I'd much rather we tighten up the rules around implicit casts generally,
as discussed elsewhere, and then allow those "loose but not as loose as
we have now" ru
a really solid release worthy of the major version increment.
Right now I'm not sure the feature list qualifies. Add in scalar typing,
annotations, etc and now we're taking. (There was talk of async supporting
features, to, but I don't know if anyone was actually working on it.)
I won't be able to rely on it for a few years anyway until distros and hosts
catch up, so 3-4 months doesn't impact me at all. :-)
--Larry Garfield
document the class), extend it, and build meaningful functionality and
defaults using an already well-known syntax and convention.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
/ low-UTF-8?
Wouldn't someone in Novsibirsk want it to generate a random Cyrillic string?
That said, I am +1 on the original proposal. It's in the similar vein
as password_hash(): If users have to think, they'll screw up. Don't make
them think.
--Larry Garfield
--
lass.
Of course the code that _reads_ the annotations still depends on the
annotation classes it cares about.
2015-02-25 5:27 GMT+01:00 Larry Garfield :
On 02/21/2015 03:35 PM, Pavel Kouřil wrote:
I know you could wrap it in your code, but that would still mean there
would probably be multipl
Bill Gates will just redefine Darkness(TM) as the new industry
standard.
--Larry Garfield
(Sorry, it was just such an obvious opening...)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
eone hit me for that?)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
pens.
In any case, my point is that we don't need to make it an either/or
question. These are both viable, logical extensions to adding basic
scalar typing, but not mutually exclusive and no need to turn into
"camps". If both pass, that's OK. Really, it's OK.
all points.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
parameter order issue as well) rather than just duplicate
function names.
This is at least the third time we've had this thread and come to that
same statement. I agree with it.
So what's the blocker on discussing Nikita's work for core?
--Larry Garfield
--
PHP Internals - P
live for at least the next decade. Offering a
substantially better alternative does improve the language. Don't waste
your time on marginal not-even-improvements.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
alias just adds to the confusion.
^^ What Rowan said. "adds to the confusion" is not "will not hurt
anything, almost".
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
m down.
I know you feel strongly about this, but you're not the first. It's
counter-productive and won't even address the marketing issue you note.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Regards,
I concur. I don't see much advantage of a short hand in this case, but
I would love to see someone pick up both the property RFC (which implied
short-hand getter/setters) and shorthand constructors. (It's undoubtedly
too late for 7.0, but they'd be great additions for 7
.
If for some reason more than a binary question is necessary, at least go
for instant-runoff style voting as that can represent "if not X, then Y
is at least tolerable" better than any mechanism currently in use in
Internals.
--Larry Garfield
--
PHP Internals - PHP Runtime Developme
elf for being stupid and
not just making a proper object, factory, DI, or any number of other
options are are 10x more testable and reusable and verifiable. Sure
there's places you could use it; there's just much better options
already available in the language and have been for a dec
iled versions of user land code?
With an opcache built into core and discussion of it moving into the
engine I think that's a given, in practice. That's entirely unrelated to
typing, though.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
If you're going to behave this way in public, please just leave the
project for good. It will be good for the project.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
happen, especially Andrea
for figuring out how to actually do it and Anthony for impressive
perseverance.
Does this mean this RFC can/should be withdrawn as redundant:
https://wiki.php.net/rfc/reserve_more_types_in_php_7
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To
m. (I suspect it
has/will ameliorate a lot of implementation-level issues with old
proposals.)
Personally I'd be in favor of such a syntax but I don't recall the
objections in the past beyond "meh, sugar".
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
;s archives are quite
extensive. (People here are verbose):
http://php.net/mailing-lists.php
http://marc.info/?l=php-internals
Also, no top-posting, please.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
on-blocking PHP (which
I also fully support in concept).
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
:-) The "badly
designed" claim is off topic and I will not respond to it.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
://github.com/decanus/JSON-Aware/tree/master
Regards,
Dean
I'll ask before someone else does...
Why does this need to be in PHP core? Why can't it be done purely in
user-space PHP code? The syntax would be different, fine, but how is it
functionally better in C?
--
--Larry Garfiel
On 07/10/2015 07:37 PM, Kris Craig wrote:
On Fri, Jul 10, 2015 at 2:39 PM, Larry Garfield
wrote:
On 7/10/15 3:27 PM, Dean Eigenmann wrote:
Hello,
I have a proposal for PHP. The proposed interface would allow developers
to decode json into a custom object directly. If given the approval I
On 07/10/2015 11:57 PM, Kris Craig wrote:
On Fri, Jul 10, 2015 at 7:07 PM, Larry Garfield
wrote:
On 07/10/2015 07:37 PM, Kris Craig wrote:
On Fri, Jul 10, 2015 at 2:39 PM, Larry Garfield
wrote:
On 7/10/15 3:27 PM, Dean Eigenmann wrote:
Hello,
I have a proposal for PHP. The proposed
clearly wrong and the compiler can
check it for you.
That's what the benefit would be. Easier IDE auto-completion is a nice
extra, but not the main goal.
+1 from me in 7.1.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
se and hope the
user knows what they're doing", even if the latter is currently more
common in PHP itself. Especially as we're talking not about a user
error but a "your system is not setup right so it will never work"
situation, as I understand it.
--Larry Garfield
--
PH
On 07/26/2015 01:36 PM, Jakub Kubíček wrote:
Hi Larry!
2015-07-26 1:29 GMT+02:00 Larry Garfield :
Another point here is that 0 is a perfectly legitimate random number in many
cases, so callers would need to do a === check, not just a boolean check.
What "boolean check" are you tal
7;s a kinda pointless function), so when we
were working on enums it never occurred to us to think about it. It wasn't a
deliberate decision to omit, as far as I recall.
I think I'd be open to adding it; my concern would be the overlap with
get_declared_classes(), which as you note currently would include enums, and
changing that is a BC break (even if a tiny one that I doubt would impact
anyone).
--Larry Garfield
eep');
$h = new Outer::Hidden('beep'); // Visibility error
I would have to research to see if other languages did this, but one option
would be to allow an inner class to extend an outer class even if it's final,
which would essentially give us sealed classes for free:
final class Outer
{
class InnerA extends Outer {}
class InnerB extends Outer {}
class InnerC extends Outer {}
}
// But this is still not OK:
class Sibling extends Outer {}
Note: I have no idea how difficult/complicated this would be, but I would be in
favor of exploring it.
--Larry Garfield
ffectively set in stone forever, rather than
something you can adjust based on future feedback, "YAGNI" becomes an actively
harmful approach to system design.
--Larry Garfield
if that will impact
__toString() at all. It may, it may not, we don't know. So for now we're
keeping our options open by disallowing __toString(), in case it ends up being
needed for some ADT-related behavior in the future.
Point 2 will, hopefully, resolve itself in time once we can get ADT support in.
Point 1 will remain, however.
--Larry Garfield
l questions (eg, impact on
get_declared_classes()) that it warrants an RFC process/discussion.
--Larry Garfield
hat naturally leads to the question of whether monomorphized
interfaces would be possible, and I have no idea there. (I still hold out hope
that Levi will take another swing at interface-default-methods.)
Though this still wouldn't be a path to full generics, as you couldn't declare
the inner type of an object at creation time, only code time. Still, it sounds
like an area worth considering.
--Larry Garfield
or making worker-mode a
first-class citizen, or at least a one-and-a-half class citizen, rather than
its current second-class status.
--Larry Garfield
at seems unwise as long as PHP still has an option to
remove comments/docblocks at compile time. Even if it's not used much anymore,
the option is still there, AFAIK.
And that's before we even run into the long-standing Internals aversion to even
recognizing the existence of 3rd party tools for fear of "endorsing" anything.
(With the inexplicable exception of Docuwiki.)
--Larry Garfield
On Fri, Aug 23, 2024, at 1:38 PM, Rob Landers wrote:
> On Fri, Aug 23, 2024, at 20:27, Bruce Weirdan wrote:
>> On Fri, Aug 23, 2024 at 4:27 PM Larry Garfield
>> wrote:
>>> Moving those definitions to attributes is certainly possible, though AFAIK
>>> bot
t.) In practice, I think a majority of those expressions would be
logically nonsensical, so I wonder if it would be better to only allow a few
reasonable ones and block the others, to keep people from thinking nonsensical
code would do something useful.
--Larry Garfield
On Sun, Aug 25, 2024, at 10:29 AM, Bilge wrote:
> On 25/08/2024 14:35, Larry Garfield wrote:
>> The approach here seems reasonable overall. The mental model I have from
>> the RFC is "yoink the default value out of the function, drop it into this
>> expression emb
same as just doing it, so let's
just do it. But if we can verify but it will be a lot more work to do, then we
could postpone that.
* I could deal with the custom collection syntax, but I'd much rather have real
reified generics and then build on top of that. That would be better for
default);
So far those are the two use cases I can realistically see being helpful, and I
acknowledge both are. I recognize that "limiting the allowed expression
structures arbitrarily is way harder than it sounds" is a valid argument as
well. At the same time, John C has offered some valid examples of cases where
it would open up additional footguns, and we want to minimize those in general.
Those shouldn't be ignored, either.
At the moment I'm on the fence on this RFC. I could go either way right now,
so I'm watching to see how it develops.
--Larry Garfield
php.net and direct people to it. I'd favor a one-off vote to allow talking
about Composer/Packagist in the docs, and I would vote yes on it. I'd probably
vote no for a one-off vote to mention Twig.
PHP.net is the starting point for people in the PHP ecosystem, good or bad. We
don't need to take ownership of the whole ecosystem or documentation therein,
but at least providing jumping off points to obvious sources
(Composer/Packagist, phptherightway.com, etc.) would be doing a good service
for our users.
--Larry Garfield
n't think I'd support a list of "popular" frameworks, but mentioning
Composer, Xdebug, and PHPUnit seems a requirement for a useful modern tutorial.
Admittedly, the docs team is very under-resourced right now and even the
reference section has not-small holes, making maintaining even more types of
documentation a potential challenge. That's something the Foundation could
possibly help with. But that's not the topic at hand: The topic at hand is
just "look, we should be able to mention Composer, Xdebug, and PHPUnit, OK?"
On which I very much am in agreement.
--Larry Garfield
explicit marking not only clarifies the intention behind the
> method but also aids in distinguishing between regular and default
> methods, simplifying the mental model required to work with interfaces.
How? All I see here is another keyword I have to use. It doesn't do anything
extra for me as a consumer of that interface. It doesn't add disambiguation to
the language, either for the engine or human readers (as the presence of the
body does that already). It just gives me 8 more characters to type.
> Just thinking out loud here - looking forward to hearing some thoughts.
My thought is we should just pass Default Interface Methods and be done with
it. :-)
--Larry Garfield
internally as a side effect?
As usual, I am not a fan of an ini setting, but I cannot think of a different
alternative off hand.
--Larry Garfield
to here so I will
not go further than that mention.
I suspect there's also other edge case bits to worry about, particularly if
trying to combine a complex alias with a complex type, which could lead to
violating the DNF rule. For example:
typealias Foo: (Bar&Baz)|Beep;
use (Bar&
| (Bar & Baz & Stringable)
>
> It's probably a good idea to update the RFC explaining how expansion works.
Woof. We're not "fixingup" anyone's DNF elsewhere. I cannot speak for
everyone, but I'd be perfectly fine not doing any magic fixing for now, and
then debating separately if we should do it more generally. Just doing it for
aliases doesn't seem like the best plan.
--Larry Garfield
On Sat, Sep 7, 2024, at 7:42 AM, Mike Schinkel wrote:
>> On Sep 6, 2024, at 4:45 PM, Larry Garfield wrote:
>> Aliases can then be used only in parameter, return, property, and instanceof
>> types. Extends and implements are out of scope entirely.
>
> Is there a str
n discussed numerous times before. Enums are not equivalent to their
backing value. The backing value is a standardized-serialization value.
Nothing more. A string-backed enum is not a string, and a string is not a
string-backed enum. Trying to use an enum as transparently equivalent to its
backing value is a categorical error and belies a misunderstanding of what
Enums are.
cf: https://peakd.com/hive-168588/@crell/on-the-use-of-enums
--Larry Garfield
us just on aliases for now, but design them in such a way
that they do not cause an issue for typedefs in the future. (Eg, using the
`typealias` keyword instead of just `type`.)
--Larry Garfield
evious
RFC, and let typedefs implement that if them if sensible.
There's probably yet another research project to do here. I'd volunteer, but I
now have a newborn taking up most of my time. :-)
--Larry Garfield
viously? If so,
> can you describe any of the core ideas you feel are most important?
I was fairly happy with the previous version, so proposing that as-is would
have my vote. I would probably oppose including arbitrary symbol overloading
at this time.
To me, the most important factors are:
1. It's type-safe, and leverages the type system to "make invalid states
unrepresentable" as much as possible. (I'd put the rules around <=> into this
category.)
2. It allows me to opt-in piecemeal to just those operators that make sense.
3. The performance overhead compared to using a method is minimal.
4. It is future-compatible with further language evolution, to the extent
possible. (The `operator` keyword helps here.)
I'd love to see this brought up again, and hope there is sufficient interest to
do so.
--Larry Garfield
On Mon, Sep 16, 2024, at 2:47 AM, Jordan LeDoux wrote:
> On Sun, Sep 15, 2024 at 9:12 PM Larry Garfield wrote:
>>
>> The "multiply by -1 for <=>" bit I don't fully understand the point of. The
>> RFC tries to explain, but I don't quite grok it.
Works brilliantly, I am
>> able to work with the code in the container using all VSCode features,
>> including debugging with GDB. Nice!
>>
>> https://bogomolov.tech/php-extension-development/
Please please someone capture the details of this thread somewhere on the wiki
or php.net, or maybe even in the php-src repo itself. We really need to have
good "how to get from git clone to a working C debugger" instructions.
--Larry Garfield
able mentions:
- pebkac, doofus, 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 is
pal 7 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 optio
chains a
potential fatal. 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 Mai
ich is exactly what exceptions 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.
eneral I will agree is a good thing, 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.
--L
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
On 2/24/12 4:48 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield wrote:
To me, it's just a request for some content, and in a REST API that's
read-only, I just don't care if the consumer sends their request as
GET or POST. I'll cheerfully give t
On 2/24/12 5:04 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfield wrote:
On 2/24/12 4:48 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield
Except that per HTTP, GET and POST are completely different operations.
One
is idempotent and cacheable
sumption is limiting and misleading,
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
much pickier is unclear.
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 Crenshawwrote:
-Original Message-
From: Kris Craig [mailto:kris.
w since I can verify that the code works as expected)? Something
else?
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. )
--Larry Garfield
--
PH
, 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
things working just 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
in 8K
chunks until 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 configuratio
milar to what's proposed
here, rather than debating it directly. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to some seriously slick potential.
$hash_map_of_type_MyIteratableClass = array_map($some_closure,
$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
lled PHP 6? PHP 5 changed 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
Yes, I now always add braces when
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 tags as well, and so should you! :-)
--Larry Garfield
--
PHP Internals - PHP Runtime D
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 , but never close :)
On Jul 19, 2012 4:44 PM, "Larry Garfield" wrote:
we 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 G
please yes!
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
$i = 1;
try {
while (true) {
yield $i++;
}
}
finally {
print "All done";
}
}
That will run indefinitely. So will "All done" ever print, or does that
finally become 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
plementing it
on normal arrays and strings becomes just a matter of consistent syntax.
Personaly I kinda like 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
; > Here's the question I see. Right now, does an ArrayAccess object work
> > with array_slice()? If so, then [2, 5] syntax would be just some nice
> > syntactic sugar. If not, then it becomes a powerful new feature, and
> > implementing it on normal arrays and strings b
G'What? Is this a bug in
PHP 5.2.4? Is this a flaw in my testing methodology? Is this a flaw in that
one particular server's configuration or compilation? If so to either of the
second two, what?
I'm reluctant to trust any benchmarks from this script until I figure out why
it&#x
try and
catch blocks around everything, but remember that Exceptions are popular
exactly because they are a clean and powerful mechanism.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than al
on-exception error-mode
handling. I had queries that were running fine but when I checked the error
value it gave a non-OK value. (I forget what off hand.) As soon as I
switched to exceptions, it worked perfectly. I believe this was under 5.2.1.
--
Larry Garfield AIM: LOLG
_GLOBALS['cfg'], and when you 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.
&
unmaintainable code. Writing code
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 o
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 Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any o
7;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
&
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 ex
turn (isset(self::$data[$name]) ? self::$data[$name] : null);
> > }
> >
> > static public function set($name, value) {
> > self::$data[$name] = $value;
> > }
> > }
> >
> >
> > summary: why "fix&quo
is to help PHP mature into a more
> > object-oriented language with an object oriented library, while
> > addressing a common complaint about the standard library not being very
> > consistent
> > (http://en.wikipedia.org/wiki/Php#Criticism [8th bullet])
> >
&g
... is the keyword vs. {} issue worth
deep sixing namespaces completely? If so, um, let's switch to {} (with or
without multiple namespaces per file) and solve the problem? :-)
For whatever the opinion of someone who writes PHP all day and not C is worth,
there it is.
--
Larry Garfield
1 - 100 of 1698 matches
Mail list logo
