ntial' it is that this is done, and I don't see any pressing need
as yet to remove var?
This much I agree with. I see no urgency to batch update, even if the
cost of doing so is low.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ying
the same trait twice, at different levels of the hierarchy; I'm not sure
this is a particularly likely scenario, or relevant to how interfaces
should behave.
Regards,
--
Rowan Collins
[IMSoP]
ersede the current stable version long before the
next major version of PHP.
It's not about whether those notices are there for 6 years or 9 years,
or which E_* constant they appear under, it's about granularity of which
ones shout at me.
Regards,
--
Rowan Collins
[IMSoP]
ue to have two ways of writing "public". But there is no way for the
engine to distinguish new code from "legacy" code which already contains
the keyword. If someone can come up with a clean mechanism for doing
that (and in particular, for new code to say "I'
rser/
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
It occurs to me that if I saw "var", I would not think "that should be
public", but "that needs assessing for visibility". I do the same with
legacy code where methods are written as "function foo()" rather than
"public function foo()" - I check whether i
Tony Marston wrote on 02/03/2016 09:53:
wrote in message news:56d5dda6.4080...@fleshgrinder.com...
On 3/1/2016 6:34 PM, Rowan Collins wrote:
Rowan Collins wrote on 01/03/2016 11:33:
Secondly, violating visibility may have repercussions outside actual
errors.
Incidentally, PHP itself
Rowan Collins wrote on 01/03/2016 11:33:
Secondly, violating visibility may have repercussions outside actual
errors.
Incidentally, PHP itself encountered this a few years ago, where a
release of libxml2 changed internal behaviour that was being relied on
for a hack. The result was that
Tony Marston wrote on 01/03/2016 09:32:
"Rowan Collins" wrote in message news:56d42cd3.6020...@gmail.com...
Tony Marston wrote on 29/02/2016 09:55:
"James Titcumb" wrote in message
news:CAKnqCEY7art1GUWG=pm0wypgqmyp0dq8oxdohgbksgq+o_b...@mail.gmail.com...
Incorrect.
ised 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
interpretation of "var" baked in anyway).
Regards,
--
Rowan Collins
[IMSoP]
version 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
[IMS
ct a wrapped
constructor 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
ay of passing around an invokable
object which, when invoked, 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
s nothing
wrong with PHP being the only language to do something, 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
pe-checks.
Then we 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
deprecations need to be justified more
strongly than a general desire 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 conse
at post, or any 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
a
declared class, with 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.
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 "l
S.A.N wrote on 12/02/2016 14:39:
2016-02-12 16:27 GMT+02:00 Rowan Collins :
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 real
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 on
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 adv
ugh, I think it is not reasonable to expect the same behaviour as for
an array, 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
uggested above seem to me to completely contradict
this one - 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
and making it work *usefully*, rather than 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 Mail
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 appr
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 o
east until that mediation breaks down.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
art 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
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 are
cate every
array-related 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]
--
f the process is perceived 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]
--
e of it, there
should be some definition of 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
ssuring people 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
urning the type, it's still amenable to optimisation, because you're
stating which checks you're interested in, so the implementation can
pick the fastest version of those checks.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
where it is useful to do so.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
probably 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.
Regard
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
$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
o 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 List
To unsubscribe, visit: http://www.php.net/unsub.php
Dan Ackroyd wrote on 29/01/2016 13:56:
On 29 January 2016 at 10:46, Rowan Collins 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) works like userland
para
this respect, 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
ted implementation. The joy of
the PHP ecosystem right now is that there 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
ementation of just
close-and-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 any
ds a key to the
array, and you have the ability to rename $a and $c while you're
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
Note that $curlOptions probably had 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
uot; - I think it's an unfortunate
BC break which could have had more attention, either to ensure it was
clearly signalled, or to look at mitigation ideas like we are in this
thread. An honest mistake, rather than somebody not caring.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP
"something'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
we could simply
present the functions as "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
- maybe leave a bit 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
be either MIT, WTFPL,
or CC0 licensed by the 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,
ay of mcrypt. So 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
both things, but 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
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
n-fatal if ignored, then "turn everything into an
exception" is not a complete solution.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
urposes here; I'm not
entirely sure what you thought I was advocating, but what I was actually
saying is really simple:
Exceptions are not the right solution to all the places that PHP
currently has warnings, so a simplified catch statement ("suppress
Exception") is not the right
ant to use them everywhere.
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 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 not use the error suppressio
't suppress exceptions, nor does 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
ses as they come up. This
generally turns out to be better than trying to codify every possible scenario
in advance and leaving loopholes - as long as you trust your judiciary!
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
Paul M. Jones wrote on 06/01/2016 16:50:
The reality is that those people will be put off contributing no matter how much you tell
them that it is "just words", and the community will be the poorer for their
loss.
I assert that you don't know, and cannot measure, if it's poorer for their loss.
same action could
have a very different motivation and impact.
I'm also not sure what the solution is, but there's a compromise to be
made somewhere between "all accusations will be discussed in an
unaccountable private court" and "all accusations must be discussed in
r structures; neither of those
points actually relies on the "people should just get over it" idea, so
there is common ground to be found.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kevin Smith wrote on 06/01/2016 11:58:
On Jan 6, 2016, at 3:28 AM, Rowan Collins wrote:
On 6 January 2016 02:13:53 GMT, "Paul M. Jones" wrote:
When speech-policing is proposed without irony, and welcomed with
applause, I respond correctly: with scorn and contempt, as is deserved.
undermines your position by making you seem like an extremist rather than a
concerned party with a contribution to make.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ebody else's value of error_reporting.
I don't see how that's an untintended consequence, or what it's got to
do with choosing between declare() and ini_set(). Or maybe I'm just
mudding multiple sub-threads now?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - P
ilerplate, and thus be
unaffected by the presence or functionality of the @ operator.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
is a reasonable line of discussion.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
agree with you, and attempt to find common
ground and compromises. That's how conversations work.
If all you're doing is trolling the group because you think being rude
on a thread about good conduct is funny, please go do it on 4chan or
reddit or something.
Regards,
--
Rowan Collins
[IMSoP]
rectly. This could then allow
more information to be exposed to userland, and more granular stacking
of handlers and configuration to mask off different types based on their
codes.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
; and "operator + (float, int)".
Like in C++, though, Postgres's operators aren't intrinsically grouped,
and it's up to you to use them in idiomatic ways, such as "||" for
various types of concatenation (because SQL) and "@>" for "contains".
r elements, you're
probably better off using array_keys / array_values to give you a list
which can be efficiently randomly accessed.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ugly to me. The name
"reset" is hardly obvious, and the side-effects of "resetting the
internal array pointer" even less so (e.g. how does it affect
copy-on-write?).
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsu
onstant to userland
so that the mangling can actually be done in place on appropriate arrays:
$old_get = $_GET;
$_GET = [];
foreach ( $old_get as $old_key => $value ) {
$new_key = preg_replace(PHP_ILLEGAL_NAME_REGEX, '_', $old_key);
$_GET[$new_key] = $value;
}
Regards,
--
Rowan C
y are
*not* making a general declaration of scope, but marking very specific
couplings. If a large number of classes need access to something marked
private, it's clearly not really private.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jefferson Gonzalez wrote on 09/12/2015 03:48:
So as somebody already said, maybe your code or setup is really busted.
Really busted, or spending all its time in a type of operation that ZE3
can't particularly optimize...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
ing
for, it's no easier to name the decision date than the EOL date itself,
so we're better off just making a firm decision now.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins wrote on 07/12/2015 14:35:
- On what factors will the decision be based? If the reason to delay
the decision is lack of information, what information are we planning
to use? Are there metrics we can use to make a more objective decision?
Come to think, this works the other way
Sebastian Bergmann wrote on 07/12/2015 14:28:
Exactly. We need a fixed EOL date and we need it now. And before this
thread started we had one: August 2017.
To be fair, it wouldn't have taken a psychic to predict that this would
be at least discussed. Until now, there has never actually been a
bed in"?
- On what factors will the decision be based? If the reason to delay the
decision is lack of information, what information are we planning to
use? Are there metrics we can use to make a more objective decision?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Develo
gards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine wrote on 07/12/2015 09:42:
Providing PHP7 clean alternatives with usable upgrade paths is the
only way that PHP5.2/3 can be deprecated fully, so any debate on an
arbitrary EOL for 5.6 is simple pie in the sky? When will Python2
disappear ... now unlikely it ever will? Is PHP5.2 any
set to asynchronous mode, you would indeed see your
co-routines running concurrently, as each waited for its respective
query result to come back from the database.
Hope that helps point you in the right direction to better understand
what's going on.
Regards,
--
Rowan Collins
[IMSoP]
-
hey don't even follow the official
point releases, preferring to fork from a well-tested point and maintain
their own set of patches.
Regards,
--
Rowan Collins
[IMSoP]
e, so it's not quite as simple as that: https://3v4l.org/qbT3j
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
guilhermebla...@gmail.com wrote on 26/11/2015 16:05:
Ok then. I'll pretend that lack of interest didn't happen many other
situations (like http://marc.info/?t=14460876781) and move on.
It's possible that a lot of the core devs are still concentrating on
getting the changes in 7.0 bedded in
e worrying if specific people are interested
- they may just be on holiday, or busy elsewhere, or just not have much
to say until someone assembles a few more details about the proposed
feature. Keep it constructive, lay out how you think the feature should
look and why, what questions are still o
that we haven't invented yet) parsers might or might not find
harder.
As I say, apologies for side-tracking the conversation for so long, I
was intending it to be one decision among many, and wanted to make sure
we'd captured a good reason for the decision, so that it could be
j
e of many decisions that needs making
before this feature can be attempted, probably starting with just what
an annotation consists of - is it a label with some text attached? a
resolved class name with parsed PHP code passed to its constructor (some
people have mentioned arrays and heredocs as param
nalysis would suggest.
All the other details about how this or that tool will adapt, how whitespace
and multiline values should be handled, etc, are going to need just as much
thought whatever the syntax looks like.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins wrote on 25/11/2015 18:47:
Simple: remove that configuration variable, and always save doc blocks.
Thinking about it, you don't even need to do that, just add a structure
in the opcache memory layout for the parsed annotations, allowing you to
accelerate access to
bject to any attempt
to shut down the discussion just because people have already made their
mind up based on some gut feeling.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Larry Garfield wrote on 25/11/2015 17:39:
On 11/25/15 11:00 AM, Rowan Collins wrote:
I don't feel that strongly in favour of docblocks, but I don't think
the reasons given against are particularly strong.
Regards,
If you don't feel strongly in favor of them, why are you tr
Larry Garfield wrote on 25/11/2015 17:06:
For me, the "sometimes it's code and sometimes it's not, even though
it looks the same" argument is sufficient to reject docblocks as a
location for annotations.
Annotations aren't code, they're metadata, and docblocks already contain
metadata; it's
Pedro Cordeiro wrote on 25/11/2015 17:04:
2015-11-25 14:53 GMT-02:00 Rowan Collins <mailto:rowan.coll...@gmail.com>>:
If it helps, just think of /** ... */ as not being a comment, but
already a first-class piece of syntax.
Except that it won't parse some stuff whil
Larry Garfield wrote on 25/11/2015 17:06:
Too, it means that a given annotation directive may have spurious *
characters inside its string, if it's multi-line. Sure, that can be
filtered out (Doctrine already does), but that's one more complication
to have to consider.
I would expect that b
e same disadvantages you're
claiming for docblocks - they look like things you can delete, or which
has some other purpose, but are actually vital to the operation of the
code.#
I don't feel that strongly in favour of docblocks, but I don't think the
reasons given against are parti
are
already supported by the reflection classes, I'm not convinced of why we
shouldn't just carry on down that route.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Larry Garfield wrote on 25/11/2015 16:42:
However, doing so would make static checking more difficult; If
annotations become a language-native feature, they should be a
first-class citizen to make it easier for IDEs to handle.
Could you explain why docblocks are harder to parse than text outs
801 - 900 of 1644 matches
Mail list logo
