ht-to-left override characters?"
- at least one form of normalization, but probably several
If there was serious work on a new string API in progress, a freeze on
additions to the current API would make sense; but right now, the
byte-based string API is what we have, and I think this function i
gt;next();
$f->rewind(); // this currently throws an error, and would echo 'Begin'
again?
Regards,
--
Rowan Tommins
[IMSoP]
e at least a roadmap for sorting out those
questions in the official distribution before it felt like a properly
supported part of the language.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that all requests can explicitly share things with. I'm not sure that
would work well for Web Sockets, because it still relies on the
traditional request-response cycle, but I've never really used them, so
don't know what kind of architectural patterns make sense for them.
Regards,
--
Ro
based on the current state of
the world". I don't think that applies here - any file will have been
written with one set of rules in mind, so "use whichever namespace rules
are currently recommended" doesn't really make sense as an option IMO.
Regards,
--
Rowan Tommins (né Coll
dn't leave a process running
that was connected as one end of a web socket, but doing so would be
pretty useless if there was no API to send and receive data over that
socket.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
an't think of any
situation where I would want a change to the default mode in the engine
to cause my code to be interpreted in a different way, so a 'default'
option makes no sense to me.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To u
is "array-like" or not, and
which attributes a particular function actually cares about.
A general "intersection type" system might be more useful, because then you
could require the parts you specifically needed, such as
"traversable" or "traversable".
Regards,
--
Rowan Tommins
[IMSoP]
duct", there's no reason <=
couldn't mean "derive from"
- Not assuming any relationship between operators once they've been
overloaded; so implement <=> doesn't imply availability of < and >
unless the user has opted into that relationship (e.g. using a Trait to
i
; trigger an array cast if the object
isn't iterable? Should foreach()? Should strict_types change that behaviour
as it does for __toString(), even though it currently only applies to
scalar types?
Regards,
--
Rowan Tommins
[IMSoP]
in your server logs.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
cause code will be out there which lists such constraints but violates
them, and will suddenly fail if the checks are enforced.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that get in people's way.
It partly depends what kind of checks were being done, I guess, and
therefore how much time it would take to run, and how much of a project
it would need to analyse at once.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e? That might mean making them explicitly aware of other
threads, or running them all on one thread but in a series of
asynchronous functions (as I understand it, that's how node.js works).
It's definitely an interesting question to explore, though.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
hat isn't the default. This happened to Wikipedia: they named
their default skin 'standard', then regretted it when they changed the
default to be something else.
Regards,
--
Rowan Tommins
[IMSoP]
extension is not the reason it's
incompatible with your existing code, and building a similar implementation
into PHP under a different name wouldn't make the migration any easier.
Regards,
--
Rowan Tommins
[IMSoP]
thumb for that earlier: "default" makes sense
when the setting *doesn't actually matter*, and you want to delegate the
decision. That doesn't seem to apply to this case.
Regards,
--
Rowan Tommins
[IMSoP]
he
default for PHP; you would know that this particular file will only run
correctly in mode A. So you would specify mode A at the top of the file,
not 'default'.
I have genuinely tried to come up with a situation where 'default' would be
useful, and I have failed.
Regards,
--
Rowan Tommins
[IMSoP]
quot;$var->getRawText()", all of which might exist on
one class, and any of which might be chosen as the implementation for
__toString()
Regards,
--
Rowan Tommins
[IMSoP]
On Fri, 14 Feb 2020 at 11:09, Rowan Tommins wrote:
>
> That would also cover the fluent interface case:
>
> after delegate setFoo {
> $this->delegated = $return;
> return $this;
> }
>
I just realised that this could be easily extended to share an
implementat
h booleans, there is at least a consistency between those two
operators, even though it's consistently weird. There's definitely a
strong case for making them match +=1 and -=1 though.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To u
SERVER. Then my dream
of deprecating $_SERVER could mean something other than moving it into
an object.
I hope I haven't left any unfinished sentences as I went back and forth
through this! And thanks again for taking the time to engage with me.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ed by Go which specifies that all error messages
> should be lowercased for the exact reason that David suggests.
>
Like Nico, I'm not sure what lowercase is easier for. Can either of you
expand on the reasoning / use case?
Regards,
--
Rowan Tommins
[IMSoP]
9e5b23717d/Zend/zend_operators.c#L2299
- decrement_function (has neither):
https://github.com/php/php-src/blob/26327bcd3b6375a4883f00a289ba129e5b23717d/Zend/zend_operators.c#L2359
Regards,
--
Rowan Tommins
[IMSoP]
ing
it to end-users, you should probably be thinking about i18n anyway, and can
load your own English translations (and user-friendly summaries) for
whatever context you want to show them in.
Regards,
--
Rowan Tommins
[IMSoP]
that it's not the intention of the feature (if we agree that it's not the
intention; maybe some people here are really hoping to use it that way?)
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
{
return PHP_OPERAND_TYPES_NOT_SUPPORTED;
}
}
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ernal initialisation logic doesn't
have to actually call it, it can just initialise the private state directly.
Regards,
--
Rowan Tommins
[IMSoP]
ry interested to see.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
/blob/9acb06041cc88b5c14d40f8cd9a74dd14d7ac786/src/Symfony/Component/HttpFoundation/Request.php#L1741
[2]
https://github.com/laminas/laminas-diactoros/blob/b36d6bf376b03dfc3190b1065630090e57f2e20d/src/functions/marshal_uri_from_sapi.php
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PH
te: trying to build a single set of classes which
include a system for getting global state AND a system for parsing it in
different ways AND an in-built validation API seems like a mammoth task. And if
you keep it monolithic, any feature you miss or make a mistake on is much
harder to fix later.
.
>
That's a lovely example of why treating Unicode as a character encoding is
the wrong mindset.
I would love to see more people using ext/intl rather than ext/mbstring,
and more ICU features like this being included.
Regards,
--
Rowan Tommins
[IMSoP]
efer-value" arguments.
My current opinion is that I'd rather wait for the details of out and inout
parameters to be worked out, and reap higher gains for the same cost. For
instance, if preg_match could mark $matches as "out", I'd be more happy to run
in a mode where I needed to
On 22 February 2020 06:50:46 GMT+00:00, Mike Schinkel
wrote:
>> On Feb 21, 2020, at 5:20 PM, Rowan Tommins
>wrote:
>> My instinctive reaction is still one of frustration that the pain of
>removing call-site ampersands was in vain, and I will now be asked to
>
..$args) to pass through the parameters.
But Closure::callable is able to copy the signature of the original
function, including type information [1], so our hypothetical ::callable
could do the same.
[1] https://3v4l.org/XBOmJ
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Interna
r, because there is no
function called translate; or it will give you a fully-qualified name,
which isn't what you wanted, you just wanted the string 'translate'.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
; 'Acme\Global\I18N', 1 => 'translate');
# this was what was intended
If you didn't want to quote the method, you'd need some other syntax
that took both class and method name, like:
[I18N, translate]::callable
Or as proposed elsewhere in the thread:
$(I18N::translate)
Regards,
--
Row
thout casting. I'm also not sure what the object would do, other
than feel nicer from a type system point of view.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
/manual/en/language.operators.increment.php
[5] https://wiki.php.net/rfc/normalize_inc_dec
[6]
https://php-lxr.adamharvey.name/source/xref/master/Zend/zend_operators.c#2359
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
On 15/02/2020 18:11, tyson andre wrote:
My opinion is that it'd be more consistent for `--` to work like `-= 1` (e.g.
become `-1`).
It might break some code, but that code was probably incorrect.
Yep, this is precisely the way I see it.
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP
,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 14 February 2020 00:39:15 GMT+00:00, Mike Schinkel
wrote:
>> On Feb 13, 2020, at 7:24 PM, Rowan Tommins
>wrote:
>>
>> An idea I had earlier which might solve some of them is if what was
>returned was not a normal Closure instance, but a new class like
>
calling
convention for PHP scripts would definitely add value, and make them a true
replacement for the superglobals, but that would be a very different RFC.
However well designed this extension is within itself, I think it needs a
stronger description of who should use it and why.
Regards,
--
Rowan Tommins
[IMSoP]
for "into" and "out of".
I think it would benefit the RFC to take a stance on that question, and build
the feature around it.
[1] https://news-web.php.net/php.internals/108347
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ature, you might as well implement the method in full.
Regards,
--
Rowan Tommins
[IMSoP]
t coming across as too negative. Maybe our
visions for what this should be are just too different, but some mixture
of hope and stubbornness makes me want to keep nudging it somewhere
"better".
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
eta-programming,
meta-classes, that kind of thing - then defining new meanings for
individual operator symbols would make more sense.
[1] https://news-web.php.net/php.internals/108347 - not showing on
https://externals.io for some reason
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PH
On 13 February 2020 03:33:32 GMT+00:00, Mike Schinkel
wrote:
>> On Feb 12, 2020, at 5:47 PM, Rowan Tommins
>wrote:
>>
>> On 12/02/2020 03:58, Mike Schinkel wrote:
>>> Returning a_closure_ instead of a string would be providing a
>feature we_already_ hav
On 12 February 2020 23:12:34 GMT+00:00, Manuel Canga
wrote:
>El mié., 12 feb. 2020 23:01, Rowan Tommins
>escribió:
>In your example, you has the same options:
>
>>
>1. Change import
>2. Add namespace:
>
>['Acme\Global\I18N',\translate::function]
There is no col
ld match the current behaviour of
::class.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 8 Jan 2020 at 20:28, Mike Schinkel wrote:
> > On Jan 8, 2020, at 5:48 AM, Rowan Tommins
> wrote:
> >
> > I think immutable variables very much address the use cases you're trying
> > to address, except for the additional requirement about which syn
k in cases like this, the upgrading notes should link specifically to
one or more such tools.
Even with such a tool, it's potentially quite a disruptive change, so we
need to decide how important we think removing this syntax would be.
Regards,
--
Rowan Tommins
[IMSoP]
eculate whether it might have been designed how it is anyway without that
history. Ultimately, the contract is that (string)$foo->getMessage() won't
error, which is ... kind of useful, I guess?
Regards,
--
Rowan Tommins
[IMSoP]
dded to the list, but it might turn out not to be callable when it
was accessed later.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nd a return type of $this would
explicitly prevent that.
If we add ": $this" alongside ": void", I wonder where that takes us next -
what other constraints on a function can be expressed using that notation
which aren't contracts on the value seen by the caller? If we don't want to
explore that question, should we avoid adding ": $this"?
Regards,
--
Rowan Tommins
[IMSoP]
able again is to pre-define the namespaced
function in my startup code, at which point I don't need function
autoloading.
Regards,
--
Rowan Tommins
[IMSoP]
ed, so this
kind of case would be much more likely to bite people.
Regards,
--
Rowan Tommins
[IMSoP]
and-line is probably
used much more rarely, but given how easy it is to incidentally pull in
dozens of classes from a third-party library, maybe that's something that
should change?
Regards,
--
Rowan Tommins
[IMSoP]
utoloader *at all* unless we know the fully-qualified name, and give up
trying to "square the circle" by combining fallbacks with autoloading for
unqualified names?
Regards,
--
Rowan Tommins
[IMSoP]
thing like:
public static string $baseUrl {
readonly,
get => $this->baseUrl ??= Config::get_options('api_base_url')
}
or:
public static string $baseUrl {
readonly,
lazy-load => Config::get_options('api_base_url')
}
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Inte
C, but we'd need to think through the different
combinations and make sure they behaved consistently and intuitively.
Regards,
--
Rowan Tommins
[IMSoP]
le-time so that multiple different
versions of the code can be created from the same source, but constants
are still constant at run-time. I know there are tools out there already
to do this, but have never used one.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
in advance. As far as I know,
PHP's autoloading is an anomaly among programming languages, and maybe
it has outlived its usefulness.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nclusion sometime in the 80's and have yet to see
anything that changed my mind.
Many people would say the kind of global state you're talking about is
an anti-pattern. I'm just looking for solutions to your use case, which
as I understand it is values which change rarely based on configuration.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
thing.
I would be interested to hear more about why you think pre-processing
doesn't suit your use case. It seems like a good fit to me:
- naturally fits with code expecting compile-time constants
- no run-time overhead if done as part of deployment
- can be implemented using succinct syntax, rather t
namespace, evaluate them, and substitute
the result into the AST. Then write the modified AST to a new PHP file,
and deploy that to your server.
Obviously easier said than done, but there are tools out there like
https://preprocess.io/ which do some quite powerful things with this
approach.
etation as a constant, like:
const CLASS_NAME='MyClass';
var_dump( $string instanceof ('' . CLASS_NAME) );
Another edge case of an edge case, of course, but a mark against that
option in my view. :)
Regards,
--
Rowan Tommins
[IMSoP]
un-time. If we could treat OpCodes as a stable target, like .NET CLI, or
Java bytecode, it could target that instead, but it wouldn't actually make
much difference to the operation of the pre-processor. There is of course a
side-effect that the resulting PHP code can be read by a human, making it
easier to debug.
Regards,
--
Rowan Tommins
[IMSoP]
of the VM's runtime state to allow code to be
executed rather than just compiled. There'd also be cases like command-line
unit tests where users would still need to mess around getting the
environment right, just like with a traditional build step. It mostly boils
down to "run build step automatically on server start", rather than
actually eliminating the complexities of the build step itself.
Regards,
--
Rowan Tommins
[IMSoP]
to emulate other features like named constructors, as
you show in the RFC.
The fluent interface example is interesting, because it doesn't actually
involve late static binding at all, we just need some way to say "what
comes out is the same type as what goes in".
Regards,
--
Rowan Tommins
[IMSoP]
t seem very helpful.
Perhaps the simplest solution is to have a restriction that the operator
overloads _must not_ specify types in their signature?
Regards,
--
Rowan Tommins
[IMSoP]
would in some ways be better, but one of the nice
things about annotations/attributes is that they provide a very flexible
mechanism for defining new features.
Regards,
--
Rowan Tommins
[IMSoP]
On Tue, 10 Mar 2020 at 11:46, Mike Schinkel wrote:
> > On Mar 10, 2020, at 7:36 AM, Rowan Tommins
> wrote:
> > I think that applies to our case equally: any punctuation or keyword is
> > just a separator between the main function declaration and the specific
> > attr
that all the other languages referenced in the RFC
use punctuation, rather than keywords, for their equivalent functionality:
C#: [Foo]
Rust: #![Foo] or #[Foo]
C++: [[Foo]]
Java: @Foo
ECMAScript (proposed): @Foo
Go: `Foo` or "Foo"
Doctrine et al: /** @Foo */
Hack: <>
That doesn't mean PHP couldn't buck the trend and use a keyword instead,
but we'd need a strong reason to do so.
Regards,
--
Rowan Tommins
[IMSoP]
On Tue, 10 Mar 2020 at 10:54, Rowan Tommins wrote:
>
> C#: [Foo]
> Rust: #![Foo] or #[Foo]
> C++: [[Foo]]
> Java: @Foo
> ECMAScript (proposed): @Foo
> Go: `Foo` or "Foo"
> Doctrine et al: /** @Foo */
> Hack: <>
>
>
To add to that list, Python de
On 01/03/2020 21:23, Rowan Tommins wrote:
https://wiki.php.net/rfc/increment_decrement_fixes
Hi all,
I have just posted a substantially rewritten version of the above RFC.
* The proposal to change boolean behaviour has been dropped.
* More justification has been included for treating nulls
{
echo 'Override';
}
}
(new B)->call(); # echoes 'Override'
Regards,
--
Rowan Tommins
[IMSoP]
re of that project.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
mething(Action $what, int $howManyTimes):
boolean {
// ...
}
There's plenty of other possibilities we could consider, though - again,
see the Python wiki link for a whole range of proposals they had for
decorators, and we may be able to find similar lists to learn from for
other languages.
Regards,
--
Rowan Tommins
[IMSoP]
and $_POST has become
"input". Maybe $request->cgi or something?
CGIRequest->cgi might feel awkward, but it's no worse than the current
ServerRequest->server, and I think naming it that way gives a better
hint as to why the array has such an odd collection of things in it.
R
,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
That said, as it seems I am the only one on the list who has commented
that really dislikes this syntax
You could equally say I'm the only on the list who is actively defending
it. If you look at discussions of the RFC off-list, "nice idea, horrible
syntax" is a recurring theme, so exploring alternatives is definitely
worthwhile.
Regards,
--
Rowan Tommins
[IMSoP]
can consider in a new proposal. If you
haven't already, you could try contacting the author as well.
In general, I think it's an interesting idea, but as the saying goes "the
devil is in the detail", so I don't have much to say without a concrete
proposal for what it would look like.
Regards,
--
Rowan Tommins
[IMSoP]
heading in the RFC, and some but not all are labelled "not part of the
RFC". It might be useful to have a clearly separate "Possible Use Cases"
header, and a summary somewhere of which interfaces and classes would
actually be provided by the initial implementation.
Regards,
--
Rowan Tommins
[IMSoP]
Require(Table::class) >> on interfaces, and << Inherit >> on
attribute definitions. Then a checking tool could look up the inheritance
tree and identify missing attributes to complain about, or inherited
attributes to copy.
Regards,
--
Rowan Tommins
[IMSoP]
native attribute syntax to build
them on top of would be a huge step forward.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e no expectation that I could initialize a variable in both
the property definition and the constructor.
Regards,
--
Rowan Tommins
[IMSoP]
ropping the special semicolon handling would mean
it either did the expected thing or gave a parse error straight away.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
on I'm less bothered by the angle-bracket syntax
than others is that I can count the number of times I've used bit shifts on
the fingers of one hand, so I don't read it as "reusing the left/right
shift token", I read it as "enclosed in double angle brackets".
Regards,
--
Rowan Tommins
[IMSoP]
d ) {} } // implicitly
aliased, $baz->thing(id: 42) will set $bazId=42 based on the name in the
interface
class Wrong implements Foo { function thing( :$wrongName ) {} } //
Error: tries to accept named parameter "wrongName", but interface
requires it to accept named parameter "id" ins
akes the single
expression form particularly useful in PHP, so I'd love to see the RFC focus on
that.
We can always add statement blocks in later, either as a special case as
currently proposed, or because we're adding them elsewhere, and perhaps with a
way to return a value rather a requirement not to use it.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
this? If not, I might be inclined to do so,
because I know I'm not alone in liking the expression part as a
standalone feature, without the complexity of using it as a flow-control
statement as well.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing
t's a bad idea would seem sufficient.
But perhaps I'm missing something more fundamental that makes you feel that
inheritance should be restricted?
Regards,
--
Rowan Tommins
[IMSoP]
f match supports blocks, but the syntax and
behaviour is unintuitive, we'll be stuck with another feature that
nobody likes very much but we can't easily replace. Worse, the RFC might
lose support based on that part, and we'd miss out on getting a really
nice new expression.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
tics of statement blocks. They "poison the barrel" for
me. That's a real shame, because I really like the core of the proposal.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ed after this RFC was
accepted, my interpretation of the text would be that it must be placed in
the \PHP namespace, because it is "tightly coupled to the internals/engine
of the PHP interpreter".
Regards,
--
Rowan Tommins
[IMSoP]
xponentiation:
var_dump(2 ** 3); # int(8)
var_dump(2 ** 3.0); # float(8)
var_dump(2.0 ** 3); # float(8)
var_dump(2.0 ** 3.0); # float(8)
My impression is what people consider "good" use of operator overloading is
much closer to "make things act like built in numerics" than "make
operators with fancy syntax", so some form of symmetry is necessary I think.
Regards,
--
Rowan Tommins
[IMSoP]
ose it
}
{
let $fh2 = fopen('/tmp/foo', 'wb');
flock($fh2, LOCK_EX); // won't obtain lock, because $fh1 is still
open, but no longer accessible
}
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
enting
it this way?
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ield. Sometimes that wouldn't matter, but again, it
limits the cases where this syntax would be useful, even if we had property
setters.
Regards,
--
Rowan Tommins
[IMSoP]
101 - 200 of 1077 matches
Mail list logo
