r file
(which I honestly have no strong opinion on), switching to braces at the same
time makes sense. It's much easier to parse visually (by a human) in that
case, and there's no reason I know of why we couldn't still forbid
non-namespaced code in a namespace-using file to avoid con
A common convention for extra visual clarity is to wrap the body of the
namespace in un-tagged braces. Although the compiler ignores them, some IDEs
may make use of them for improved code assistance." Or something like that.
That is, of course, predicated on the extra braces actually having no
be well-documented.
I overall like this concept. Kudos to Greg, as others have said. One
question I would have is what is the performance hit of braces over a
keyword? (Not a challenge; I genuinely don't know what the C implementation
differences would be that would make a difference.)
--
gt;
> Than
>
> set_error_handler("foo");
>
> The current syntax would still work because of automatic type
> conversion.
>
> Best Regards,
>
> Jeff
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made
On Monday 17 December 2007, Jeff Moore wrote:
> On Dec 17, 2007, at 10:30 PM, Larry Garfield wrote:
> > I'm assuming that making the function above GC-able would be a
> > herculean task
> > at this point, based on previous comments, but I do not actually
> > know
s where going all OO is not a good thing, and
results in more code complexity, not less.
A "complete" namespace implementation supports both classes and functions
equally.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has ma
rides it and
then stubs out to the system tz database? That sounds like an "option just
like Joe's patch" that should work fine.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The latter, I think, would get better
traction with existing developers and be easier to understand (since it uses
the same separator character).
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than
let's call it what it is, and what, honestly, the array [] thread seemed
like: It's not a vote, it's a poll. Confusion solved. :-)
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible
ent, so checking those functions is
basically required if you want to run on a server over which you don't have
absolute control. I wouldn't say that's deprecated or a strict-violation.
So I guess I'm -1: Restore them, always return false, and throw E_DEPRECATED.
--
Lar
t(...) {}
}
That's a bit redundant, but... I think probably acceptable.
So, I think I'd favor get:X set:Y as modifiers, with the assumption that
1) Should accessors ever happen they'd be expected to NOT duplicate the
visibility, either with the option above or something similar.
2) isset and unset can be skipped for now but the RFC can explicitly state that
should they ever be needed, they'd be added in the same way.
Here endeth my analysis. Thanks again, Andre!
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
x27;s close to one and wouldn't require a
separate syntax.
I mention it here mostly for transparency and to make sure we don't end up with
multiple competing RFCs that duplicate functionality needlessly.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
nc('strlen', str: 'foo');
Same statement: Seems logical, although why anyone is still using
call_user_func() I don't know. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote:
> Greetings, Internalians.
>
> There has been much talk of the \PHP namespace of late, including one
> unsuccessful RFC. In the discussion, the pushback broke down into two
> main camps:
>
> * We should never na
email is a good example of what kind the language might look like when
> several such features are potentially accepted in the future.
>
> May I propose that some of us interested in this do a short call over the
> summer on this topic to see if we can align on direction?
I'm open t
On Tue, Jul 7, 2020, at 4:22 PM, Miguel Rosales wrote:
> Larry Garfield wrote on 07/07/2020 16:46:
> > This has reached the 2 week mark, but there's not been much discussion.
> > Anyone else want to weigh in?
> >
>
> I guess I'm missing something obvi
ze even if we could all agree to do so.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Thu, Jul 9, 2020, at 6:55 AM, Rowan Tommins wrote:
> On Thu, 9 Jul 2020 at 09:58, Dan Ackroyd wrote:
>
> > On Tue, 7 Jul 2020 at 15:47, Larry Garfield
> > wrote:
> > >
> > > This has reached the 2 week mark, but there's not been much discussion.
&g
On Fri, Jul 10, 2020, at 3:54 AM, Nikita Popov wrote:
> On Tue, Jul 7, 2020 at 4:47 PM Larry Garfield
> wrote:
>
> > On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote:
> > > Greetings, Internalians.
> > >
> > > There has been much talk of
to properties of the
object. Probably we'd also need to require that properties of by-val objects
cannot be by-ref objects or resources, which seems reasonable to me.
I think that would do a far better job of addressing the shared-mutable-state
issue than reference counting, because it attacks the root problem rather than
a symptom.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
g _toBool() itself. Feel free to steal the user-repo example if you
want.
I have no strong feelings about interface vs. magic method, that's an old race
I don't have a horse in.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Sat, Jul 11, 2020, at 4:04 PM, Olle Härstedt wrote:
> > I think that would do a far better job of addressing the
> > shared-mutable-state issue than reference counting, because it attacks the
> > root problem rather than a symptom.
> >
> > --Larry Garfield
>
ki doesn't use Markdown. It uses some
wonky proprietary ancient mess instead. Now that you have Wiki access you
should probably start using the PHP Wiki instead of Github so that you don't
have to convert a mess of nice formatting from Markdown to PHPWiki-down.
I like this idea
ts to be defined as Falsifiable also. "
What's that about?
"(Including __construct() replacing old style constructors in PHP 7.)" -
__construct replaced old-style constructors in PHP 5. :-)
I think the truth tables have a formatting error; check the last line that goes
wider than the rest. Also, watch out for "smart quotes" in the string parts.
Also, YAY summary tables!
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ls a boolean check (like null) but also has
default values in it for the base case. A user object likely wouldn't use
that, but a value object like an Address very well could.
Until we can support for-reals monads (which would require enums and generics
to do properly; the former is possibl
On Wed, Jul 15, 2020, at 11:43 AM, Marco Pivetta wrote:
> Hey Larry,
>
> On Wed, Jul 15, 2020 at 5:32 PM Larry Garfield
> wrote:
>
> > 1) return null, which is a non-type, and thus you need to make the return
> > type ?User or User|null, which means the call
On Wed, Jul 15, 2020, at 11:59 AM, Marco Pivetta wrote:
> Hey Larry,
> <http://ocramius.github.com/>
>
>
> On Wed, Jul 15, 2020 at 6:55 PM Larry Garfield
> wrote:
>
> > I disagree entirely. The value of a Maybe over just null is
> >
> > 1) You ca
s are already claimed.
https://wiki.php.net/rfc/php_namespace_policy
This is probably (I hope) the final edit of consequence before voting. Speak
now or forever hold your peace. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.ph
thanks to PSR-0, PSR-4, and Composer. Really all that's being done here is
officially reserving and using PHP (and/or Ext) as the "core vendor," and then
following existing conventions. Everything else is already the standard
practice across the ecosystem, just said in more formal words with some
collaboration processes defined.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
tial for php-src to add a number of attribute
classes, which would logically have very generic seeming names. Getting those
out of the global namespace and into a logical organization would be very good.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ives voters
confidence that if the RFC passes the code will actually get completed by the
people that proposed it, rather than just expecting someone else to magically
do it for them.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
f so, recompute the vote as above and go with the result.
@@ may be easier to type than the others, but at the end of the day the parsing
problems it introduces seem like the killer blow to me.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
The vote on the PHP namespace policy is now open:
https://wiki.php.net/rfc/php_namespace_policy
Usual rules, 2/3 required for passage. Vote will be open until 9 August.
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
On Sun, Jul 26, 2020, at 11:24 AM, Larry Garfield wrote:
> The vote on the PHP namespace policy is now open:
>
> https://wiki.php.net/rfc/php_namespace_policy
>
> Usual rules, 2/3 required for passage. Vote will be open until 9 August.
The vote has been closed. Final results:
of #[]
previously, but at least for the use cases i can foresee it's not actually
relevant.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ther.
Supporting both @@Foo and @@{ Foo } sounds really nice on the surface as a
compromise, but runs into the problem of any 3rd party parsers now needing to
do extra work as well. Minimizing work for 3rd party parsers is one of the
main goals under discussion, as I understand it. I&#x
not.
* It's very clearly labeled a survey, not a binding vote.
* RFC authors should use it before an actual vote starts.
* Voters can give the poll results as much weight as they feel like giving it.
I think that could be a useful data gathering tool without rocking the status
quo too much.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
gs or flags or whatnot.
If you want to check the keys of an array, call array_keys() first and use that.
if (any(array_keys($foo), fn($k) => $k %2)) { ... }
all(), any(), and first() all sound like good things to include, but let's not
over-complicate them. We can do better today than we could in 1999...
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
;
> function array_reverse($fn, $arr) { return array_filter(fn($item) =>
> !$fn($item), $arr); }
>
> Anyway, I think that It should be implemented by core, once that we have
> array_filter().
Any boolean function can be inverted with a simple ! in a short closure. I
don'
probably be JIT compiled into a tight loop in machine code.
>
> That's definitely something I'd want to see for array_map/array_filter.
> There's the question of whether it'd be reasonable to omit stack frames
> or whether it's practical to create fake frames
equest.
>
> Nikita
I agree here. _ is already a common pattern in other languages for a
placeholder ignored variable. It's not a big jump for PHP static analyzers to
start ignoring unused $_ variables, and it requires no language changes or
formal standards.
I am skeptical of
o:
class Collection {
public $__T;
public function add(mixed $item) {
if (!$item instanceof $this->__T) {
throw new TypeError();
}
}
}
$c = new Collection().
$c->__T == 'Product';
Which is essentially what you can do in userspace today, but automated. I
don't kn
ards,
> Nikita
I could see an argument for either UseOfMyAttribute.php or
AccessOfAttribute.php. I think I would also favor UseOfMyAttribute.php,
however, because if you get it wrong the place you have to change it is in that
file, so it should obey the setting in that file.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
;
> Any thoughts on this?
>
> Regards,
> Nikita
I don't know if it's safe to change so close to RC; I'd be fine with leaving it
for a version since grouping is in practice so rare. If you decide to change
it now, however, I agree that applying to all items in th
properties, it gets applied to the
property.
If I mark the attribute as being for parameters, it gets applied to the
parameter.
If I mark it for both, or don't restrict it at all, it applies to both.
That may not be how the logic is currently implemented but that's what as a
user I'd find least-surprising.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
an one get the original version? (In SVG format,
because all other logo formats are wrong.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
huge win. Writing good sample code for the documentation
would be an interesting challenge, but it's the sort of thing that can be done
over time.
The interesting question would be how to configure it to ensure it doesn't
become a security issue. We'd probably need to lock down t
is way, the PHP project can maintain its neutrality, while the
> community can iterate quickly on promoting the release of PHP 8.
>
> Cheers,
> Ben
Oh, you snagged that one, eh? :-) I also have gophp.[org|me|info] available if
we want to do something with them.
--Larry Garfield
--
*dons flame retardant suit*
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
rse than an associative array -- from the point of
view of performance, self-documentation, or usability -- is stdClass. :-) I
can't recall using it in the last decade at least, and my code has been better
for it.
Especially now with constructor promotion and named properties, I'd prefer to
just forget that stdClass exists and encourage others to do so as well.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, Oct 20, 2020, at 11:08 PM, Mike Schinkel wrote:
> > On Oct 20, 2020, at 2:19 PM, Larry Garfield wrote:
> >
> > A while back, Nikita mentioned that it should now be easy to offer an
> > abbreviated syntax for functions that are just a single expression. I
> &
On Tue, Oct 20, 2020, at 1:19 PM, Larry Garfield wrote:
> A while back, Nikita mentioned that it should now be easy to offer an
> abbreviated syntax for functions that are just a single expression. I
> decided to take a crack at it and it turns out he was right. I thus
> of
of
some kind" rule, and only some projects adopt it. Basically, a mess.
Whatever we do, it should be language-consistent so that there's no bikeshed
potential.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ing $username,
private string $role,
private string $firstName,
private string $lastName,
) {}
public function getId(): int => $this->id;
public function getUserName(): string => $this->username;
public function getRole(): string => $this->role;
public f
nstruct(public string $name) {}
}
Why is that not OK? Someone mentioned it means you couldn't call a function
there, but... that's not a huge problem because I can't imagine why you would.
If we really wanted to avoid that:
#[Foo(new Bar(name="baz"))]
That would be un
.
>
> Good luck with the RFC.
>
> - Nuno
Yes, that's how it would fall out, assuming multi-line-arrows happen. I'm
honestly still torn on that myself for various reasons, but "=> means
expression, fn means auto-capture, use one or both as appropriate" seems like a
reasonable syntax guideline that we can teach people.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
unclear how/why it would? Please explain?
> 4. Should we be considering other bloat^W features?
> a. Exclusive Union: type SingleSerialization = Stringable ^
> JSONSerializable; // XOR: Must be one, but not both
> b. Blacklist: type AnythingButDOM = !DOMElement;
> My opinion: Hell no. Just spitballin'.
>
> -Sara
Hard pass. At that point, make separate methods.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t said, I don't think they would conflict so I'd be fine with both happening.
+1 from me in concept.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
which would be a
> good start, but I think what's missing the most currently is a good API to
> get inspiration from.
> Is there a filesystem library in another language that is considered
> state-of-the-art at the moment?
>
> — Benjamin
I have heard very positive things about
gt; match($n) {
0 => 0,
1 => 1,
default => $fib(n - 1) + $fib($n - 2),
}, range(1, 6));
print $fib(5); // Does this work?
(No you shouldn't write it like that, but since Fibonacci is the example we're
working with...)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
R-9:
https://github.com/php-fig/fig-standards/blob/master/proposed/security-disclosure-publication.md
It unfortunately never really went anywhere, but I thought it was a good idea.
There's some links there to some prior art we were drawing from, or planning to
draw from. The idea
s of switch() could use match() instead, and as
> such make use of the strict comparison semantics. Only switches that make
> use of non-trivial fallthrough behavior could not be easily expressed using
> match.
>
> Nikita
Disagree. switch is a procedural logic flow control. match is a
> I started an informal discussion for this change during the 7.4 cycle
> already, but decided to postpone the change at the time.
>
> Regards,
> Nikita
Seems well thought-out to me. Endorse.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
on isn't asking why something
isn't a legit file; "missing" and "it's a stupid name anyway and it should feel
bad" and "the disk is missing" are all the same thing as far as it's concerned.
All it's asking is "if I try to open this fil
any typos in the RFC itself
go entirely to me.
*dons flame-retardant suit*
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Dec 4, 2020 7:37:51 PM Paul Crovella :
> On Fri, Dec 4, 2020 at 3:25 PM Larry Garfield wrote:
>>
>> Greetings, denizens of Internals!
>>
>> Ilija Tovilo and I have been working for the last few months on adding
>> support for enumerations and algebraic data
On Sat, Dec 5, 2020, at 3:26 AM, Pierre R. wrote:
> Le 05/12/2020 à 00:24, Larry Garfield a écrit :
> > Greetings, denizens of Internals!
> >
> > Ilija Tovilo and I have been working for the last few months on adding
> > support for enumerations and algebraic da
if something is any enum?
> ` Suit::Spades instanceof Enum`
>
> This basically means that all enumerations would to based on a
> general enum.
> This would be very helpful on providing functionalities especially
> for enumerations thinking about a doctrine enumeration typ
er_Edit];
$this->perms[Role::Admin] = [Action::Order_Read, Action::Order_Edit];
}
public function isAllowed($user, $action): bool {
return in_array($action, $this->perms[$user->role]);
}
}
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Fri, Dec 4, 2020, at 5:24 PM, Larry Garfield wrote:
> Greetings, denizens of Internals!
>
> Ilija Tovilo and I have been working for the last few months on adding
> support for enumerations and algebraic data types to PHP. This is a
> not-small task, so we've broke
g to just be too complicated to
support in practice. I'll make a note in the RFC that they must be unique.
> *Enum & UnitEnum interfaces*
>
> The implementation does not seem to support these yet. Taking the examples
> from the RFC:
>
> Suit::Hearts instanceof Enum;
and scalar enums have a ton of value unto themselves.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
rts would be easy or hard. That would be an
Ilija question.
Assuming it's feasible to do, what do people feel about supporting that? IMO,
cases(), from(), and values() need to be kept no matter what as they're more
self documenting and can be passed around as callables. So the questi
On Mon, Dec 7, 2020, at 9:56 AM, Rowan Tommins wrote:
> On 07/12/2020 15:26, Larry Garfield wrote:
> > Assuming it's feasible to do, what do people feel about supporting that?
> > IMO, cases(), from(), and values() need to be kept no matter what as
> > they're m
On Sat, Dec 5, 2020, at 2:26 PM, Larry Garfield wrote:
> On Fri, Dec 4, 2020, at 5:24 PM, Larry Garfield wrote:
> > Greetings, denizens of Internals!
> >
> > Ilija Tovilo and I have been working for the last few months on adding
> > support for enumerations and algebra
ly thing that passes, that's
still a major win for PHP. It's not as big a win as tagged unions with robust
pattern matching and generics on the side would be, but it's still a big step
forward. By breaking it into chunks, we make it more likely that as much as
can be done will get done, and approved, and into the language, even if the end
result is the same feature set when 8.1.0 gets tagged.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ardless of whether or
not the method in question is on an enum.
Having a way for developers to flag a function as safe to memoize would be
helpful, but is a completely different topic from Enums.
Forbidding enum-bound state is as close to guaranteed idempotence as PHP
allows, which is what the current RFC does.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
https://wiki.php.net/rfc/short-match
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, Dec 15, 2020, at 3:00 AM, Nikita Popov wrote:
> On Mon, Dec 14, 2020 at 6:34 PM Larry Garfield
> wrote:
>
> > I present to Internals this tiny RFC to follow up on the match()
> > expression RFC from earlier in the year. There was solidly positive
> > support f
tion getNumberKind(int $number) => match {
> $number > 0 => NumberKind::POSITIVE,
> $number == 0 => NumberKind::ZERO,
> $number < 0 => NumberKind::NEGATIVE,
> }
> ```
>
> See how natural it looks and reads.
Ah, someone gets what I'm driving
space.
>
> -Sara
It looks like the quoted part from someniatko changed from a named function to
an anon function? Not sure what happened there.
I've included both a named and lambda version of his example in the RFC,
however, and linked to the short-functions RFC as that would allow
pattern matching RFC that Ilija and I
have been kicking around for post-enums:
https://wiki.php.net/rfc/pattern-matching
That's still in the "it would be cool if" stage only, and is IMO off topic from
the abbreviation effort in this RFC.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
nks,
> - Tyson
Well, since I'm quoted... :-)
I'm fine with this, but have one question and one correction:
* If we do eventually end up with list/vec types, would the naming here
conflict at all? Or would it cause confusion and name collision? (Insert name
bikeshedding here.)
objects have what methods on them at
compile time.
It's not perfect, but I think it's a good solution to a long-standing
challenge. (Whether or not such higher order functions belong in the standard
lib is debatable; it probably depends on what the performance difference is.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
s are used in php code)
For those answering in the straw poll, note that the longer the prefix, the
uglier chained calls will get. Whether that's done with pipe or something
else, expect to be typing that prefix a lot. That's why I am OK with most
options except `iterable_`, because that's a lot of needless typing.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ally welcome.
Happy New Year. May it be enumerable.
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
iteup is here:
https://peakd.com/hive-168588/@crell/object-properties-and-immutability
I hope it proves stimulating, at least of discussion and not naps.
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.ph
unction
> color()" after "private function __construct() {}"
Both fixed, thanks.
> Finally, I got a segmentation fault while trying to use what I think is an
> unsupported syntax (removing the ":string" from a scalar enum), where is
> the correct place to report th
On Tue, Dec 29, 2020, at 2:26 AM, Marc wrote:
>
> On 28.12.20 21:23, Larry Garfield wrote:
> > There's been a number of discussions of late around property visibility and
> > how to make objects more immutable. Since it seems to have been
> > well-received i
On Tue, Dec 29, 2020, at 2:48 AM, Marc wrote:
>
> On 28.12.20 21:21, Larry Garfield wrote:
> > Hello, Internalians!
> >
> > After considerable discussion and effort, Ilija and I are ready to offer
> > you round 2 on enumerations. This is in the spirit of the previ
On Wed, Dec 30, 2020, at 2:43 AM, Markus Fischer wrote:
> Hi,
>
> On 28.12.20 21:21, Larry Garfield wrote:
> > The full RFC is here, and I recommend reading it again in full given how
> > much was updated.
> >
> > https://wiki.php.net/rfc/enumerations
>
7;s copy-on-write behavior, full on
immutability doesn't actually waste that much memory. It does use up some, but
far less than you think. (Again, based on the tests MWOP ran for PSR-7 a ways
back.)
> I wonder if that difference can be optimised out by the
> compiler/OpCache: detect c
and immutable mentioned
up-thread is that big of a deal in PHP, specifically. Yes, they're different
things, but the cost of them is not all that different because of CoW, so
considering them separately is not as important as it would be in a language
that doesn't automatically do CoW
y one.
Yes, but with CoW those 3 copies are not that expensive, so we can most of the
time ignore them except as a very micro-optimization. (See previous email.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
es not include enums.
> - Inheritance would work between enums. But only by eliminating some cases.
> I can see how enum RedSuites could extend enum Suites without breaking LSP.
> Not sure if it makes sense to dig on this now.
>
> Regards,
> Alex
Possibly as a future scope, if
On Wed, Dec 30, 2020, at 6:27 AM, Rowan Tommins wrote:
> On 28/12/2020 20:21, Larry Garfield wrote:
> > After considerable discussion and effort, Ilija and I are ready to offer
> > you round 2 on enumerations.
>
>
> Thank you both, again, for all your efforts. I'm
On Wed, Dec 30, 2020, at 12:30 PM, Aleksander Machniak wrote:
> On 28.12.2020 21:21, Larry Garfield wrote:
> > https://wiki.php.net/rfc/enumerations
> Why can't this be simplified to:
>
> enum Size {
> case Small;
> case Medium;
> case Large;
> }
>
>
. And that's when dealing with very small numbers, so
in most cases you're unlikely to notice a difference unless you really are
iterating over something a million times.
I also tossed some big string properties into the class, and while the total
time went up a bit the ratio be
to use.
So, one less foot gun.
Also, one of the extensions planned, as noted, is ADTs/tagged unions. Those
could not have a primitive equivalent, since they're not singletons. Keeping
UnitEnum and ScalarEnum separate allows us to later add TaggedEnum (or similar)
that also extends UnitEnum, but not ScalarEnum.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ady established
in PHP, and i the same as the syntax used in Swift. What you're describing
looks a lot more like a generic. Which... I suppose in some ways this is if
you squint really hard? I don't have much of an argument against it other than
aesthetic. I have no idea what the parser would do with it.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
101 - 200 of 1424 matches
Mail list logo
