Re: [PHP-DEV] [RFC][Vote] Typed Properties

what and when what was called but if it works for you. :) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

= new DateTimeImmutable($row['marriage']); } if (isset($row['death'])) { $some_model->death = new DateTimeImmutable($row['death']); } $some_model->number_of_siblings = $row['number_of_siblings']; yield $some_model; } } } The Pers

Re: [PHP-DEV] [RFC][Vote] Typed Properties

essing it. PS: The UNSIGNED BIGINT thing is one of the reasons why I want intersection and union types so that we can do the following: class O { private int|string $id; } And leave it to a more intelligent system to determine whether this can be safely converted to an int or not (e.g. MySQLi)

Re: [PHP-DEV] [RFC][Vote] Typed Properties

programmers. We know it by now. ;) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/26/2016 11:40 PM, Rowan Collins wrote: > On 26/05/2016 21:00, Fleshgrinder wrote: >> PS: This needs a cast unless some special driver options are active. >> >>$me->numSiblings = (int) $db_record['num_siblings']; > > ...or unless strict_types=0, in which case

Re: [PHP-DEV] [RFC][Vote] Typed Properties

e it is possible does not mean that it is the proper way. Just make a new instance. ;) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

e->birth is guaranteed to be a \DateTime object > > Regards, > Nothing to add here. :) PS: This needs a cast unless some special driver options are active. $me->numSiblings = (int) $db_record['num_siblings']; -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

annot achieve? I cannot think of a single situation that is valid and not a developer error which would be impossible with the currently discussed approach. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

e just assertions and design by contract and you make a very good point here for an actual error. I am convinced. ;) However, it should not throw an error for isset() and empty() to allow more special constructs. As we already have it in place everywhere with the two. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/26/2016 7:00 PM, Tom Worster wrote: > On 5/26/16, 12:48 PM, "Fleshgrinder" <p...@fleshgrinder.com> wrote: >> This would be a valid approach too, yes. I personally would be against >> it because I do not want to initialize all my properties. >>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

property is not defined. I am of course open for ideas but emitting another kind of fatal error does not really make things better imho. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/26/2016 6:40 PM, Tom Worster wrote: > On 5/26/16, 12:30 PM, "Fleshgrinder" <p...@fleshgrinder.com> wrote: > >> The problem is a completely different one, how should the following code >> behave? >> >> class A { >> >>public

Re: [PHP-DEV] [RFC][Vote] Typed Properties

dge cases. Option 1. is extremely brutal and not necessarily what we want (lazy, anyone?). Option 2. has a huge problem with objects because it cannot initialize e.g. a \Fleshgrinder\Custom\SuperClass nor a \DateTime. Option 3. is the current behavior but silently doing so results in a type h

Re: [PHP-DEV] [RFC][Vote] Typed Properties

from. We need help here from people who know the PHP source better. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

erties RFC to continue. Unless I missed something in the discussion or got something wrong again. Please correct me! -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/26/2016 12:39 PM, Rowan Collins wrote: > On 26/05/2016 11:16, Fleshgrinder wrote: >> $o = (object) ['x' => null]; >> var_dump(isset($a->x)); // false >> var_dump(property_exists($a, 'x')); // true > > Apart from a typo in

Re: [PHP-DEV] [RFC][Vote] Typed Properties

ncorrectly. The behavior of isset() with array keys that were explicitly set to null never changed. ref: https://3v4l.org/TS621 However, this does not change my proposal. :) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Have a look at my latest message: http://marc.info/?l=php-internals=146424924029857=2 -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

$this->x = 42; } return $this->x; } } I could live with that. Note that the behavior of isset() and empty() was already once changed during the 5.4 feature release! I am proposing to change it with a major version for existing code and only emitting an E_STRICT till then. This is not even close as brutal as that behavioral change back then but other than that pretty much the same change. This time it just affects objects and not associative arrays. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

, unset, ...). In other words, null is a value and undefined/unset a state. Whether this proposal should become part of this RFC or not is something that needs to be discussed. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

/ 42 > unset($a->z); > var_dump($a->z); // 0 + notice > var_dump($a->u); // null + notice > var_dump($a->v); // null + notice > var_dump($a->w); // Fatal error, uninitialized... > This was proposed many times but it renders checks whether something was initialized or

Re: [PHP-DEV] [RFC][Vote] Typed Properties

bsolutely sure that this will cast confusion as you are. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

is_unset() - The following existing operations would need to be extended: - gettype() - settype() -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/25/2016 10:23 PM, Benoit Schildknecht wrote: > Le Wed, 25 May 2016 21:40:28 +0200, Fleshgrinder <p...@fleshgrinder.com> > a écrit: > >> and unset simply because the property is not >> explicitly assigned null by unset, it is being undefined. > > > Becaus

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/25/2016 9:13 PM, Niklas Keller wrote: > 2016-05-25 20:39 GMT+02:00 Fleshgrinder <p...@fleshgrinder.com>: > >> In my opinion it should simply vanish along with its definition. I mean, >> > > Usually, yes. But suddenly `private Type $foo` isn't reliable a

Re: [PHP-DEV] [RFC][Vote] Typed Properties

ter unset? Would it be - as it is now - that it > is as if the property was never defined, or would it be something else? > In my opinion it should simply vanish along with its definition. I mean, isn't that the definition of unset in general. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Simple Annotations

ge > ) { ... } > What is this good for? When is /ValidateRange/ being evaluated? On every call? How? I really do not get it, sorry. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Simple Annotations

flection to error out while you are performing introspection on a data structure. The annotation reader however will error out in the moment you try to access something. This separation of concern makes it actually easier and is in the vain of good software development too. I understand wha

Re: [PHP-DEV] [RFC] Simple Annotations

an with words. :-P https://gist.github.com/Fleshgrinder/d26cd4751827b8c10a0dc33da32b48c3 Reflection is the wrong tool for the job to build annotation systems. Reflection should not be used in production it should be used to introspect data structures and reason about them or other stuff during un

Re: [PHP-DEV] [RFC] Simple Annotations

of, well, PHP. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Simple Annotations

wever might result in fatal errors from meta-data: $reflector = new ReflectionClass(User::class); $reflector->getAnnotations(); // Fatal error: Uncaught Error: Class 'TableName' not found ... This is an absolute No-Go for meta-data. -- Richard "Fleshgrinder" Fussenegger sig

Re: [PHP-DEV] [RFC] Allow loading extensions by name

t. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Allow loading extensions by name

} } else { $path = $extension_dir . $name . '.so'; if (is_file($path)) { return do_load_extension($path); } } return do_load_extension($name); } Something along these lines should do it (of course in C). :) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

ng to be the end of the world, if we decided to live with > doc-comments only. > I hope it's going to be negative. The name is misleading and the AST approach is not really useful in userland. :( -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Allow loading extensions by name

On 5/10/2016 6:56 PM, Fleshgrinder wrote: > On 5/10/2016 6:54 PM, Stanislav Malyshev wrote: >> Hi! >> >>>> Please read and comment : >>>> >>>> https://wiki.php.net/rfc/load-ext-by-name >> >> The RFC says " it is currently impos

Re: [PHP-DEV] [RFC] Allow loading extensions by name

h environments" - but even with > extension fix, wouldn't it be still impossible since Windows are Unix > paths would probably be different? > Usage of slashes and relative paths works perfectly fine in Windows; or do you mean something different? -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

a very specific need of some parts of a website and not something that is universally required. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Allow loading extensions by name

On 5/10/2016 3:22 PM, François Laupretre wrote: > Please read and comment : > > https://wiki.php.net/rfc/load-ext-by-name > +1 and I am wondering why nobody else ever came to this idea. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Pipe Operator

public function build() { > $this->loadConfig(); > $this->buildApp(); > $this->buildRouter(); > +$this->buildDispatcher(); > $this->parseResponse(); > > return $this->response; > } > } > > Whoa that's significantly more changes, and therefore significantly more > chances to make a typo! > At least the complexity is not completely hidden behind some arbitrary procedural function call. You assume that the procedural function that you are introducing already exists and returns the correct thingy that continues the chain in exactly the order you want it too. Those are a lot of assumptions considering the fact that the pipe operator is meant for combining arbitrary libraries. Sorry, not convinced but a real world example might change that. ;) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

least offline. I do not see a single benefit in the current feature proposal. Especially since one can already run the content of a PhpDoc tag through the AST thingy and *bam* you have exactly the same thing. What we need is an annotation system that works for userland and not this attribute grammar c

Re: [PHP-DEV] [RFC] Pipe Operator

is not > the same). The point of this is to take a very common pattern (nesting many > procedural calls) and make it easier to read and manage later. > foreach (scandir($arg) as $path) { if ($path !== '.' && $path !== '..') { $ret[] = getFileArg($arg . DIRECTORY_SEPARATOR . $path); } } What can I say ... -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Pipe Operator

ret[] = getFileArg($arg . DIRECTORY_SEPARATOR . $path); } } Ocramius mentioned that the pipe operator would be super useful in async libraries and stuff but I am lacking real world examples here that illustrate how this new operator would make those experimental stuff benefit from it. Espec

Re: [PHP-DEV] [RFC] Pipe Operator

ething that cannot be already solved. It is always just about source code formatting and laziness to write out some variables. Sorry -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Pipe Operator

n't think > it solves the same problem space as pipe chaining. > The pipe operator is also just a work around for poorly designed libraries in this case and yields more poorly designed libraries. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Pipe Operator

ction(){}) > ->merge($someOtherArray); > It is indeed a much better approach. The more I read and think about the pipe operator the more I am against it. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Annotations VS Attributes

n live with that. Anyone can read our discussion and make up their mind on their own (and hopefully share it with us). [1] Unless of course---and I wrote that before---we extend the name of the new functionality to be more precise: - Attribute Grammar (what the current proposal effectively is) - Meta-Attributes - Custom Attributes - Annotation Attributes - Aspects [2] - ... [2] https://en.wiktionary.org/wiki/aspect > In aspect-oriented programming, a feature or component that can be > applied to parts of a program independent of any inheritance > hierarchy. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Pipe Operator

On 4/30/2016 5:51 PM, Fleshgrinder wrote: > $ret = scandir($arg) > |> array_filter($$, function($x) { return $x !== '.' && $x != '..'; }) > |> array_map(function ($x) use ($arg) { return $arg . '/' . $x; }, $$) > |> getFileArg($$) > |> array_mer

Re: [PHP-DEV] [RFC] Pipe Operator

> either: it is not "a different way of doing the same thing". > On Apr 30, 2016 17:05, "Fleshgrinder" <p...@fleshgrinder.com> wrote: > This is the example code from the RFC written in a normal procedural way. $files = scandir($arg); $files = array_filter($files, function ($x) {

Re: [PHP-DEV] [RFC] Pipe Operator

terface/ example very well). Unless you changed your mind regarding that. Hence, it is nice syntactic sugar but it does not allow us to solve problems that we cannot solve already. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Attributes

attributes and that userland is not going to collide with internal ones. Currently the RFC does not include any attributes but many examples that others might use to deduce a coding standard and later we add internal attributes and things go south. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: Fwd: [PHP-DEV] [RFC] PHP Attributes

r. I am not proposing the previously mentioned syntax as a real RFC yet, simply because I do not think that it is the right time to do so. However, I do believe that DbC does not belong into meta-attributes. My question remains: why DbC in meta? What could be any advantages? -- Richard "Fleshgrinder&quo

Re: [PHP-DEV] [RFC] PHP Annotations VS Attributes

ted it. > Allows use of the #[start] attribute, which changes the entry point > into a Rust program. This capability, especially the signature for > the annotated function, is subject to change. > > --- https://doc.rust-lang.org/reference.html The past and current RFCs are not proposing any attributes, they are proposing a system to annotate data with custom attributes. [1] http://dataannotationsextensions.org/ [2] https://www.it-visions.de/glossar/alle/454/MetaAttribut.aspx (German) [3] https://en.wikipedia.org/wiki/Attribute_grammar -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: Fwd: [PHP-DEV] [RFC] PHP Attributes

{} // Special scope "old" available... ensure { # error message $this->x = old::$x - 42; } } ensure { # created cannot be less than changed time $this->created <= $this->changed; } -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Annotations VS Attributes

Attributes", which look much > more like arbitrary metadata of the sort we are discussing right now: > http://rustbyexample.com/attribute.html > That is why there is an empty line between the pages that are actually documenting the usage of an annotation functionality and the

Re: [PHP-DEV] [RFC] PHP Annotations VS Attributes

outer layer to fail early. Validation of developers should happen via design by contract where we currently only have assert() at our disposal. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Annotations VS Attributes

//msdn.microsoft.com/en-us/library/aa664611%28v=vs.71%29.aspx > > Regards, No confirmation bias and as I said, Microsoft got it completely right. To give you an analogy, Microsoft is calling the egg an egg and the chicken a chicken. We would be calling a chicken an egg because it is able to

[PHP-DEV] [RFC] PHP Annotations VS Attributes

er English and computer science terminology! Last but not least, it also ensures that users find the correct PHP manual page when they search for this new feature that might make it into core at some point. :) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Request for Karma

the HowTo that one needs to send a request to internals list to ask for karma so somebody knows. I keep the request, I am sure it will be useful to step in and help on other occasions. :) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Attributes

On 4/25/2016 10:04 AM, Dmitry Stogov wrote: > > > On 04/24/2016 11:24 AM, Fleshgrinder wrote: >> The invariant could also be added as an additional branch to the class >> instead of a method, since it would not work like a method. >> >>class A {} invariant {}

[PHP-DEV] Request for Karma

account under the name "fleshgrinder". -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Attributes

On 4/25/2016 10:31 AM, Dmitry Stogov wrote: > > > On 04/23/2016 06:29 PM, Fleshgrinder wrote: >> +1 for the basic idea, however, I have various remarks. >> >> The RFC text is hard to read and contains many grammatical mistakes. How >> could one help you here? &g

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On 4/26/2016 9:40 PM, Levi Morrison wrote: > I think he meant to post a different case: > > function (Foo $foo = null, $concrete_param); > > This is based on a conversation I've had with him elsewhere. > Gosh, I know such code. That should result in an error! :P -- Ric

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

ent there! Deprecation of null as default value makes no sense, nor does it make sense to deprecate 42 as default value. ;) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

es as are used in the C source (e.g. AST_FUNC_DECL vs. AST_CLASS). The userland API could be more consistent here. You might disagree thought but in the end only the ordinal must be an absolute perfect match. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Attributes

nd it seems as it nobody sees it but your example illustrates it perfectly. @fopen('file', 'r'); function foo(){} @deprecated function foo(){} @throws InvalidArgumentException function foo(){} @route ['name' => 'foo'] function foo(){} Leaving out the brackets makes it very clear. I am in an ex

Re: [PHP-DEV] [RFC] PHP Attributes

hat explicit but it is what it is. > ROFL, that is actually totally true and I never thought about it. Damn silencing operator! :P However, i still think that the brackets are unnecessary and make it look like function calls. <> function f() {} -- Richard "Fleshgrinder" Fus

Re: [PHP-DEV] [RFC] PHP Attributes

On 4/24/2016 2:54 PM, Fleshgrinder wrote: > Another way to illustrate what I mean: > > The feature will be used /to annotate/ (add metadata) and the so > /annotated/ data has additional /attributes/ afterwards. > > Trying building the sentence if the feature is

Re: [PHP-DEV] [RFC] PHP Attributes

. Hence, in Ceylon no differentiation would be made between modifiers and annotations. However, one could check the actual annotation type to determine what it is. https://modules.ceylon-lang.org/repo/1/ceylon/language/1.2.2/module-doc/api/index.html#section-annotations -- Richard "Fleshgr

Re: [PHP-DEV] [RFC] PHP Attributes

xtension you mentioned works just fine without the brackets. @invariant CONDITION; class A { @ensure CONDITION; @require CONDITION; function f(){} } -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Attributes

te of the class? /Yes, behavioral/ Is *inattentive* an attribute of the child? /Yes/ ... So, what should `$r->getAttributes()` return? It is to broad, it is to generic, it is too often mixed up. `$r->getAnnotations()` is less ambiguous in the context of programming and thus a better choice. I hope

Re: [PHP-DEV] [RFC] PHP Attributes

On 4/24/2016 1:36 PM, Benjamin Eberlei wrote: > On Sun, Apr 24, 2016 at 10:24 AM, Fleshgrinder <p...@fleshgrinder.com> wrote: > >> The invariant could also be added as an additional branch to the class >> instead of a method, since it would not work like a method. >

Re: [PHP-DEV] [RFC] PHP Attributes

ng and the program will execute normally. TL;DR this feature *MUST* be called annotations (unless someone knows an even better term) and the annotations *MAY* be used to add attributes to properties but for many other things too. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Attributes

e, it should be thought about know. Simply because the brackets make sense if such a feature is to be implemented. ;) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Attributes

out >> parse errors. >> >> Regards >> Thomas >> > That is the nature of a feature release, you find many of those in any PHP feature release. Think of for instance `yield`, directly results in a parse error in older PHP versions. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Attributes

/* Uncaught PostconditionError: $this->balance === (old::$balance - $sum) */ ?> I actually think now that it would be better to go for this than for annotations. [1] http://blog.jetbrains.com/kotlin/2015/08/modifiers-vs-annotations/ [2] https://archive.eiffel.com/doc/online/eiffel50/intro/langua

Re: [PHP-DEV] [RFC] PHP Attributes

s directly in userland, e.g. with an `annotation function` and/or `annotation class`. However, this would require more thought. Another question that is unanswered for me is: how to go about adding annotations to a complete file as is currently possible with PhpDoc and its file-level doc block:

Re: [PHP-DEV] [RFC] Nullable Types

?T {} $x = fn(); if (is $x T) {} else {} Not doing as above is a compiler error in Ceylon. However, I already wrote multiple times that there are already statical code analysis tools available that can find exactly such things in your code. One just needs to use them. -- Richard "Flesh

Re: [PHP-DEV] [RFC] Nullable Types

runtime if something else is being returned. Honestly, null is not our problem. Every language has its null, just because they wrap it or rename it does not make null suddenly vanish from the universe. :P -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Nullable Types

ons/ ... /** * @return int|false */ function fn() {} function fn(): int|false {} ... are equivalent and the former does not suddenly return *false* on its own and hell it shouldn't. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

__toInt(): int; function __toString(): string; function __toArray(): array; function __toObject(): object; function __toResource(): resource; } Auto-conversion only if not ambiguous (`$o1 + $o2` where both have `__toInt()` and `__toFloat()` throws an ?Error but `(float)$o1 + (float)$o2` works so does `intdiv($o1, $o2)`), next is operator overloading. ;) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Quick sanity check ...

how important proper documentation is. Believe me, I know. You might say now that those programmers are bad, well, yes, maybe. But that is what you get when you are working in huge teams; ask Google. In the end it is about better APIs for me as I explained in many other messages and I stay true to that. :)

Re: [PHP-DEV] Quick sanity check ...

to me. Also, do not forget that the times and memory consumption you get from PHP might not reflect the real world. I would suggest to measure this with independent tools. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Quick sanity check ...

. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

creates the proper type based on the value. // Expressing this in userland is impossible ... :( } -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

ast makes it harder to implement cleanly. You need to consider that this RFC might be voted negative but it might come back in PHP 8 or PHP 9 where the landscape has changed so vastly that it might become a yes. Let's not introduce half backed features that nobody ever implemented and found useful

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

cial use cases but those are worth exploring imho. function div(int|float $x, int|float $y): int|float { if (is_float($x) || is_float($y)) { return $x / $y; } else { return intdiv($x, $y); } } function even(int|string $x): bool { if (is_int($x)) { return $x

Re: [PHP-DEV] Re: Improving PHP's type system

ither a HouseCat nor a Dog. This is dangerous and introduces many potential hard to find bugs. Better don't touch it and go for duck typing or the introduction of a dedicated interface: *always* -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time

gunslinger.tumblr.com/post/47131406821/php-is-meant-to-die https://software-gunslinger.tumblr.com/post/48215406921/php-is-meant-to-die-continued -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

t I say does >> not make it an insult. > > "It's Not What You Say, It's What People Hear" > > > But we are now completely off topic. To bring us back on topic I repeat > my request that you try to be specific about what you want and why, with > respect to the RFCs under discussion. > > Tom > > Very well said! :) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

t the implementer should take care of honoring. The intersection type hint is much stricter in such cases. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

On 4/19/2016 12:02 AM, Lester Caine wrote: > On 18/04/16 20:08, Fleshgrinder wrote: >> This is however a useful shortcut and shortcuts are good things in >> terms of usability if done write. Think of + vs. right click >>>> copy (or any other example of useful keybo

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

On 4/18/2016 7:22 AM, Marcio Almada wrote: > 2016-04-17 23:56 GMT-04:00 Larry Garfield : >> Rather than debate the relative merits of Null as a concept, since I think >> all agree removing Null from the language is not even a thing, what do you >> think of my recommendation

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

es that require more book keeping and by refusing to compile if they encounter a place where proper handling is missing. As I wrote earlier, we could introduce such a feature into the language. However, static code analyzers can already provide this functionality. People just need to use them.

Re: [PHP-DEV] RFC: Functional Interfaces

always be referred to as *callback*; imho. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

the only thing that allows us to create truly meaningful types. However, the problem of primitives remains, as was illustrated in this and related threads multiple types, e.g. `array|Traversable`. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

On 4/17/2016 2:57 PM, Lester Caine wrote: > On 17/04/16 13:35, Fleshgrinder wrote: >> If you are only afraid that usage of your libraries declines because >> users demand these new features to be part of it and you do not want to >> implement them. Sorry, but that

Re: [PHP-DEV] Re: Improving PHP's type system

On 4/17/2016 2:19 PM, Lester Caine wrote: > On 17/04/16 11:29, Fleshgrinder wrote: >> Especially since its not needed at all. HHVM already solved most of >> these issues extremely nicely: >> >> - https://docs.hhvm.com/hack/types/type-system >> - https://docs.hhvm.c

Re: [PHP-DEV] Re: Improving PHP's type system

; current namespace." and this makes "use" confusing. > Especially since its not needed at all. HHVM already solved most of these issues extremely nicely: - https://docs.hhvm.com/hack/types/type-system - https://docs.hhvm.com/hack/type-aliases/introduction - https://docs.hhvm.co

Re: [PHP-DEV] Re: Improving PHP's type system

e* get a grip. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

nguages handle this problem differently. PHP has `NULL` and we should keep it this way. To minimize bugs resulting from unchecked `NULL` usage a compiler feature could be implemented that warns a developer in such cases. We already have it for uncatched exceptions (although IDEs are currently not tellin

<    1   2   3   4   5   >