ium did in PECL)? Or
should the policy be that there are no namespaces used by the core?
Regards,
--
Rowan Tommins
[IMSoP]
ather subjective; is it the
"@" that makes it familiar? the lack of extra brackets? I'm not sure it's
fair to boil this down to a straight yes/no.
* "Tokens Used" seems to be an implementation detail, with no explanation
of why this would make a difference to anyone's vote.
Regards,
--
Rowan Tommins
[IMSoP]
On Mon, 10 Aug 2020 at 14:56, Benjamin Eberlei wrote:
>
> On Mon, Aug 10, 2020 at 3:40 PM Rowan Tommins
> wrote:
>
>> The question asked was that _if the parentheses were made mandatory_,
>> would
>> this provide the same benefits ascribed to the other syntaxes?
syntaxes?
To avoid repeating myself, here are the previous posts where I elaborated
on this question:
* https://externals.io/message/111312#111342
* https://externals.io/message/111312#111354
Regards,
--
Rowan Tommins
[IMSoP]
always use fully-qualified names in attributes...
Regards,
--
Rowan Tommins
[IMSoP]
ich in my view make this new feature unnecessary.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
/ type of result inferred from
existing constant
function waste_time(BigNum $iterations = GOOGOLPLEX) { ... }
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
arams#vote
[4] https://externals.io/message/110910#110961
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
te static
variables, since right now we don't think of a function as "belonging
to" a file in the same way it would belong to a class.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ointed out are similar to
visibility or scope modifiers - anywhere that could be an attribute will be
parsed as one, not as a statement, comment, or whatever else, so some code
changes meaning, and other code becomes a syntax error.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[Foo]@
With complex parameters:
@@Foo('hello @@ world', (1+2)*3)
@(Foo('hello @@ world', (1+2)*3))
@[Foo('hello @[ world ]', [1,2,3])]
@[Foo('hello @[ world ]@ again', [1,2,3])]@
Regards,
--
Rowan Tommins
[IMSoP]
On Thu, 6 Aug 2020 at 07:40, Derick Rethans wrote:
> On Wed, 5 Aug 2020, Rowan Tommins wrote:
> > The confusing thing about this argument is that as soon as they have
> > arguments, attributes will have an ending delimiter _whatever_ syntax
> > we choose, because nob
process.
Opportunities that might, depending on a whole bunch of other factors,
come in PHP 10.0 or 11.0 are probably not a strong argument for a syntax
option.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https
it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.
I agree that it is probably rarer than //... and /*...*/ but let's avoid
unnecessary hyperbole.
Regards,
--
Rowan Tommins
[IMSoP]
nput is casted to 0 and thus producing
unexpected behaviour if the user is not aware of the current method
prototype.
Unless there are problems with the implementation, this seems like a
straight-forward win.
Regards,
--
Rowan Tommins
[IMSoP]
is perfect, but because I don't think this RFC makes a
good case for a revote, and strongly suspect it will just be another beauty
contest.
Regards,
--
Rowan Tommins
[IMSoP]
on, and what the
impact would be.
My vote, if I had one, would remain under "No" for this re-vote. There
seems to be no reason to allow this vote, but not allow another one next
week with a new suggestion, and nothing objective to choose between the
syntaxes.
Regards,
--
Rowan Tommins
[IMSoP]
useful if it was a re-cap of
arguments discussed in prose elsewhere, but it is not on its own a good
source of information for making a decision.
Regards,
--
Rowan Tommins
[IMSoP]
right of the letters, although #[] is
the only one that doesn't need any use of shift. Which mostly just goes to
show that pretty much any punctuation will be hard to type on some layouts
and easy on others.
Regards,
--
Rowan Tommins
[IMSoP]
tor discussed, this is
basically a subjective feeling, rather than anything substantial.
Regards,
--
Rowan Tommins
[IMSoP]
ance of matching something like "$foo =
$bar<> has a small disadvantage here, but it's also been
thoroughly rejected in a previous vote, and seems unlikely to suddenly make
a comeback.
Regards,
--
Rowan Tommins
[IMSoP]
and what updates the user would
need to make.
Regards,
--
Rowan Tommins
[IMSoP]
- quite the contrary, it will mean
more time is wasted debating every case.
It's worth stressing that naming conventions are not new - we've had them
for global functions for many many years. We may talk about "putting things
into namespaces", but PHP's namespaces really are just names, so this RFC
could easily be called "update naming conventions for classes".
Regards,
--
Rowan Tommins
[IMSoP]
On Thu, 9 Jul 2020 at 18:14, Derick Rethans wrote:
> On Thu, 9 Jul 2020, Rowan Tommins wrote:
>
> > And yet we have repeatedly had discussions about whether this or that
> > feature should or shouldn't be prefixed with a namespace. If you think
> > the correct answe
u be more open to a version of the feature that was opt-in at the
definition site? Then your example could swap the hand-rolled documentation
and validation in "fromArray" for a fully typed signature in
"fromNamedParams", and the only compatibility promises would be ones
already made by "fromArray" anyway.
Regards,
--
Rowan Tommins
[IMSoP]
native I know of is the builder pattern
($builder->withFoo($foo)->withBar($bar)->withBaz($baz)->build()), which at
least makes the boilerplate scale linearly rather than exponentially, but
is still going to require dozens of lines of code to achieve what named
parameters can do with one.
Regards,
--
Rowan Tommins
[IMSoP]
t you're trying to catch here
is programmer mistakes, not unexpected run-time behaviour.
Regards,
--
Rowan Tommins
[IMSoP]
ause you can't guarantee yours is the only reference) or an
optimised copy-on-write (mutate if you happen to have the last reference,
otherwise clone). It would be better for the language to implement those in a
user-friendly way than exposing the implementation details of refcounting.
Regards,
--
tures.
If the input is an actual array or object coming from "outside", you're
probably going to want a more extensible validation system anyway. Those are
really hard to design, and probably best left to userland where people can
choose the tradeoffs they prefer.
Regards,
--
Ro
ious discussions and proofs of
concept before diving in.
[1] https://wiki.php.net/rfc/userspace_operator_overloading
[2] https://externals.io/message/105589
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
olution to the "modified clone" problem of
full immutability (how to implement withFoo methods), since any "frozen" object
could be cloned to get a mutable copy, which would be frozen before passing on.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t also has much lower performance impact. Even the automatic form can probably
be performed by the compiler - e.g. if "new" was called in this function,
insert a call to "freeze" before the first time the object appears as a
function parameter
Regards,
--
Rowan Tommins
[IMSoP]
-type), and __construct() was marked ": void", and
leave the rest of the logic to the generic code for handling those
declarations.
Again, I would be surprised if any style guide would forbid writing
"getIterator(): Traversable" just because the check is already enforced
imp
omplex rules of "it's
optional except when it's not", which I'm personally not a fan of.
Regards,
--
Rowan Tommins
[IMSoP]
ew PHP\* names, and provide a userland polyfill for users upgrading
from the PECL extension?
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
to parse the error message, since
the pattern /unexpected ([^"]+) "(.*?)"/ will always give you a token name
(even if just 'token') and its content.
I can re-visit that part if you feel strongly, though.
Regards,
--
Rowan Tommins
[IMSoP]
fully expect to have a
patch (and, if deemed necessary, RFC) in plenty of time for 8.0.
I intend to post a new thread with examples of old and new messages once
I've finalised the details.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
T
ut, something like: unexpected double quotation mark.
>
That would be a reasonable special-case; theoretically, the same would
apply for a lone single-quote, although I think the parser happens never to
see that as a separate token.
Thanks for the feedback,
--
Rowan Tommins
[IMSoP]
it.md#detailed-design
[2] https://wiki.php.net/rfc/object-initializer
[3]
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/readonly
[4] https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/#with-expressions
--
Rowan Tommins
[IMSoP]
On 29/06/2020 17:21, Marco Pivetta wrote:
Hey Rowan,
On Mon, Jun 29, 2020, 18:19 Rowan Tommins <mailto:rowan.coll...@gmail.com>> wrote:
On Mon, 29 Jun 2020 at 16:44, Marco Pivetta mailto:ocram...@gmail.com>> wrote:
> property accessors seem to perpetuat
nitialise_object($classDefinition);
$newInstance->__construct(...$args);
return $newInstance;
If a constructor returns a value, it is simply discarded, so a signature of
void would be completely appropriate.
Regards,
--
Rowan Tommins
[IMSoP]
t. I also appreciate that I hadn't provided any
public updates on my progress, and what hurdles needed to be over-come.
But you did know I was working on a patch, so the simple solution would
have been to ask me before opening the vote.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Int
sted change was to include column
numbers; this appears to be feasible, but definitely more complex, and
with potential performance trade-offs. I hope to re-visit this later.)
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t;> function(<> int
$var) {};
Finally, typing up those examples, it occurs to me that @@ is quite a
"heavy" symbol - it has a large proportion of black (or whatever colour)
pixels - and inevitably a rather "fussy" one. I find it draws the eye
more than the angle-
he unexpected token was, so that searching for "Parse
error: syntax error, unexpected" wouldn't give enough of a hint?
Other information currently missing from the message - e.g. column
number, hints about unclosed blocks - is likely to be far more useful.
Regards,
--
Rowan Tommins (né Coll
y react to this one better. That's fine; we can make a
decision for subjective reasons, but let's be honest and say that.
Regards,
--
Rowan Tommins
[IMSoP]
-right operators, and so the
immediate association on seeing them is so obvious it's not worth
mentioning; to others, they just look like a new kind of brackets.
That association might actually be a good reason to avoid that syntax,
but if so it should be spelled out, rather than taken as a given.
umber_id", "id", JoinColumn::UNIQUE)
private $phonenumbers;
// Rust-style
#[ManyToMany(Phonenumber::class)]
#[JoinTable("users_phonenumbers")]
#[JoinColumn("user_id", "id")]
#[InverseJoinColumn("phonenumber_id", "id", JoinColumn::U
ing almost the same thing.
> while not having to disable strict_types
It feels a bit like you want to "have your cake and eat it" here - if you want
a loose check and aren't worried about a few unusual values getting through,
why are you running in strict_types mode in the first pl
On 10/06/2020 22:38, Rowan Tommins wrote:
rather than renaming T_PAAMAYIM_NEKUDOTAYIM, we should simply ensure
the user never needs to see it.
I'd like to clarify this slightly: I should have said "beyond renaming
... we should ensure" - I have no particular objection t
here be value in a "lightweight reflection" API, which
gave access to things like this without the full power or performance cost
of Reflection?
Regards,
--
Rowan Tommins
[IMSoP]
rectly by the parser.
In both cases, I think we know roughly what we'd like to see, so there's
not much else to say until somebody looks into actually doing it.
Regards,
--
Rowan Tommins
[IMSoP]
a particularly good comparison for PHP.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
by adding parentheses
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 25/07/2020 16:26, Chuck Adams wrote:
On Fri, Jul 24, 2020 at 1:32 PM Rowan Tommins wrote:
If anything, I would argue for making both of these into errors, if
that's possible. I think the biggest risk with this kind of change is
not existing code relying on the old behaviour, it is code
ous HTTP 1.1 features are enabled in our
client code by default suggests that is frequently not the case.
Regards,
--
Rowan Tommins
[IMSoP]
have been able to tell, the client code now complies
with the spec for HTTP 1.1, although I struggled to find a list of
minimum capabilities.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Wed, 29 Jul 2020 at 03:31, Ryan Jentzsch wrote:
> https://phil.tech/2013/wtf-is-t-paamayim-nekudotayim/
https://3v4l.org/guXbl#v800alpha3
You're welcome.
--
Rowan Tommins
[IMSoP]
because it's increasingly rare for a server to actually
honour the 1.0 spec.
My main motivation for the change is that if someone was writing the
feature today, I don't think it would occur to them to default to 1.0, and
I think _new_ users would be less surprised at needing to opt into 1.0 than
into 1.1.
Regards,
--
Rowan Tommins
[IMSoP]
/message/110004
[4] https://externals.io/message/110910#110961
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
bolt on in a hurry just to solve an issue with named
parameters.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
/5899
I realise it's now rather last-minute for 8.0, so if anyone thinks it
should have more careful thought, or an RFC, it will have to wait. If
there are no objections, though, it would be nice to have it merged
before the freeze.
Thanks,
Rowan
On 21/05/2020 22:53, Rowan Tommins wrote:
Hi
ot;PHP"
in its name is a " fake namespace" at all - it is an object representing a
token of PHP source code, and thus a PHP token. Even inside a namespace,
there would be an argument for giving it that name.
Regards,
--
Rowan Tommins
[IMSoP]
tory (i.e. @@Deprecated() rather than
@@Deprecated)? The rules for what could appear between @@ and ( are pretty
simple, and finding the correct ending ) should be pretty much the same
effort as finding the correct ending ], since both can occur in matching
pairs inside the argument list.
Regards,
--
Rowan Tommins
[IMSoP]
not enjoy going through
every Composer package in my vendor directory, checking for or supplying an
appropriate patch, and then waiting for a tag or forking to create my own.
Regards,
--
Rowan Tommins
[IMSoP]
you the same question I have asked others, but without much
response: would you vote Yes to an alternative proposal to officially adopt
a policy of _never_ using the PHP\* namespace, to eliminate future debates
about when to use it?
Regards,
--
Rowan Tommins
[IMSoP]
needing to skip parameters, it would be great to see some ideas to make
those alternatives easier. For instance, if you think parameter objects
plus the builder pattern is the right way to go, how can we reduce the
boilerplate currently required to define the builder class?
Regards,
--
Rowan Tommins
[IMSoP]
lumn showing those
additions: https://rwec.co.uk/x/php-parse-errors/comparison.html
If there's no other comments or objections, I would appreciate if
someone could merge this in so it can be tested in the next alpha :)
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
arts: [ '<', '>Hello ', '' ],
expressions: [ $tag, $_GET['name'], $tag ],
modifiers: [ ['raw'], [], ['raw'] ]
);
It will take a while to figure out the details, but I think a powerful
feature like this is more worthy of adding new syntax.
[1]
https://developer.mozilla.org/en-US/docs
they both pink?
both purple?
Note that Larry's longer term plan is for "algebraic data types",
including "tagged unions": https://wiki.php.net/rfc/adts Unlike
straight-forward enum cases, these are not singletons, and each instance
has its own associated state.
Regards,
se I was
starting from that position: assume they have *no* features, and add the
ones we think are necessary and achievable.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
lly
be on the "just use explicit methods" side.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
geably, since constants
and cases are de-referenced with the same syntax
assert(Suit::Spades === Suit::Pikes);
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ation than using the default object format and breaking
the singleton-ness of the case objects.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
min;
}
}
}
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
y the same performance as passing or comparing a bare integer.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
create some
subset of objects ("structs"?) inside static contexts.
That can be entirely parallel to a feature that lets you wrap a list of
attributes inside another attribute, and does some recursive magic with
reflection to let you delay calling their constructors.
Regards,
--
Row
need a whitelist of all built-in
operations which were side-effect free (i.e. no file writes,
configuration changes, output, etc, etc).
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
afe return value, and throwing an
exception is more justifiable.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
that "foo\0bar" is
a "bad value". Clearly, somebody thought so and accounted for it as such
in the implementation, but it would never have occurred to me if I
hadn't read this thread.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Deve
On 2 December 2020 22:38:13 GMT+00:00, "Björn Larsson"
wrote:
>One could add that here the PHP programmer need to do work that
>basically
>replicate how the code worked earlier for little gain.
Just to reiterate, the previous implementation was also bad - it returned an
entirely undocumented
lue
which contains "\0" is "not what it expects", and I don't think I would
ever have guessed that before reading this thread.
So I stand by my assertion that this behaviour was both undocumented and
unexpected.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP
that I don't need to rely
on all services cooperatively exiting in good time
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
independently is
sensible, and imagine that most users will want a much higher clock-time
limit than the CPU-time limit.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
bably "the same as the current timeout
setting", but spelling it out would help to picture when this feature
might or might not be useful.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
) { ... }
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
d [$foo, 'bar'] respectively;
if it (or a variant of it) returns a Closure, it would be the
(optimized) equivalent of passing those to Closure::fromCallable.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https:
l_fibonacci = $fibonacci;
$fibonacci = function (int $n) { return rand(0, $n); };
echo $this_is_the_original_fibonacci(10). "\n";
The $fibonacci inside the closure would be a normal local variable,
which just happens to have the same name as the one outside, so
assigning to one would have
a beautifully timed e-mail - "11/11/2020 20:20 UTC"!]
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
" would just be a means to the end of removing the
option, but it's not clear that the case for doing that is any stronger than it
was 5 years ago.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
where it makes code hard to follow, and leads to subtle bugs. That's why
I would like the two syntaxes to feel like equal options to choose between.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ts".
3. Vote to switch to a less verbose syntax [...]
The downside is that...
Let me stop you there. The downside is that a mob of Internals regulars
will come to your house and lynch you for asking them to vote on the
same thing yet again. It just ain't gonna happen.
Regards,
--
Rowa
attributes.
There is no artificial limitation; there is a binary choice: does #[Foo]
represent an object or a list with one item in? This is completely new syntax,
so there is nothing for it to be inconsistent with other than itself.
I am arguing that having it represent a list with one item in i
very easily" do this? Have you looked
into how it would need to be implemented, and what edge cases we would
need to consider?
At risk of sounding like a broken record: Nikita did look into it, and
documented his conclusions in the RFC.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
ot;short_bio" => #[
Assert\NotBlank,
Assert\Length(
max: 100,
maxMessage: "Your short bio is too long!"
)
]
],
allowMissingFields: true
]
Regards,
--
Rowan Tommins (né Coll
quivalent, then all cases
> must have a unique scalar equivalent defined explicitly.
enum Suit: string {
case Hearts;
case Diamonds;
}
Presumably, this would result in an Error being thrown when compiling the
declaration.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Develop
immediately replace their original,
and optimise it to an in-place modification. In other words, compile
$foo = clone $foo with { x: 42 } to $foo->x = 42, even if the clone is
actually in a "withX" method.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Develo
s = 'S';
}
It seems fairly reasonable for the enum version to allow the same syntax:
enum Suit: string {
case Hearts = 'H', Diamonds = 'D', Clubs = 'C', Spades = 'S';
}
Or, for a non-scalar enum:
enum Suit {
case Hearts, Diamonds, Clubs, Spades;
}
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Int
iption() {
return match($this) {
self::PENDING => 'Pending Payment',
self::CONFIRMED => 'Confirmed',
self::CANCELLED => 'Cancelled',
};
}
}
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
s you say can easily be
added later.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
301 - 400 of 1094 matches
Mail list logo