().
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
) without building a
whole HTTP framework into the core.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
interface is what most
people will end up wanting anyway.
Regards,
--
Rowan Collins
[IMSoP]
,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
information it originally contained.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
sense (for a static class with missing method bodies).
There's an ancient RFC proposing that here, but it seems it didn't get
anywhere much: https://wiki.php.net/rfc/static-classes
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
in general, it's a good idea, but that
implies it is the first milestone in some larger plan, which doesn't
seem to be the case as yet.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
like a good Big Feature to pin a major
release on, just as Unicode strings would have been, had it gone ahead.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
- (int)' 12' (leading space) is 12, but (int)'a12' (leading non-digit)
is 0 (no such special case is needed for trailing whitespace, because
any trailing characters are ignored.)
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
); }
wants_int(int $foo) { var_dump($foo); }
wants_object('abc'); // fails with E_RECOVERABLE_ERROR
wants_int('abc'); // succeeds and prints int(0)
That seems both inconsistent and less useful than a hybrid juggling +
validation approach.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
); }
As such, it neither requires, nor is required for, additional warnings
around lossy casts.
[1]: http://blog.ircmaxell.com/2012/03/parameter-type-casting-in-php.html
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
-type-hinting-is-harder-than-you-think.html
[2] http://blog.ircmaxell.com/2012/03/parameter-type-casting-in-php.html
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to strict weak type hinting than
casting weak type hinting; it differs in *performing* a non-lossy
cast, rather than just asserting the *possibility* of one.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
in that case (although you'd then want an __castFromArray
override when you did flesh out the class):
$foo = (MyValueObject)['id' = 42, 'name' = 'The Answer'];
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
be emulated
fairly easily with is_array(), is_callable(), and instanceof).
If we don't want all casts to emit warnings on loss, perhaps a new
function or keyword request them - e.g. (strict int)$foo, or
strict_cast($foo, 'int').
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP
On 13/07/2014 17:36, Andrea Faulds wrote:
On 13 Jul 2014, at 17:29, Rowan Collins rowan.coll...@gmail.com wrote:
It's an interesting thought, but we currently have the object keyword for that
particular use case. In some languages, having a base object is useful because
functionality can
. This doesn't really have to do with it being
non-scalar per se, just that there's no natural type-juggling like
there is for '123' = int or '1.5' = float.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
signatures. It makes sense
for the language to implement both at once, but for the user to be able
to use them separately (e.g. catch lossy conversion in existing uses of
(int)$foo).
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
features in order to make
stronger guarantees.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.)
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that I see this as a new definition of lossless cast;
this RFC is intentionally *not* using the existing cast logic, as
explicit casts *never fail*, so but existing casts work this way is
not relevant.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
Arvids Godjuks wrote (on 14/07/2014):
There is no special casing, Array and Object type hints are already
implemented and are in the language for quite a long time. Just don't
touch them, that's all I ask.
The special case existing for backwards compatibility doesn't make it
less of a
Derick Rethans wrote (on 14/07/2014):
A compromise by adding more inconsistencies.
The only way of not introducing some inconsistencies (or, to put it
another way, new features) is to use strict type hints, which perform no
casting, and error on invalid input, since that's what the existing
Zeev Suraski wrote (on 14/07/2014):
-Original Message-
From: Rowan Collins [mailto:rowan.coll...@gmail.com]
Sent: Monday, July 14, 2014 6:28 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
Derick Rethans wrote (on 14/07/2014
Zeev Suraski wrote (on 14/07/2014):
I do believe that the vast majority of people would want '32 ' and 42\n
to silently convert to 32/42, and will generally not care much about
'32abc' converting to 32 either for the sake of consistency.
And passing 'hello' to a function type hinted as int?
Zeev Suraski wrote (on 14/07/2014):
I'd say absolutely yes, if they're PHP developers that's exactly what they'd
expect. After all, if you use 'hello' today in any integer context in PHP,
explicit or implicit, that's exactly how it will behavior across the
language.
And yet if you use it as a
Andrea Faulds wrote (on 14/07/2014):
On 14 Jul 2014, at 18:24, Rowan Collins rowan.coll...@gmail.com wrote:
If the current type hints were only for objects, I would be OK with that, but I
really don't get why an array cast is so different from an int cast.
I’m don’t think the result
Andrea Faulds wrote (on 14/07/2014):
Arguably it’s inconsistent for the scalar and non-scalar type hints to work
slightly differently, but the point is that we’d be doing what makes sense for
arrays (no meaningful casts, so we don’t casts) and what makes sense for the
scalar types (there are
comes down to us each wanting our
favourite from that list of features to have the privilege of dedicated
syntax in function signatures.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ferenc Kovacs wrote (on 15/07/2014):
On Tue, Jul 15, 2014 at 3:21 PM, Andrea Faulds a...@ajf.me wrote:
as I mentioned above, nobody argues that input validation (and escaping
output in a context sensitive manner) is a must.
Isn’t a must, surely? (I assume that was a typo)
I wasn't talking
Ferenc Kovacs wrote (on 15/07/2014):
sorry, not a native speaker.
No problem, I think the intention was clear enough, and certainly meant
no criticism. :)
so you are saying that nobody argues that $someGenericStatement is
not proper grammar?
in my case the $someGenericStatement was that
of the flag, that's just the caller's way of making the
decision. That the type hint encouraged that would therefore seem like a
Good Thing.
(I'd post that comment on the appropriate sub-thread where that example
was raised, but don't have time to find it...)
Regards,
--
Rowan Collins
[IMSoP
that position, but it is the logical conclusion of that
particular line of reasoning.)
Regards,
Rowan Collins
--
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stas Malyshev wrote (on 15/07/2014):
Having more than one set of rules
for implicit cast makes no sense to me at all and will only lead to
more confusion and frustrated users.
That's only a problem if you frame the new hints as a type of implicit
cast. If they were to be described in
Ford, Mike wrote (on 15/07/2014):
Oh, goodness, deary me -- this sounded so familiar I just had to do some delving
and hey presto! I refer you
to:http://marc.info/?l=php-internalsm=124655821522388
(...which, interestingly, even predates Zeev's 2010 claim, and I believe may
have taken
Andrea Faulds wrote (on 15/07/2014):
It’s a shame Nikita’s Exceptions in the Engine RFC failed, as being able to do
this would be nice:
try {
$foo = (int!)$foo;
} catch (RecoverableError) {
$foo = 1;
}
Perhaps some sort of similar syntax? `(int!)$foo else 0`?
I was thinking the
syntax (not that that is what you were
asking for, exactly, I've taken it to extremes to make a point).
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski wrote (on 16/07/2014):
For me the introduction of a new set of rules is a deal breaker.
I'm -1 on the RFC the way it is, and +1 if we implement these 'hints' as
implicit casts, plus change implicit casts to emit E_CAST in case of loss
of data or 'bogus' conversions.
Just to be
Stas Malyshev wrote (on 15/07/2014):
Hi!
That's only a problem if you frame the new hints as a type of implicit
cast. If they were to be described in relation to existing
functionality, I'd describe them as a new type of *explicit* cast, but
How they are explicit cast if you're not explicitly
Andrey Andreev wrote (on 16/07/2014):
I understand that this RFC is about type cast hints and that's fine
with me.
It is and it isn't. It's about a hybrid approach which deliberately
mixes casting and validation.
Having the mixture alongside pure casts or pure validation is less
attractive
Zeev Suraski wrote (on 16/07/2014):
Secondly, if you do enable E_CAST - you may have to slightly*modify* your
understanding of implicit casts, but you won't have to learn two different
sets of rules. New users will see just one consistent set.
I think I've got a bit lost: I thought you were
Zeev Suraski wrote (on 16/07/2014):
But there too, they'd have consistency, just one set of rules for
implicit cast of scalar values across all of PHP.
The way I see it is that there's an existing set of rules for the result
of any cast, implicit or explicit; these are in some cases lossy.
Yasuo Ohgaki wrote (on 16/07/2014):
The only BC issue I can think of is game that expects the same pseudo
random sequences. These apps may use mt_srand() to get fixed random
sequences and adjust their apps if it is needed. This is acceptable BC
for new releases. IMO.
Do you propose making
like you've written avoids that, but it
feels kind of weird - like when SQL date functions take things like
day and hour as barewords rather than strings.
Maybe I'm overthinking it though.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
what those actually are.
So, my apologies for being slow on the uptake, but given the mix of
people extremely familiar with the core, and people familiar only with
its effects on userland, I wonder if I'm not the only one.
Humble regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP
with?
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
from *both* sides of the current RFC, but
there may be other things that came up in discussion that aren't
mentioned because they don't fit well in the current structure.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
every occurrence detected by
the scanner to the appropriate unambiguous form (even if that is
technically unnecessary for that particular case); then when you re-ran
the scanner, it wouldn't find the same ones again?
I'm probably missing a subtlety here, though...
--
Rowan Collins
[IMSoP]
--
PHP
Zeev Suraski wrote (on 22/07/2014):
I think the way it's laid out right now makes sense. Let's not try to
sweep this under the carpet - we two mutually exclusive options and we
need to decide between them.
How is laying out the arguments more clearly sweeping it under the
carpet? The
it has an intro and conclusion where the PHP 6 one doesn't.
I got the vibe that people weren't happy with the RFC, and that's why
the vote was cancelled, so I was suggesting a way forward, but maybe I
misread the situation.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime
on the RFC which led to the vote being cancelled
are actually in agreement now.
Ah, OK, my bad.
:)
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
and first sentence.
More seriously, UnsignedInt might go nicely alongside Andrea's BigInts...
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
://www.mediawiki.org/wiki/Extension:Collection
[3] https://www.dokuwiki.org/plugin:bookcreator
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
popular implementation.
On the flip side, there is definitely value in representatives from
other implementations having a voice in changes that affect them, but
that could just mean ensuring that members of those projects are
involved within the current framework.
Regards,
--
Rowan Collins
, not 5 (I'm
guessing phpng, if accepted, will be Zend Engine 3?). I think the
backwards compatibility of being able to say PHP 5.6 compliant is
attractive though.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
this spec is eventually distributed in, I hope it
doesn't contain whatever markup/misfeature is causing Adobe Reader to
insert quotemarksbetweeneveryword when I copy and paste from it!
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
to make clear
that the Zend Engine isn't actually the language implementation, it just
*powers* the implementation. In which case, what *should* the
implementation be called?
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
Andrea Faulds wrote (on 24/07/2014):
On 24 Jul 2014, at 14:40, Rowan Collins rowan.coll...@gmail.com wrote:
Incidentally, that's another question: some people like to make clear that the
Zend Engine isn't actually the language implementation, it just *powers* the
implementation. In which
easily reinterpreted third verse.
Damn, Godwin's Law, sorry all!
:(
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
/Template:PHP
Which is definitely too trivial to spend much energy debating.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ivan Enderlin @ Hoa wrote (on 25/07/2014):
On 24/07/2014 15:40, Rowan Collins wrote:
Ivan Enderlin @ Hoa wrote (on 24/07/2014):
Taking the example of XML, CSS, HTML, ECMAScript or other languages
(maybe the JVM, I don't know exactly), there is version numbers for
the specification
On 26/07/2014 22:55, Chris Wright wrote:
On 25 July 2014 17:25, Larry Garfield la...@garfieldtech.com wrote:
On 7/24/14, 2:38 PM, Sara Golemon wrote:
On Thu, Jul 24, 2014 at 12:29 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Zend is only one of many
contributors. Yes, the engine is still
to give us a chance to
design a more consistent library of functions.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the disadvantage is it requires an intermediate value
(string/array) rather than being something as low-level as a parser
rule. I tend to agree with Stas that overloading the operator here
could be confusing.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
in making the syntax
more regular to have to include arbitrary exceptions to a feature just
for lack of unambiguous syntax.
--
Rowan Collins
[IMSoP]
as written, and fix it in the
next release of both the implementation and the spec.
Having the 5.6 spec match behaviour, and starting a 5.7 draft
immediately for implementations to actually target might be a compromise?
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
Lester Caine wrote (on 06/08/2014):
On 06/08/14 11:16, Rowan Collins wrote:
According to the bug report, HHVM also accepts multiple default blocks,
but uses the first rather than the last. It's probably not worth
implementing specific code there to take the last default label just in
order
is also missing, incidentally) is to have one
class, but include methods for interrogating its type - e.g. isBound(),
isBindable(), etc
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andrea Faulds wrote (on 10/08/2014):
On 10 Aug 2014, at 22:00, Rowan Collins rowan.coll...@gmail.com wrote:
You're rather pre-supposing the proposed syntax there, and letting it lead the
semantics rather than vice versa. The point is it would be useful to allow
creation of a pre-bound
:
}
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
at
the same time. One is clearly an error; the other is just poorly written
logic, and you can't make the parser outlaw every instance of poor logic.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
if you want to change the state and jump to a
different label, you have to wrap the switch in a loop, and evaluate it
again. If you specify multiple labels matching the same state, the
second one can never be reached. http://3v4l.org/i3746
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime
Ferenc Kovacs wrote (on 13/08/2014):
Btw. I've added a comment to https://bugs.php.net/bug.php?id=67757 as
I've found some really weird behavior for multiple defaults and I
think that it would be better to try to figure out and fix why do we
pick the last default in the problematic snippet
Ferenc Kovacs wrote (on 13/08/2014):
It is not selecting the first default, it just never needs to look
for a default, because it has already found a matching case label.
yes, and it continues the execution from the first matching case and
correctly evaluates the following defaults,
Ferenc Kovacs wrote (on 13/08/2014):
I think you misunderstood that part, I was thinking about a state
machine like this:
1. function doStuff(){
2. switch($state){
3. case OPENDOOR:
4. if(!opendoor()){
5. break;
6. }
7. $state = SITDOWN;
8. case SITDOWN:
9. if(!sitdown()){
not entirely sure it's a good idea, and can't imagine how
anyone would rely on it (if you have a look at that trasnscript, you'll
find some fun attempts at finding an esoteric use). Is it really that
big an optimisation that it's worth such surprising behaviour?
--
Rowan Collins
[IMSoP]
--
PHP
there, then over-ridden by whatever the user declares.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
If we want optimistic targets, what about a slim 5.7 release in the
first half of 2015 (~9 months), and 7.0 before 2016 (12 to 15 months)?
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 15/08/2014 01:46, Yasuo Ohgaki wrote:
On Wed, Jul 30, 2014 at 9:35 PM, Rowan Collins
rowan.coll...@gmail.com mailto:rowan.coll...@gmail.com wrote:
Making small changes, such as extra function aliases, or identical
versions of existing functions with switched parameter order, just
On 23/08/2014 04:39, Yasuo Ohgaki wrote:
Hi Rowan,
On Mon, Aug 18, 2014 at 12:28 AM, Rowan Collins
rowan.coll...@gmail.com mailto:rowan.coll...@gmail.com wrote:
On 15/08/2014 01:46, Yasuo Ohgaki wrote:
I have previously been tempted by the thought of adding a new set
, at first glance.
I’ve not given this solution deep thought, so I’m sure there are problems I’m
missing.
The biggest one that comes into my mind is how to define a column
that's before the starting token if there are a mix of tabs and spaces
involved.
--
Rowan Collins
[IMSoP]
--
PHP
:
$bar = isset($bar) ? $bar : $baz;
$bar = $bar ?? $baz;
$bar ??= $baz;
Not the most readable, perhaps, but then shorthand and readable are
often in conflict with one another.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
PHP_TYPE_NULL = NULL
Of course, we'd then need to agree exactly which casts are considered
safe...
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
is
'-1.5e-50'?) but it *looks* like the right function, and it has a really
simple name, so people don't bother looking for anything more complicated...
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, these could be special boxed types, which were real objects
acting almost but not quite the same way as the equivalent basic type. Some
languages (e.g. Java) have those, but they're frankly rather confusing, and I'm
not sure what the benefit would be.
Regards,
--
Rowan Collins
[IMSoP
and maintained, but whether it's worth
breaking the BC on this just for the sake of it, I'm not sure...
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the same. But there is no reason for that to stop list($a,) = $foo
being equivalent to $foo[0] for existing strings, and mean first byte.
[1] http://news.php.net/php.internals/72914
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
over the
standard library.
As a userland developer, this is actually rather confusing, and I'd be
interested to know what it would take to come up with some finite set of
base behaviours that documented what each function would do given the
wrong types.
--
Rowan Collins
[IMSoP]
--
PHP
of strict cast which you
would approve of?
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
be as a
feature, rather than just how consistent it is or isn't with other parts
of the language.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
values that
can be provided by the user, or what happens if they don't).
Apologies if I'm missing something obvious here.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
overall behaviour that is a black box.
Please correct me if I've misunderstood that.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Crockford on why JSON requires quoting on all key names), but it
makes things very messy if you try not to have any at all.
--
Rowan Collins
[IMSoP]
Robert Stoll wrote (on 16/09/2014):
I would argue type declaration is wrong as well since it is not a type
declaration as it is known in other languages where the type declaration is
binding. IMO it is more a type check. Consider the following
function foo(Bar $b){
$b = 1; //$b is not a Bar
that with an interface contract, and some
suggestions on what you might want to do instead:
http://stackoverflow.com/q/21665795/157957
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
( func_get_args() as $arg )
{
if ( ! is_null($arg) )
{
return $arg;
}
}
}
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon wrote (on 17/09/2014):
My general feeling is to leave it alone. I agree that it's a misnomer, but as
has been mentioned, it's a well established misnomer. I don't see a big gain
from it apart from academic purity.
I guess in that way it's similar to overloading, which has a
; console.log(x.y) with x as
an empty object is not).
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
compatibility with
existing code, so removing or changing a default parameter requires a strong
justification to offset the problems it may cause users.
I hope this message doesn't sound too negative, and look forward to
clarification of your thoughts.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP
1 - 100 of 1629 matches
Mail list logo
