y
impression.
I can provide an RFC if it sounds usefull and if I get Wiki karma
Thanks
--
Michał Brzuchalski (aka brzuchal)
posiible.
P.S. We've meet on PHPCon'15 in Poland, thanks for +1.
Cheers,
--
Michał Brzuchalski (aka brzuchal)
2016-04-05 11:13 GMT+02:00 Marco Pivetta :
> Hi Michał,
>
> First of all: +1 to this: very useful for value objects!
>
> A few questions:
>
> * can you re-d
Hi,
2016-04-05 12:13 GMT+02:00 Marco Pivetta :
> Hi,
>
> On 5 April 2016 at 12:06, Michał Brzuchalski
> wrote:
>
>> Hi Marco,
>>
>> Ad. 1 it is posiible to redeclare in a sub-class final property as
>> non-final, here is some gist presenting
Hi Robert, Marco and Chris,
now I see your point. Lastly I've found in DZone newsletter about Java
putting `var` and `val` keywords, interesting is the second which is going
to be used in case of immutable "variables" like a "values" (that's where
`val` came from) see here http://openjdk.java.net/
nual page when they search for this new feature that might make it
> > into core at some point. :)
> > --
> > Richard "Fleshgrinder" Fussenegger
> >
>
> I agree with all of that, +1.
>
> >
>
Hi,
personally I prefer Annotation word instead of Attributes because of my
language (Polish) discrepancies in usage as "class attribute" in Polish
means quite the same as "object property" in English and may came to
missusage of that name - this info is also on Wikipedia
https://pl.wikipedia.org/wiki/Atrybut_(programowanie)#Poj.C4.99cie_atrybutu_w_programowaniu_obiektowym
Annotation in Polish in Software Development is uniquely associated with
the Attributes in your meaning exactly the same as Java Annotaitons and
this is clearly understood for eg. Cay S. Hortsmann in "Java 8"
in translation into Polish is talking about Annotations.
For eg. in Symfony docs translation into Polish
http://symfony-docs.pl/bundles/SensioFrameworkExtraBundle/index.html also
is usage of Annotation (Ctrl+F "adnotacje") - this is official
documentation.
Thats why IMHO Annotation name should be retained.
Thanks,
Regards,
--
Michał Brzuchalski
2]
>
>
> In general, I see two alternatives:
>
> 1) Pass short closures and then include a special case of that special
> case that effectively gives us comprehensions over foreach, if, and yield,
> but with fewer seemingly-stray characters.
>
> 2) Steal a completely different syntax from some other language that is
> still terse but less confusing. The main alternatives to "square brackets
> around a for loop" syntax seem to be:
>
> A) Chained filter() and map() methods
> B) SQL-like keywords
> C) Use <- somehow.
> D) Use a different starting character before the [] so that the parser
> knows some new funky order of stuff is coming.
>
> I am open to both options, of course contingent on someone willing and
> able to code it.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
Great work and I like the idea in general.
BR,
--
Michał Brzuchalski
Hi CHU Zhaowei,
Where can I find first RFC version? Revisited RFCs AFAIK should be served
under different name.
Personally I liked key preserve behavior. Without it use of spread operator
I array expression would have minor use. But this is my personal feeling
about only.
I think I'm missing som
pt., 5 kwi 2019 o 08:56 CHU Zhaowei napisał(a):
> Here is a MDN document for spread operator in JS:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_array_literals
> and hope you find more useful examples.
>
The next paragraph in MDN document
_operator_for_array#string_keys
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
hat, either way, we're
delivering feature
which has very limited usage which can be confusing, cause I can
array_merge or
use + operator so why can't I use keys with spread operator if I already
have them in
my generator, iterable or array which came from for eg. json_decode or
whatever.
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
or
> (Foo) +$bar, etc.
>
Wouldn't that be possible to differentiate consts with class names if we
merge symbol tables and allow only one symbol with the same name?
I know this is huge BC break but AFAIK in the past, there was a discussion
about merging symbol tables.
--
regards / pozdr
e boundaries of
namespace scope
or package scope (whatever you call that) symbols without a root namespace
file.
I can imagine some can use explicit require to load library class to skip
scoped declares,
autoloads or whatever lands there.
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
le => Symfony\Component\Console\
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
m pretty sure I've mentioned that earlier.
If we wanna shape package for PHP then the separate discussion could be a
good idea.
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
Hi Sergey,
pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev
napisał:
> As I understand, in P++ it was planned to drop the legacy code, add new
> functionality and painlessly implement BC.
>
> Who wants – migrates the PHP project in P++, who doesn't – continues to
> use PHP.
>
> New projects, f
Hi Zeev,
pt., 9 sie 2019, 14:23 użytkownik Zeev Suraski napisał:
>
>
> On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
>> Hi Sergey,
>>
>> pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev > >
>&
k a package and declare an unrelated file as part
> of it, but I don't think that's an issue: the situation is the same as for
> namespaces, where one can hijack a third party vendor namespace. In
> practice, it proved not being an issue, and the original author's intent is
> clear: "this is my namespace/package, if you mess with it, fine, but you're
> on your own".
>
> Nicolas
>
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
t we should
> not ignore.
>
I did some writings on that
https://brzuchal.com/posts/packages-in-programming-languages/ was a little
hurry
but tried my best to grasp key aspects of package / module concept in other
languages.
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
mix normal PHP code with package definition,
cause every possible PHP syntax
we would agree, opens the door to add something more to that file, for eg.:
# package.php
https://wiki.php.net/rfc/namespace_scoped_declares#motivation_and_vision
[2] https://www.php.net/manual/en/function.register-tick-function.php
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
śr., 14 sie 2019 o 11:01 Rowan Collins napisał(a):
> I don't see this as a problem. Right now, PHP doesn't care how many
> files you put your code in. As far as I know, you could concatenate the
> entirety of Laravel into one PHP file, and applications would not be
> able to tell the difference.
ot;. The userland part of the
> autoloader already doesn't know which of those it's looking for, so the
> only constraint is that the names can't collide, so you couldn't name a
> package the same thing as a class.
>
>
Exactly so how would it know from string
śr., 14 sie 2019 o 12:11 Rowan Collins napisał(a):
> On 14/08/2019 11:07, Michał Brzuchalski wrote:
> > Exactly so how would it know from string name either it should load class
> > from src/Foo.php or src/__nsmeta.php if there is no information?
>
>
> It wouldn't.
śr., 14 sie 2019 o 12:17 Michał Brzuchalski
napisał(a):
>
>
> śr., 14 sie 2019 o 12:11 Rowan Collins
> napisał(a):
>
>> On 14/08/2019 11:07, Michał Brzuchalski wrote:
>> > Exactly so how would it know from string name either it should load
>> class
>>
idea and we should not change the way comments work
especially inline comments which even aren't kept in opcache.
I think better approach would be to put type in front of first variable
declaration like:
[type] $variable = $value;
BR,
--
Michał Brzuchalski
t/rfc/object-initializer
I appreciate any feedback you all can provide.
Thanks,
--
Michał Brzuchalski
brzuc...@php.net
tax which would
not be restricted to stdClass only.
Although it's not a game-changer, simple addition to the language which
reduces boilerplate when dealing
with objects which don't need complex constructors like for eg. DTO objects.
Regards,
> Lynn van der Berg
>
>
Regards,
Michał Brzuchalski
n more strikes but that's
not the main reason about that RFC - nice to have but let's start with
something.
Regards,
Michał Brzuchalski
Hi Claude,
pt., 13 wrz 2019 o 08:39 Claude Pache napisał(a):
>
>
> Le 13 sept. 2019 à 07:49, Michał Brzuchalski
> a écrit :
>
> Hi Lynn,
>
> czw., 12 wrz 2019 o 17:01 Lynn napisał(a):
>
> Heya,
>
> What's the added benefit of this compared to implement
g `{ foo = 10 }` create an `stdClass` object (not
> in the RFC); While not used much since it has no effect, it's perfectly
> okay to put your code in brackets eg `{ { { $foo = 10; } } }`. As such, I
> don't think it's a good idea to allow `new stdClass` to be omitted.
>
Future scope mentions only about letting to create stdClass with omitting
of the class name only,
nothing said about removing a new keyword.
Thanks,
Michał Brzuchalski
reason about choosing "=" was a simplification of instantiation and
properties initialisation
and we use "=" to assign property values now.
The "=>" is specific for array key pairs and IMO should stay specific for
arrays only.
Thanks,
Michał Brzuchalski
eanings: { foo = 10 }
>
>
>
{ $foo = 123 }; // unexpected "}" cause of missing ";"
$bar = { $foo = 123 }; // unexpected "{" cause it's not allowed in this
context
Both examples are syntax error.
You can use {} for separating blocks of code, but now if you wanna assign
value.
Everything considered syntax error can be used for feature shaping.
Regards,
Michał Brzuchalski
country = "GB",
phoneNumber = PhoneNumber::fromString("+1555 010 020"),
birthDate = new DateTimeImmutable("1983-01-01"),
email = Email::fromString("john@example.com"),
};
}
Thanks in advance,
Michał Brzuchalski
tomatically called
> after __construct():
>
>
Thank for your feedback and ideas, but I decided not to include it in the
RFC.
Thanks in advance,
Michał Brzuchalski
Hi Paul,
niedz., 15 wrz 2019 o 15:48 Paul M. Jones napisał(a):
>
>
> > On Sep 12, 2019, at 09:00, Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
> >
> > Hi internals,
> >
> > I'd like to open discussion about RFC: Object Initial
Hi all,
czw., 12 wrz 2019 o 16:00 Michał Brzuchalski
napisał(a):
> Hi internals,
>
> I'd like to open discussion about RFC: Object Initializer.
>
> This proposal reduces boilerplate of object instantiation and properties
> initialization in case of classes without require
Hi Rowan,
pon., 16 wrz 2019 o 15:47 Rowan Tommins
napisał(a):
> On Mon, 16 Sep 2019 at 08:29, Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
> > Please keep in mind that initializing properties through object
> initializer
> > applies to visible
ut being redundant.
>
Sorry for that, the quoted sentence was left unintentionally and yes, it's
not off-topic.
Had to rethink what I was trying to say, but I do think both these features
could exist.
Regards,
Michał Brzuchalski
this from class
inner scope exactly the same way as you're able to access them from class
inner scope now.
This feature may not be a cure for all diseases, but I believe is the right
to reduce noise and boilerplate when instantiating and initializing simple
objects with type restrictions and ensures valid object state every time
it's used.
BR,
Michał Brzuchalski
Hi all,
the discussion period was long and discussion I think quite comprehensive.
I'd like to open the RFC up for a voting today at 11:00 UTC. The voting
will take from 11:00 UTC 7th till 11:00 UTC 21st of October 2019.
BR,
Michał Brzuchalski
czw., 12 wrz 2019 o 16:00 Michał Brzuch
Hi all,
the discussion period was long and discussion I think quite comprehensive.
The RFC is at https://wiki.php.net/rfc/object-initializer and is up for
voting now.
The voting will take 2 weeks from 11:00 UTC 7th till 11:00 UTC 21st of
October 2019.
BR,
Michał Brzuchalski
Hi all,
A follow-up note.
There is no implementation of a patch yet.
BR,
Michał Brzuchalski
pon., 7 paź 2019 o 13:00 Michał Brzuchalski
napisał(a):
> Hi all,
>
> the discussion period was long and discussion I think quite comprehensive.
>
> The RFC is at https://wiki.php
; anything reflection-ish based.
>
Thank you for your feedback.
Cheers,
Michał Brzuchalski
witch-expression-and-statement-improvement
Cheers,
Michał Brzuchalski
śr., 16 paź 2019, 03:46 użytkownik David Rodrigues
napisał:
> Hello. I like to suggests a discussion about a FR to make possible to
> inline switch, as an alternative to nested inline conditionals.
>
> $val
my proposal with commas, see here:
https://wiki.php.net/rfc/switch-expression-and-statement-improvement#switch_expression_introduction
Unfortunately, this RFC needs more work cause it mixes switch statement
enhancement with comma-separated list syntax and of switch statement - I
need to split it into two RFC's
This is nice hearing that this idea has an interest.
As soon as the RFC will be split and finished I can start a discussion
thread.
Cheers,
Michał Brzuchalski
Cheers,
Michał Brzuchalski
pon., 7 paź 2019 o 13:00 Michał Brzuchalski
napisał(a):
> Hi all,
>
> the discussion period was long and discussion I think quite comprehensive.
>
> The RFC is at https://wiki.php.net/rfc/object-initializer and is up for
> voting now.
> The voting
hat accepts is countable (look at generators).
speaking of arrayable probably you're thinking of counting it too, but then
it would require to behave like an intersection of types
arrayable = iterable&countable - going further it would not accept
generators anymore - concluding people would still use iterable
and not arrayable for traversing using foreach etc.
Just my 50cents.
Cheers,
Michał Brzuchalski
Fatal error: Uncaught
Error: Cannot unset string offset".
An expected result is to be the same but an effect radically different as
you can see [1].
IMHO allowing string offset to be unset using unset construct could be
allowed to ensure consistency then.
Any thoughts on this?
BR,
--
Michał Brzuchalski
[1] https://3v4l.org/0Ol3N
stead of ServerRequest instance properties and a single point to retrieve
header values just like
well known ParameterBag's from HttpFoundation to operate on get, post,
headers etc.
BR,
--
Michał Brzuchalski
t", "throw" etc.
> Potential alternatives would be Stringifyable (or Stringifiable?),
> StringCastable, StringConvertible...
> (Even though I personally have no problem with "Stringable")
>
>
Maybe StringObject? We do already have ArrayObject.
BR,
--
Michał Brzuchalski
allable(['Zoq',
> 'Fot']);
>
> to
>
>
> <$foo, Fot>
>
>
>
> E.g:
>
> array_map(, $array);
> array_map(, $array);
>
> Do you like ?
>
That reminds me an old draft RFC https://wiki.php.net/rfc/short-closures
where I thought curly braces can be used to create closure from syntax
nearly the same as invoking but without parentheses.
That way we can provide clear intent - I mean if whatever is around: curly
braces or $ with parentheses IMHO it should be consistent with call like
format. For example:
$(strlen) or {strlen} for Closure::fromCallable('foo')
$($foo->Fot) or {$foo->Fot} for Closure::fromCallable([$obj, 'Fot'])
$(Zoq::Fot) or {Zoq::Fot} for Closure::fromCallable('Zoq::Fot')
Etc. The same inside like a call but wrapped in something and with no
parentheses part.
Cheers,
--
Michał Brzuchalski
>
familiar alternatives should be
> explored as well. Thinking about the existing list() and array() syntax,
> another possibility could be:
>
> closure(foo);
> closure($obj->Fot);
> closure(Zoq::Fot);
>
It looks like a function but it's not a function cause what you have inside
parentheses looks like a const, property and class const.
IMO a statement like that for consistency it should be with no parentheses
like:
$foo = closure foo;
$foo = closure $obj->Fot;
$foo = closure Zoq::Fot;
Cheers,
--
Michał Brzuchalski
>
wt., 11 lut 2020, 21:14 użytkownik Dik Takken
napisał:
> On 11-02-2020 20:01, Michał Brzuchalski wrote:
> > wt., 11 lut 2020, 18:42 użytkownik Manuel Canga
> > napisał:
> >
> > That reminds me an old draft RFC https://wiki.php.net/rfc/short-closures
> > where I
27;t we go with Token class name alone without the prefix?
The only one which includes PHP in class names so far are only:
* __PHP_Incomplete_Class
* php_user_filter
Above taken from https://www.php.net/manual/en/reserved.classes.php
BR,
Michał Brzuchalski
they do have a public __construct
so they look like classes but are not actually classes which you should be
allowed to instantiate wherever
you want, right? So we agree it looks a little weird here but dunno if
there's something we can do.
cheers,
Michał Brzuchalski
es and it looks like they could be also marked as
read-only in next major PHP version.
Cheers,
--
Michał Brzuchalski
śr., 18 mar 2020, 03:36 użytkownik Jakob Givoni napisał:
> Thank you, Michał, for chiming in :-)
>
> On Tue, Mar 17, 2020 at 10:52 AM Michał Brzuchalski
> wrote:
> > For object initializer, I was hoping to introduce a feature which with
> the benefits of typed properties
Hi Larry,
pon., 23 mar 2020, 01:48 użytkownik Larry Garfield
napisał:
> Hi folks.
>
> There have been a lot of RFCs and possible RFCs of late that are all
> circling around the same related problem space: Working with objects right
> now involves too much boilerplate to get things done. As I've
; > * Constructor Promotion
> > I would vote yes on this, assuming the implementation is sane.
>
> On Mon, Mar 23, 2020, at 12:55 AM, Michał Brzuchalski wrote:
>
> > That still doesn't resolve issue with lot of boilerplate when you deal
> with
> > small objects fo
();
>
> baz()
>
> },
>
> };
>
> ```
>
>
>
> This is indeed possible in PHP and could be implemented as part of the
> `switch` expression or as a general language feature. A nice side effect is
> that this could also be used in arrow functions:
>
>
>
> ```php
>
> $x = fn() => {
>
> foo();
>
> bar();
>
> baz()
>
> };
>
> ```
>
>
>
> This would, however, make it inconsistent with closures as they use the
> return keyword. Thus we would probably have to make sure arrow functions
> still work with return statement which would decrease the need for such a
> language construct. It is also very unlike anything else in PHP.
>
>
>
> # Poll
>
>
>
> This is a short overview of what I'll be working on in the coming weeks. I
> created a short poll for you guys to let me know if this idea is worth
> pursuing:
>
> https://forms.gle/stXMv72CAaDDxfwf8
>
>
>
> Stay safe!
>
>
That looks like what I've described a few months ago in
https://wiki.php.net/rfc/switch-expression-and-statement-improvement
If you dig into the mailing list you can even find almost ready to use
patch which implements it.
I'd love switch expression inclusion in PHP.
Cheers,
Michał Brzuchalski
always verbose and easy to read/decipher
this solution IMHO has more drawbacks regarding readability than benefits.
Cheers,
--
Michał Brzuchalski
onna download the php-src source code,
build environment and go with the ext/standard implementation and start
adding it in C.
The notice in this cases should either be different or not emitted at all.
If the latter then that has to be documented I guess.
Cheers,
--
Michał Brzuchalski
cribed at https://wiki.php.net/rfc/php-namespace-in-core
Best Regards,
Michał Brzuchalski
ge Peter Banyard and it's
> > purpose
> > is nothing more like to allow the use of PHP Namespace in the core.
> >
> > The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core
> >
> > Best Regards,
> > Michał Brzuchalski
>
> Hello,
Hi Derick,
śr., 15 kwi 2020 o 15:51 Derick Rethans napisał(a):
> On Wed, 15 Apr 2020, Michał Brzuchalski wrote:
>
> > Hi internals,
> >
> > I hope you're doing well.
> >
> > I'd like to announce the PHP Namespace in core RFC for discussion.
>
sible to write:
int $id = $data['id'];
int $id = getIdFromData($data);
And then expect the $id to behave more like typed property with type guard.
At least this is me what would expect from putting a type in from of
variable name
like in array destructuring example.
Why? Cause it has a type constraint in from of variable name just like
typed properties have.
Cheers,
Michał Brzuchalski
7;m just
> explaining that a different expectation exists, and why)
>
>
Agree this would slow things down but if it could be potentially type
checked on the assignment with type constraint in front of the variable
name I think that would be a neat feature.
So to work as a function parameter but not like a typed property.
Cheers,
Michał Brzuchalski
namespace in the core
for tightly coupled to the PHP engine types
which could be placed there without a risk to be unbundled in a future what
would cause a need to rename them back.
Therefore we think that these along with the arguments in the proposal are
the best ones to agree for now.
BR,
Michał Brzuchalski
Hi Benjamin,
pon., 20 kwi 2020 o 14:06 Benjamin Eberlei napisał(a):
> Hi Michał, George,
>
> On Wed, Apr 15, 2020 at 2:29 PM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
>> Hi internals,
>>
>> I hope you're doing well.
>>
>
a
good idea as a way to provide
callable types checking.
Any thoughts are highly appreciated!
Cheers,
Michał Brzuchalski
int for
callable/closure check
but actually this is not the case we're looking for. Things where mentioned
delegate
match perfectly is the places where your expectations to the
callable/closure type
are static and known at the time when writing code.
Given that in a situation when the input and the output types are known
this would bring the benefit of runtime check before use.
Cheers,
Michał Brzuchalski
PHP.
I've never used it and actually was asking myself why is it in the core.
I would vote for unbundling of it.
Cheers,
Michał Brzuchalski
always.
Voting will open Tomorrow on *May 22nd around 06:00 UTC*
and will remain open for 14 days until *4th of June.*
Cheers,
--
Michał Marcin Brzuchalski
/For the fame and glory of PHP!!/
śr., 15 kwi 2020 o 14:29 Michał Brzuchalski
napisał(a):
> Hi internals,
>
> I hope you'r
Hi Internals,
We have just opened the vote on the PHP namespace in core RFC. The voting
will be
open for two weeks, until 2020-06-05 06:00 UTC.
Link: https://wiki.php.net/rfc/php-namespace-in-core#vote
Cheers,
Michał Marcin Brzuchalski
pt., 22 maj 2020 o 08:14 Michał Brzuchalski
napisał(a):
> Hi Internals,
>
> We have just opened the vote on the PHP namespace in core RFC. The voting
> will be
> open for two weeks, until 2020-06-05 06:00 UTC.
>
Heads-up. We will end the vote soon.
If anyone may have not de
śr., 3 cze 2020 o 09:49 Michał Brzuchalski
napisał(a):
> pt., 22 maj 2020 o 08:14 Michał Brzuchalski
> napisał(a):
>
>> Hi Internals,
>>
>> We have just opened the vote on the PHP namespace in core RFC. The voting
>> will be
>> open for two weeks, until 20
wt., 9 cze 2020, 15:33 użytkownik Nikita Popov
napisał:
> On Tue, May 12, 2020 at 10:26 AM Nikita Popov
> wrote:
>
> > On Wed, Mar 11, 2020 at 10:50 AM Nikita Popov
> > wrote:
> >
> >> Hi internals,
> >>
> >> Userland classes that implement Traversable must do so either through
> >> Iterator or
wt., 9 cze 2020 o 13:56 Benjamin Eberlei napisał(a):
> On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown
> wrote:
>
> > Hi internals,
> >
> > I discussed the syntax for attributes further with Benjamin, Martin,
> > and several other internals developers off-list, and with their
> > feedback complete
Hi Mike,
wt., 16 cze 2020 o 08:59 Mike Schinkel napisał(a):
> Hi internals,
>
> Given that there appears to be some appetite to reduce checks for
> inappropriate signatures[1] I am wondering if anyone has strong opinions —
> pro or con — on removing checks for static methods?
>
> My primary use-
wt., 16 cze 2020 o 09:50 Nikita Popov napisał(a):
> On Tue, Jun 16, 2020 at 8:59 AM Mike Schinkel wrote:
>
> > Hi internals,
> >
> > Given that there appears to be some appetite to reduce checks for
> > inappropriate signatures[1] I am wondering if anyone has strong opinions
> —
> > pro or con —
Hi Internals,
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist
Discussions should remain on the list.
Any
I use and love because of refactor, code
styling, run&debug etc.
PHP language has poor type safety and IMHO without such patches it will
never evolve into type safety programming language.
Regards,
--
Michał Brzuchalski
2016-06-13 11:40 GMT+02:00 Joe Watkins :
> Morning,
>
> &
other mentioned.
Regards,
--
Michał Brzuchalski
2016-06-22 11:59 GMT+02:00 Lester Caine :
> On 22/06/16 10:37, Michał Brzuchalski wrote:
> > Without it, PHP will newer be aqualed such as Java, C# even Hack
> language -
> > there still will continue to be a big gap, due to the lac
another RFC's and another implementation.
Regards,
--
Michał Brzuchalski
2016-06-22 15:06 GMT+02:00 Marco Pivetta :
> Top-posting due to mobile conn.
>
> I voted no due to flaws introduced in the language by the current RFC.
>
> The performance impact is irrelevant.
> On Jun
--Larry Garfield
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I fully agree with Rasmus, I'm kind of developer complaining about the
missing PHP features.
At the same time often teach new progr
11 lip 2016 18:31 "Rasmus Schultz" napisał(a):
>
> > what's the actual added value of this sort of operator?
>
> The only direct value to the language is brevity - mere convenience.
>
> But I think the biggest indirectly added value, is that this will
> discourage people from the chainable methods
18 lip 2016 15:58 "Rowan Collins" napisał(a):
>
> On 18/07/2016 01:50, Stanislav Malyshev wrote:
>>
>> Hi!
>>
>>> How about an alternative approach where a function inside a namespace
>>> can be autoloaded using the existing callback, by using a reserved
>>> namespace segment? So to autoload funct
You are creating weird most of time unneded quite complex syntax. Just use
escaping functions or any other escaper or just simply template engine as
most of people does!
19 lip 2016 21:52 "Michael Vostrikov"
napisał(a):
> > This can be used for all context-dependent text transformations
> On the
20 lip 2016 19:03 "Michael Vostrikov"
napisał(a):
>
> > You are creating weird most of time unneded quite complex syntax. Just
> use escaping functions or any other escaper or just simply template engine
> as most of people does!
>
> I explained the reasons for implementing this operator in previo
Previously you wrote about PHP as a lang only. There was an RFC
https://wiki.php.net/rfc/script_only_include about dissallow opening tags
in require statements - personally I'd love to see it in PHP it could
minimize affect af featores like operator we're talking about to just
templates.
26 lip 20
ace, though.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
pozdrawiam
--
Michał Brzuchalski
zend_class->name and same for function pointers.
Nowadays probably none of extension uses namespaces so it's not a real
problem right now to provide such change.
Thanks for reading,
regards,
--
Michał Brzuchalski
lass midifier rather than proprty modifier
keyword.
regards,
--
Michał Brzuchalski
2016-08-08 12:31 GMT+02:00 Silvio Marijić :
> Hi,
>
> I would need your help with one idea. I'm working on one RFC that I'm would
> like to submit. Idea is that after you initialize object eg.
usion because of
>> final classes. I think "immutable" is more suited here.
>> What I try to achieve is something similar like case classes in Scala.
>>
>> Best regards,
>>
>> 2016-08-08 13:16 GMT+02:00 Michał Brzuchalski :
>>
>>> Hi Silvio,
&
2016-08-08 14:47 GMT+02:00 S.A.N :
> May be better to do as immutable arrays?
>
> const = new Email;
>
> it will be a super global immutable instance of Email.
>
I think you've missunderstood concept of immutable classes.
--
pozdrawiam
--
Michał Brzuchalski
led in CLI.
2016-08-08 15:00 GMT+02:00 Silvio Marijić :
> @Michal, well no I did read it. I see that there is not much going on
> there since last year. Did you tried to implement it ?
>
> 2016-08-08 14:49 GMT+02:00 Michał Brzuchalski :
>
>>
>> 2016-08-08 14:47 GMT+02:00
ooperating on implementing immutable and
> sealed modifiers?
>
> 2016-08-08 15:20 GMT+02:00 Michał Brzuchalski :
>
>> @Silvio I've tried to implement final https://github.com/php/p
>> hp-src/compare/master...brzuchal:final-properties but haven't found time
>> to impl
".
>
> On the other hand, saying "you can autoload functions from another
> namespace using qualified names or 'use function'" sidesteps the fallback
> issue, and sounds like a reasonable, non-BC-breaking, feature.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
pozdrawiam
--
Michał Brzuchalski
o see this one in action.
>> >
>> > I agree that we should separate them into separate RFC-s.
>> >
>> > 2016-08-08 15:51 GMT+02:00 Michał Brzuchalski :
>> >
>> >> It is great to hear somone is interested so why not. My lately
>> d
MSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
pozdrawiam
--
Michał Brzuchalski
It doesn't look like base64_*'s responsibility at all. Those global
functions should be just encoder and decoder and notbing yo do with
security!
10.08.2016 3:24 PM "Kalle Sommer Nielsen" napisał(a):
> On Aug 10, 2016 15:15, "Shafi Upwork" wrote:
> >
> > I was working Base64 Decode and Encode
>
1 - 100 of 189 matches
Mail list logo
