is way:
class Foo {
HTTPRequest $request = SOMETHING;
}
How do I safely initialise that?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
his state.
Regards,
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 27/05/2016 09:35, Tony Marston wrote:
"Lester Caine" wrote in message news:5747f02a.2010...@lsces.co.uk...
On 26/05/16 22:36, Rowan Collins wrote:
So every time I update the current tree because the client has selected
a different initial root I have to destroy perhaps 30 pers
On 26/05/2016 17:57, Fleshgrinder wrote:
On 5/26/2016 6:50 PM, Rowan Collins wrote:
As I'm sure has already been pointed out (I haven't followed the whole
thread) this defeats a large advantage of typed properties - I now can't
read from the property without checking if it's null, so I can't do
On 27 May 2016 10:53:05 GMT+01:00, Lester Caine <les...@lsces.co.uk> wrote:
>On 27/05/16 10:16, Rowan Collins wrote:
>> The most useful typehints are inside the SomeModel class, not the
>> table-level wrapper. This is true even if they're just dumb structs,
>
was
incorrectly assigned to the father property, just a new association
representing the corrected information.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
pon accessing it.
Actually, that's one of the points up for discussion: should accessing the
property when no assignment has been made raise an E_NOTICE, so that there is a
difference between "?int $foo" and "?int $foo = null".
Regards,
--
Rowan Collins
[IMSoP]
--
PHP I
On 02/06/2016 00:19, Aaron Piotrowski wrote:
On Jun 1, 2016, at 3:56 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
On 01/06/2016 19:36, Aaron Piotrowski wrote:
While this might be considered a BC break, I can't imagine there's an actual
code out there relying on suppressing the w
t
h('hello'); // string
function i(string | int) { echo gettype($number); }
i('10'); // string
i(10); // int
It may be that the implementation makes this prohibitively difficult,
but it would certainly be easier to document than the rules currently
proposed.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP
me->death may still be null, as indicated by the
"?" in their type spec
// $me->birth is guaranteed to be a \DateTime object
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
a different set
of objects to hold it.
Objects are not memory slots to be re-filled, they represent a specific
instance of a thing. Creating and destroying 30 objects on a modern
system is the work of nanoseconds, and not something to be avoided at
all costs.
Regards,
--
Rowan Collins
[IMSoP
On 26/05/2016 21:00, Fleshgrinder wrote:
PS: This needs a cast unless some special driver options are active.
$me->numSiblings = (int) $db_record['num_siblings'];
...or unless strict_types=0, in which case PHP will add an implicit cast
for you. :)
Regards,
--
Rowan Collins
[IM
n't
store a null date :(
That's exactly what ?DateTime is for - "either DateTime or Null", just
like in a database.
In most type systems, there is no such thing as "a null date" - if it's
null, it's not a date, it's a null value.
Regards,
--
Rowan Collins
[IMSoP]
-
you perform one unnecessary operation;
if it's never been initialized, it has now.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
of a meaning in that case,
anyway, and it has nothing to do with initialisation.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 26/05/2016 11:49, Fleshgrinder wrote:
On 5/26/2016 12:39 PM, Rowan Collins wrote:
On 26/05/2016 11:16, Fleshgrinder wrote:
$o = (object) ['x' => null];
var_dump(isset($a->x)); // false
var_dump(property_exists($a, 'x')); // true
Apart from a typo in your exampl
s been: https://3v4l.org/NeqGl
isset() is really very simple: if the thing your accessing would give
you the value null, it returns false, otherwise it returns true.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.p
that with any confidence.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, making these consistent would be nice, but like a lot of
consistency, does it come at too high a price?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ti-type-hints", they just don't
agree with this particular implementation.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
me run-time checking, but I
couldn't find any documentation explicitly laying out the principles.
That gives us a unique set of problems when designing them, not least in
terms of performance.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsu
"in the PHP 7 era",
regardless of what changes we're releasing?
(Note: I've deliberately tried to keep this thread about the policy in
general; for my concerns about this change in particular, see the other
thread.)
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
get released quickly,
then that release would be soon.
The only difference over drip-feeding them into the 7.x series would be
that users would know when to expect things to break.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
this feature into a live release right now, with 7.1 already in
alpha. Is the plan to release major performance changes in 7.1.x?
Wouldn't most of those have to wait for 7.2.x anyway?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
On 16/06/2016 19:11, Levi Morrison wrote:
On Thu, Jun 16, 2016 at 10:30 AM, Rowan Collins<rowan.coll...@gmail.com> wrote:
>
>Why? What's special about 7.1? If it was a case of finishing off changes
>that "should have been part of 7.0", I can see some kind of l
to be implemented.
Do we really trust our future selves so little that we are incapable of
planning more than 6 months ahead?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
y warnings!
This is why I really don't understand what the hurry is to get this into
the release: the BC break may be marginal, but so is the benefit. Why
not just postpone both until the performance benefits are more concrete?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime D
including some third
party library that doesn't something wonky, and need to be robust. Or,
as Alexander points out, you might want to execute "finally" blocks on
the way out, even though the application is ultimately going to crash.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - P
, shuffling, maybe built-in UUID support...
Then, IF the new APIs become popular, we can come back to talking about
removing rand() and mt_rand(), because we'll have replaced them with
something substantially better, not just another variant on the same thing.
Regards,
--
Rowan Collins
[IMSoP]
--
make a proposal they'll approve. There's already a
majority of voters, just not the required super-majority, so I think
it's pretty clear that there's an appetite for the idea, if pushed in
the right direction.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nd a note on the others that "since 7.2, mt_rand() is an
alias for random_fast_int()" etc. (Not wedded to the name
random_fast_int, we can bikeshed that later.)
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ewhere seems as good a place to start as any.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that "should have been part of 7.0", I can see some kind of logic, but
the ones we're actually discussing seem to be more about "preparing for
8.0".
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ething's
gone very wrong" function anyway, I think it receiving all Throwables
makes sense, even if the BC break in your scenario is unfortunate.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
es it stop fatal errors being fatal; nor
should its replacement.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Dan Ackroyd wrote on 08/01/2016 16:26:
On 8 January 2016 at 15:48, Rowan Collins <rowan.coll...@gmail.com> wrote:
It doesn't do anything to help Stas's example for instance:
@$counts[$item]++;
I think that that code is bogus since the release of PHP 7, which made
it trivial to n
On 10/01/2016 08:58, Yasuo Ohgaki wrote:
- "super_global" rather than "superglobal" to obey CODING_STANDARD.
AFAIK, "superglobal" is consistently spelled as one word throughout the
manual, so that underscore looks very out of place to me.
--
Rowan Collins
[I
e way.)
This is another good reason to give the extension a snappy name - if you
got your way and this extension lived in the \Crpytography namespace,
how would you signal that a particular Node.js library was intended to
interact with it?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals -
t it would
be interesting to think about how they might be related.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the pluggable API
removes the need for any of the sodium_* / Sodium::* / \Sodium\* functions.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"a toolbox of encryption primitives, currently
implemented using libsodium".
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
of leeway for understanding
other people's concerns before threatening to abandon work which would
be very much appreciated.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
other things in it, $url may be an
existing variable getting a new value. The best extract would give you
is $curloption_10002, which isn't all that useful.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 27/06/2016 16:31, Andreas Heigl wrote:
So it crashes with a fatal error when Implementing the interface. It'S
interesting though that the script allows me to instantiate the class
nonetheless.
It sounds to me like the ability of the interactive shell to catch fatal
errors and continue
On 17/06/2016 11:37, Björn Larsson wrote:
Den 2016-06-17 kl. 12:15, skrev Rowan Collins:
Do we really trust our future selves so little that we are incapable
of planning more than 6 months ahead?
Well, my interpretation was that postphoning it meant 8.0, which
is not 6 months away. Having
n.
While on the other side, a polyfill with identical semantics but worse
behaviour would be easy to provide as a composer package, reducing BC
concerns.
It would need an RFC, but that shouldn't be too hard to get drafted in
this case. https://wiki.php.net/rfc/howto
Regards,
--
Rowan Coll
ably the least common use case. In the OP's use case, given a large
array consisting only of string keys, the function would have to examine
every key to decide whether to return ARRAY_KEYS_STRING or
ARRAY_KEYS_MIXED, although the user doesn't care about that distinction.
Regards,
--
Rowan Col
so.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
$string[1]; $temp++;
$string[1] = $temp;
If making string access similar to array access is a lower priority than
adding features such as the one in this RFC, then the case for switching
to {} is strengthened, but not conclusive.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - P
nt
environment. This would allow you to detect even things which cause
fatal errors on some implementations, by triggering the error in a
sub-process, and would be more efficient than probing them at runtime.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing
that they will
probably never be used, is a justifiable position, not a contradiction.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
enforcement mechanism. If you consider the
status quo to include such an enforcement mechanism, and do not wish to
remove it, then you agree with that general principle.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine wrote on 09/02/2016 14:55:
On 09/02/16 14:32, Rowan Collins wrote:
nobody would agree to an "out of court settlement" if there was no court
case to be avoided.
That one is probably a bad example. How many cases are settled simply to
avoid exorbitant legal costs? Being
Matt Prelude wrote on 09/02/2016 15:51:
On 09/02/16 15:24, Rowan Collins wrote:
That said, I am not convinced either
a) that the current process has any guarantee of transparency - who
exactly has the right to block people from the list, or revoke other
karma? what transparent process
as biased, or intimidating for
one side or the other, it would have a chilling effect rather than a
calming one. In my mind, that makes defining due process even more
important, to reassure everyone that the intimidation is not intended.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime D
piece of PHP code ever written in favour of a
vaguely-imagined utopia whose parameters we haven't even defined yet.
I don't believe in either extreme. It's a simple proposal, which can be
examined on its own merits.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development
form part of the guidelines: "Do not treat an RFC as
your personal property to be defended against the community; rather,
treat it as an offering of effort which the community will help you
shape". (I haven't spent long thinking about that wording - feel free to
improve it.)
Regards,
--
rray, and so "striving to make string offsets work well" and
"striving to make string offsets work the same as array offsets" are
different, and possibly conflicting, goals.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
S.A.N wrote on 12/02/2016 13:37:
Often all keys are unknown, or a very lot keys, use list(...) - is unreal.
I would like to, instead $value)
{
$this{$key} = $value
}
Use the short syntax sugar
It's really do?
If the keys are unknown, then you probably don't want to blindly copy
them
S.A.N wrote on 12/02/2016 15:13:
But is also necessary and the function or operator like
object_assign($target, ...$sources)
Like I say, for that kind of purpose, I'd just use an array, which
already has the facilities for working with arbitrary keys. But I know
some people think $foo->bar
S.A.N wrote on 12/02/2016 14:39:
2016-02-12 16:27 GMT+02:00 Rowan Collins <rowan.coll...@gmail.com>:
S.A.N wrote on 12/02/2016 13:37:
Often all keys are unknown, or a very lot keys, use list(...) - is unreal.
I would like to, instead $value)
{
$this{$key} = $value
}
Use the short
ith declared properties) is so easy, and so much more
powerful.
That's why I call it a matter of taste: if I want a hash, I'll use an
array, which is already full-featured; if I want an object, I'll define
a class for it and use at least some OO principles.
Regards,
--
Rowan Collins
[IMSoP]
Matt Prelude wrote on 09/02/2016 17:56:
Rowan
On 09/02/16 17:42, Rowan Collins wrote:
Without going into point by point discussion, I think you're
conflating several things here:
1) the right of the accused to know *what* they are accused of, which
I agree is fundamental
2) the right
that mediation breaks down.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
- you've suggested extremely formal and verbose wording to
replace punchy, jokey, points. It maybe needs a bit more "us" rather
than "you", but ultimately, it's a bunch of dos and don'ts, so there's
only so far it can go in placating a nervous reader.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
han trying to make it look like
arrays. Then, it would be less surprising for $string{-1} to behave
differently from $array[-1], and that $string{} is a syntax error.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
espect, but if not impossible this would at least be
rather surprising.
It also doesn't help with your stated point of using get_class as a
callable, since you'd have to know what function it was in order to call
it in the right way (although exactly what the use case for that would
be, I've no i
Dan Ackroyd wrote on 29/01/2016 13:56:
On 29 January 2016 at 10:46, Rowan Collins <rowan.coll...@gmail.com> wrote:
You appear to be suggesting that "get_class()" should behave differently
than "get_class(null)".
I don't know if internal parameter handling (ZPP) work
suggestion that the technical merit of their
arguments should be ignored.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
could add to that a special case for constructors:
- Callable::forConstructor(string $class_name)
This would be roughly equivalent to (and polyfillable with):
return function (...$args) use ( $class_name ) { return new
$class_name(...$args); };
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - P
be surprised if other IDEs and tools can pick
this up as well.
In this case, you could just use the fact that the property is labelled
"@inject" to mark the distinction, and you'd be no worse off in terms of
tooling support than you are now (i.e. IDEs will not come with this
inter
thing, there may be
sound theory behind how other languages work.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nvoked, will cause instantiation of a particular class.
I don't, however, know Python well enough to say whether a better
example would be more like what you want in PHP.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
tor is so much worse that it needs a new language concept.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ion of that for constructors could work
(ReflectionClass::getConstructorClosure() ?).
Reflection always feels to me like "the language doesn't really support
this, but you can sort of cheat this way", but maybe that's a poor
prejudice.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP In
re for tidiness. As with "can we rename
functions / fix argument order / etc", I wonder if there's scope for
publishing an FAQ which, while not holding the force of Official Policy,
is nonetheless endorsed as consensus to guide new contributions...
Regards,
--
Rowan Collins
[IMSoP]
--
PHP
ere are tons of nice libraries out
there, and you don't have to wait for a new PHP version to get a bugfix
or feature, just "composer update".
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e
extracting them.
It may or may not work for your use case, but it doesn't really have
anything to do with objects either way.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
fire-exception would be a horrible idea in PDO, but having one
object which represents an open connection, and a separate one which
represents a *potential* connection (maybe open, maybe closed, maybe
not-open-yet) is a useful abstraction, and doesn't need anything in PDO
itself.
Regards,
--
Christian Wenz wrote on 11/02/2016 09:17:
On Mon, Feb 8, 2016 at 09:32 AM, Matthew Setter wrote:
The approach I took was this:
return array_keys($arr) !== range(0, count($arr) - 1);
FWIW, this might not work for arrays with missing indices like [0 =>
'a', 2 => 'b']
I personally would
Paul M. Jones wrote on 11/02/2016 17:16:
Finally, these are Guidelines, but for whom? Is their violation actionable? If
so, by whom, and in what circumstances? If not, then the Guidelines should say
so.
My understanding (admittedly I've only skim-read the text) was that this
document was
ents for and against, based on the pre-draft discussion.
I remain not-quite-convinced that the benefits outweigh the costs, but
don't feel very strongly; I'm kind of "-0.5" on this (and don't have an
actual vote anyway).
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Ru
Tony Marston wrote on 10/03/2016 10:38:
"Rowan Collins" wrote in message news:56e0025c.5040...@gmail.com...
This leaves us back with a decision about *which* BC breaks are
acceptable, discussion of which includes how many people use the
feature, how it will affect them, and what th
it. If you want to participate in the existing
process, participate (and if you want to understand more about how it
works, ask). If you don't want to do either of those things, I'm not
sure what you expect us to do with your messages.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime
etime in the next few years", which is quite a mild pressure.
But in general, I agree with your sentiment that there is effort
involved that could be spent elsewhere.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
C, which I admit I haven't
fully read, about "rough consensus". https://tools.ietf.org/html/rfc7282
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
its, which I am happy to delve
into the details of on a case-by-case basis.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
James Titcumb wrote on 09/03/2016 11:13:
By the way Yasuo, you didn't include the internals mailing list in your
last reply.
I think possibly you didn't include the list in a previous reply then,
assuming Yasuo was replying to something you wrote?
--
PHP Internals - PHP Runtime Development
e, because there is no consensus, or
in some cases, just no interest. It is certainly not the case that if
you stop shouting, this deprecation and removal will quietly go ahead.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
arter than just a Perl
regex. There are also examples for making code modification in the docs
for Nikita's PHP-Parser library: https://github.com/nikic/PHP-Parser/
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
172/] - it's not the language's responsibility to
support every workflow that exploits unintended functionality.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, it's applying the same rules for
grouping types as we apply for grouping visibilities.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"do not top post" is classed as a "hint".
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hat use.
Meanwhile, it might be worth checking the list archives for previous
discussions of package visibility; I know it has come up a couple of
times recently, in various forms, so it would be good not to repeat the
same points again and again.
Regards,
--
Rowan Collins
[IMSoP]
which JSON is modelled.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
a huge change to the language, and no doubt
have all sorts of impacts and problems of its own, but I don't think it
makes sense to say "you can typehint your property names, but you lose
some existing functionality if you do so, for technical reasons".
Regards,
--
Rowan Collins
[IMSoP]
--
PHP
, and deprecation
is a tiny change anyway, so there's really no hurry. :)
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ther no-op or error if you attempted modification.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ely do it like this, and a hook into something as
fundamental as "echo" can't really rely on "it's quite rare" as an
excuse for not accounting for them.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e *same* type when performing assignment.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
801 - 900 of 1629 matches
Mail list logo
