Re: [PHP-DEV] Re: Naming of 'weak' type hints
Zeev Suraski wrote: > One thing that I think we should change is how we refer to the ‘weak’ type > hints. The word ‘weak’ has a negative ring to it, and considering this is > how the language behaves across the board it’s a pretty bad name for this > feature. Borrowing from C#, I would suggest the names implicit and explicit argument types. There is nothing "weak" about them, they just do an implicit conversion which can be quite powerful if used correctly. In the future, I hope that we will have implicit object conversions in addition to the scalar ones. Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
2015-03-18 18:30 GMT+01:00 Chris Wright :
> On 18 March 2015 at 17:07, Lazare Inepologlou wrote:
>
>>
>> 2015-03-18 16:28 GMT+01:00 Chris Wright :
>>
>>> On 18 March 2015 at 13:12, Pavel Kouřil wrote:
>>>
>>> > On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov
>>> > wrote:
>>> > > On 18 Mar 2015 15:52, "Pavel Kouřil" wrote:
>>> > >>
>>> > >> Hello,
>>> > >>
>>> > >> I made that conclusion because in the first example, the library
>>> kinda
>>> > >> forces strict mode rules on the caller, even if he doesn't want to
>>> use
>>> > >> strict mode - this makes the interoperability of the two modes
>>> > >> problematic.
>>> > >
>>> > > This is incorrect, library force itself to use right types, not you.
>>> I
>>> > don't
>>> > > see any problems here. The only thing that for sure lacks in PHP and
>>> that
>>> > > would make STH better is callable signature types.
>>> > >
>>> >
>>> > Well, it forces you to do that, basically. And also forces you to
>>> > "care" about the mode of library, adding mental overhead. Look more
>>> > closesly at the first example - does the error in that case make sense
>>> > to you (from purely user's point of view)? When you call
>>> > a(function(int $b) {return $b * 2; }) - should you really be required
>>> > to check the context within the a() is declared?
>>> >
>>>
>>> You don't need to check the declaration context of a(). Either the
>>> library
>>> is definitely passing an integer and your code will work, or it isn't
>>> definitely passing an integer, maybe it's a float, so you shouldn't
>>> declare
>>> the parameter type at all - it isn't a typed parameter. This is simply a
>>> matter of RTFM in the library docs (and if there are no docs or the docs
>>> are wrong then you have to go read the library code anyway just as you
>>> would today, so you haven't lost anything).
>>>
>>> Type declarations are a way to more completely describe the interface
>>> contract, they are *not* a replacement/shorthand for casts. If the
>>> desired
>>> behaviour for your callback should be to accept anything and treat it as
>>> an
>>> integer for the computation, then your code should be written to describe
>>> that intent, i.e:
>>>
>>> a(function($b) {return ((int)$b) * 2; })
>>>
>>> This code both describes the behaviour of a() and the programmer's
>>> intended
>>> behaviour for the callback. Using a type declaration as a means to force
>>> a
>>> cast hides both of these - a reader would assume the callback is always
>>> called with an integer.
>>>
>>>
>> Yet, this code has a major flaw: the type of $b cannot be statically
>> inferred.
>>
>> No matter how "strict" the new mode is, it can only catch errors at
>> runtime. This is usually too late. Having the ability to find error at
>> design time is priceless. For me, this is the primary reason I am using
>> type hints.
>>
>>
> In the case where the caller may or may not be passing an int (i.e. the
> case where the original example would error because of strict mode in the
> lib), the type cannot be inferred through static analysis no matter what
> you do, at least not correctly, because it has no definite type. Since
> there is currently no "number" union type it is "mixed", which is the
> default "type" for any variable.
>
>
Let me be more clear. The type of $b cannot be statically inferred here:
a(function($b) {return ((int)$b) * 2; })
But it can be inferred here:
a(function(int $b) {return $b * 2; })
So I would always prefer to use the second form, especially if the closure
was more complex.
However, it seems that the second form is possible to fail, and that
depends on the mode (strict or not) of the library that contains the
function a. It does not depend on the mode that I have chosen to work with.
The two closures will not work in the same way and that's a kind of a WTF
moment.
Lazare INEPOLOGLOU
Ingénieur Logiciel
>
>>
>> Lazare INEPOLOGLOU
>> Ingénieur Logiciel
>>
>>
>>
>>
>>>
>>> >
>>> > >> Also, the other possible outcome of the scenario (respecting the
>>> mode
>>> > >> of the place where the callback is declared), is IMHO problematic as
>>> > >> well, because it does not respect the strict mode of the place where
>>> > >> it is called, making it inconsistent with how the dual mode RFC
>>> works
>>> > >> in general.
>>> > >
>>> > > It doesn't matter where the callback or function was declared, it
>>> only
>>> > > matters where it was called. It pretty much is consistent.
>>> >
>>> > This was just a comment about how it would be (also) wrong to solve it
>>> > the other way around.
>>> >
>>> > --
>>> > PHP Internals - PHP Runtime Development Mailing List
>>> > To unsubscribe, visit: http://www.php.net/unsub.php
>>> >
>>> >
>>>
>>
>>
>
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
2015-03-18 16:28 GMT+01:00 Chris Wright :
> On 18 March 2015 at 13:12, Pavel Kouřil wrote:
>
> > On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov
> > wrote:
> > > On 18 Mar 2015 15:52, "Pavel Kouřil" wrote:
> > >>
> > >> Hello,
> > >>
> > >> I made that conclusion because in the first example, the library kinda
> > >> forces strict mode rules on the caller, even if he doesn't want to use
> > >> strict mode - this makes the interoperability of the two modes
> > >> problematic.
> > >
> > > This is incorrect, library force itself to use right types, not you. I
> > don't
> > > see any problems here. The only thing that for sure lacks in PHP and
> that
> > > would make STH better is callable signature types.
> > >
> >
> > Well, it forces you to do that, basically. And also forces you to
> > "care" about the mode of library, adding mental overhead. Look more
> > closesly at the first example - does the error in that case make sense
> > to you (from purely user's point of view)? When you call
> > a(function(int $b) {return $b * 2; }) - should you really be required
> > to check the context within the a() is declared?
> >
>
> You don't need to check the declaration context of a(). Either the library
> is definitely passing an integer and your code will work, or it isn't
> definitely passing an integer, maybe it's a float, so you shouldn't declare
> the parameter type at all - it isn't a typed parameter. This is simply a
> matter of RTFM in the library docs (and if there are no docs or the docs
> are wrong then you have to go read the library code anyway just as you
> would today, so you haven't lost anything).
>
> Type declarations are a way to more completely describe the interface
> contract, they are *not* a replacement/shorthand for casts. If the desired
> behaviour for your callback should be to accept anything and treat it as an
> integer for the computation, then your code should be written to describe
> that intent, i.e:
>
> a(function($b) {return ((int)$b) * 2; })
>
> This code both describes the behaviour of a() and the programmer's intended
> behaviour for the callback. Using a type declaration as a means to force a
> cast hides both of these - a reader would assume the callback is always
> called with an integer.
>
>
Yet, this code has a major flaw: the type of $b cannot be statically
inferred.
No matter how "strict" the new mode is, it can only catch errors at
runtime. This is usually too late. Having the ability to find error at
design time is priceless. For me, this is the primary reason I am using
type hints.
Lazare INEPOLOGLOU
Ingénieur Logiciel
>
> >
> > >> Also, the other possible outcome of the scenario (respecting the mode
> > >> of the place where the callback is declared), is IMHO problematic as
> > >> well, because it does not respect the strict mode of the place where
> > >> it is called, making it inconsistent with how the dual mode RFC works
> > >> in general.
> > >
> > > It doesn't matter where the callback or function was declared, it only
> > > matters where it was called. It pretty much is consistent.
> >
> > This was just a comment about how it would be (also) wrong to solve it
> > the other way around.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
Re: [PHP-DEV] [RFC] Anonymous Classes
2015-03-07 8:22 GMT+01:00 Patrick Schaaf : > Am 06.03.2015 20:14 schrieb "Philip Sturgeon" : > > > > Right, this here RFC has been drastically improved. > > > > https://wiki.php.net/rfc/anonymous_classes > > > > Anyone got any doubts or troubles at this point? > > Can we / could we do "extends self", "extends static", or even "extends > $someclassname" ? > > +1 Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] Scalar Type Hints v0.4
2015-02-18 12:45 GMT+01:00 Rowan Collins : > Michael Wallner wrote on 18/02/2015 11:39: > >> On 18/02/15 12:31, Rowan Collins wrote: >> >>> Michael Wallner wrote on 18/02/2015 11:19: >>> >>>> On 17/02/15 23:03, Sara Golemon wrote: >>>> >>>> 1) Introduce scalar types for primitives: bool, int, float, string, >>>>> resource, object (we already have array) >>>>> 1a) Introduce meta-types as pre-defined unions (we can add custom >>>>> unions in a later rfc). A possible list may be as follows (again, we >>>>> can argue what's in this list separately): >>>>> * mixed: any type >>>>> * scalar: (null|bool|int|float|string) >>>>> >>>> Hold on, usually, type checking functions don't identify NULL as scalar. >>>> >>> No need for anyone to hold on; as it says in the section you've quoted >>> "we can argue what's in this list separately". Sara's after reactions to >>> the principle of having meta-types/unions in general, not their >>> definitions, right now. >>> >> Did you already incorporate "strict mode" yourself? >> SCNR >> >> I'm not a native speaker, so "hold on" might mean something different to >> you than to me. >> >> > Sorry, what I meant was, "don't worry, this isn't the kind of issue that > we need to worry about yet". > > Sara's e-mail made clear that these were quick examples, and she wasn't > expecting feedback on the details at this stage. > > Still, nullable types is something that had been proposed several times in this list, and fits nicely with the introduction of union-types. So, yes it would be nice null not to be included in scalars. Instead, we could have a union type like scalar? = scalar|null Lazare INEPOLOGLOU Ingénieur Logiciel > Regards, > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Abstract final classes
2014-11-27 4:47 GMT+01:00 guilhermebla...@gmail.com < guilhermebla...@gmail.com>: > Hi, > > I worked on an implementation of a somehow controversial concept that > exists in hack and C#: abstract final classes. > > https://wiki.php.net/rfc/abstract_final_class > > My motivation is to further expand class support to add modifiers (PPP - > public, protected, private). I added this change to initially segregate > grammar rules. It was an easy feature without extensive complexity and > covers some use-cases. > > "Abstract final" is a strange way to name it. What you want is a "static" class: * The fact that one cannot initialise an abstract class is only a side effect. Abstract classes are meant to be used for inheritance. * Abstract static methods are not possible (one more reason why abstract is a bad name). * A "static" class does not have to be final, given the fact that PHP is one of the few languages that offer a robust Late Static Binding. Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking
2014-11-25 23:42 GMT+01:00 Nikita Popov :
> On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz wrote:
>
> >
> > Am 25.11.2014 um 22:43 schrieb Levi Morrison:
> >
> > On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz
> wrote:
> >>
> >>> I think it's required to do the type check on runtime (Option 2)
> because
> >>> one of the use cases for return type-hint are factories and such often
> do
> >>> instantiation in base of unknown string values:
> >>>
> >>> class MyFactory {
> >>> public static function factory($name) : AdapterInterface {
> >>> $class = 'MyNamespace\Adapter\' . $name;
> >>> return $class();
> >>> }
> >>> }
> >>>
> >> It seems that I did not explain this clearly enough; I apologize. The
> >> variance has to do with the declared type in the function signature
> >> when inheritance is involved, not the type of the value returned by
> >> the function.
> >>
> >> For instance, under any of the three options this code will work just
> >> fine:
> >>
> >> class Foo {}
> >> class Goo extends Foo {}
> >>
> >> class FooFactory {
> >> function create(): Foo { return new Goo(); }
> >> }
> >>
> >> As long as the return value from FooFactory::create returns Foo or a
> >> subtype of Foo (such as Goo), then it will work.
> >>
> >> The variance that is under discussion in this thread is about the
> >> declared return type in the signature:
> >>
> >> class GooFactory extends FooFactory {
> >> function create(): Goo {}
> >> }
> >>
> >> In this case, GooFactory::create() declares a return type of Goo,
> >> which is a subtype of Foo [the return type of the inherited method
> >> FooFactory::create()]. This is a covariant return type.
> >>
> >> If we choose option 3, the only possible return type for
> >> GooFactory::create is Foo.
> >>
> >> Hopefully this clarifies the issue.
> >>
> > Yes it does - thank you for explanation - my mistake :/
> >
> > Option 3 is a no go not from OOP perspective and from consistency pov as
> > we already allow this in type-hint:
> >
> > class FooFactory {
> > function create(Foo $foo): Foo { return $foo; }
> > }
> >
> > class GooFactory extends FooFactory {
> > function create(Goo $goo): Goo { return $goo; }
> >
> > }
> >
>
> This is not correct. Parameter typehints in PHP are invariant, so you are
> not allowed to change them during inheritance. However LSP violations
> during inheritance of *non-abstract* methods currently uses a very low
> error level (E_STRICT), so you probably didn't notice. If you try the same
> thing with an interface method or an explicitly abstract method, you will
> receive a fatal error:
>
> interface I1 {
> function foo(A $a);
> }
> class C1 implements I1 {
> function foo(B $b) { ... }
> }
>
> This code snippet will result in a fatal error, because it violates type
> invariance.
>
>
Let's not compare these two:
* Parameter types are contravariant, otherwise they are not type sound.
Yet, contravariance in general is of little interest (I cannot think of any
practical example), so invariance is a good compromise.
* Return types are covariant. There are many useful examples already
mentioned in this mailing list.
http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#Covariant_method_return_type
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] [RFC] Using objects as keys
2014-10-27 16:54 GMT+01:00 Levi Morrison : > > I would like to present to your attention an RFC about using object as > keys: > > > > https://wiki.php.net/rfc/objkey > > A few points I have against this proposal, as I understand it: > > - It does not store the object, only the result of `__hash`. > Without the actual object this is not helpful for any use-case I have. > > - Using a method in the object prevents you from hashing on > different members of the objects for different uses. For example, > there is a User object. Most of the time the User::id will be used for > the hash. However, sometimes the hash needs to be on User::username. > If the hashing code is pushed inside the object and call it > automatically then you can't hash on the different values. > > In summary 1) the hashing function should be external to the object, > 2) should not be invoked magically, and 3) the object needs to be > stored. This can already be done in user-land; here is one such > example that I have created but there are others: > https://github.com/morrisonlevi/Ardent/blob/master/src/HashMap.php > > Although I don't care very much for the first two points, the third point is very alarming. Yes, we should have the option to get the objects used as keys, otherwise the new functionality does not offer much. Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] RFC: Anonymous Classes
2013/9/26 Joe Watkins > On 09/26/2013 01:50 AM, Pierre Joye wrote: > >> hi! >> >> On Sun, Sep 22, 2013 at 11:39 PM, Joe Watkins wrote: >> >>> Morning All, >>> >>> https://wiki.php.net/rfc/**anonymous_classes<https://wiki.php.net/rfc/anonymous_classes> >>> >>> I'd like to hear thoughts regarding the addition of anonymous classes, >>> patch included. >>> >> >> Thanks for your proposal and work. >> >> If you did not yet update your RFC I would suggest to do so, it is about >> the right time. >> >> Adding already answered questions, more use cases (read a couple of good >> ones in this thread). It will help to end in circular discussions or >> arguing. >> >> Cheers, >> Pierre >> >> > Thanks ... > > I have made many changes to the RFC and patch since the beginning of this > discussion ... > > It might be useful if you could all now go back to the RFC for another > read, point out anything I've left unclear at this point. > > Thank you for the updates. There is a possible mistake in the "Inheritance" section. The $this->data array is passed by value to the constructor of the anonymous class. Once there is any change to the initial array, the two classes will contain different data. Which leads us to the point that this pattern is not enough to do what you wanted to without changing the original constructor. This is usually out of the question, as one such change will also change the outer class' behavior. We don't have to reinvent the wheel here. The solution is some kind of "use" clause that works similarly to the anonymous functions. Cheers, Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] RFC: Anonymous Classes
2013/9/24 David Soria Parra
> Lazare Inepologlou schrieb:
> > I use anonymous classes very frequently in Java and in C#, and I would
> say
> > that they are quite useful. However the examples given in the RFC are
> > really bad ones. Why on earth would you need a constructor for an
> anonymous
> > class? Anonymous classes are used to implement quickly some interface.
> > Frankly, constructors are not part of any interface. Besides a
> constructor
> > is totally useless in an anonymous class as it will never be called after
> > the object is created.
>
> The need for anonymous classes in Java mostly comes from implementing
> interfaces on demand due to the lack of lamdas and the requirements of
> a strongly typed language. PHP has lambdas and it doesn't require you
> to match typing. Therefore I think the preferred way for most of the
> use cases is to use a lambda or if a bigger implementation is necessary,
> to give it a name. Due to namespacing you don't pollute the global scope
> anyway. Therefore I don't see much reason left as to why add anonymous
> classes and I really have a hard time finding a use case, except for trying
> to write PHP as you would write Java (which most likely is a bad idea).
>
>
There are many use cases where anonymous classes are useful, even in the
presence of lambdas. I use them quite often when dealing with graphical
interfaces and templates. Here is an example:
abstract class MyFancyHtmlListView extends UI {
protected function IsHeaderVisible(){ return true; }
protected function GetListItemMenu(){ return null; }
protected function OnItemClick( $item ){ }
protected abstract function RenderListItem( $item );
public function Render(){
// echo ...
}
}
With anonymous classes we could do something like this:
The biggest advantage is that a missing RenderListItem could be statically
verified.
It is just a pattern that follows a different way of thinking: Instead of
having a list of parameters (including lambdas), we have standard methods
that take advantage of all the nice properties of OOP such as abstraction,
inheritance and polymorphism.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] RFC: Anonymous Classes
2013/9/23 Derick Rethans > On Mon, 23 Sep 2013, Joe Watkins wrote: > > > https://wiki.php.net/rfc/anonymous_classes > > This RFC misses one very important part: an argument for why this > feature is useful. Syntax changes are likely to be extremely contentious > and without convincingreasoning *why* we need this, we shouldn't even > consider looking at an RFC. > > I use anonymous classes very frequently in Java and in C#, and I would say that they are quite useful. However the examples given in the RFC are really bad ones. Why on earth would you need a constructor for an anonymous class? Anonymous classes are used to implement quickly some interface. Frankly, constructors are not part of any interface. Besides a constructor is totally useless in an anonymous class as it will never be called after the object is created. Let's not rule out this feature yet. It's just a weak RFC, so let's wait for better approaches. Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] PROPOSAL: new class entry for grouping functions, consts and vars
2013/9/20 kuzuha > Hi, I wrote a *rough* patch to add new class entry "definition" for > > grouping functions, consts and vars. > > > > https://github.com/kuzuha/php-src/compare/feature;definition > > > > As you know, defining a lot of constants makes php slower. > > I think autoload is very nice solution to avoid that problem. > > Autoloading skips unnecessary code and makes php faster. > > > > The "definition" block means Grouped defines. That gives autoloading > > to function, consts and vars. And PSR-0 helps simplify directory tree. > > This is nothing else than a "static class" of C#, which does nothing but enforcing self-discipline. We can already do all these stuff with a standard PHP class. Besides, a standard PHP class offers Late Static Binding, which gives a very nice mechanism to expand a library. How does your "definition" block provide anything similar? Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] Support for keywords where possible
2013/9/11 Bob Weinand
> Hi!
>
> I tried to widen the naming possibilities by allowing to use keywords as
> identifiers (for function names, class names, label (goto) names, ...)
> where possible. It doesn't break any BC.
>
> Furthermore when BC needs to be broken in future for new keywords, it will
> have a smaller impact as most usages of the new keyword then still work.
>
> It also prevents unnecessary workarounds like in
> https://wiki.php.net/rfc/named_params#syntax. There, to address a
> function with a parameter called $array, we could simply write func(array
> => $value); instead of the until now necessary func("array" => value);
>
> You can find the patch here:
> https://github.com/php/php-src/pull/438
>
> Any thoughts about this?
>
>
>
I like it! I always hated the fact that "list" is a reserved word.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] [RFC] Named parameters
2013/9/6 Adam Harvey
>
>
> Variadics/splat: collecting both named and positional arguments into
> one array seems reasonable to me. I think the main use case there
> would be option parameters, which you'd have to validate anyway, so
> positional parameters would be dealt with at that point — I don't see
> separate arrays as conferring any great advantage in terms of
> validating parameters, and it's no simpler conceptually.
>
>
There is a small drawback. Suppose this code:
function foo( $bar = 0 , ...$args ){}
foo( bart => 3 ); // misspelled name
According to the RFC, any unknown argument name will fall into the $args
array, making the above code valid. As this cannot be verified statically,
it is a possible source of bugs.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] [RFC] Skipping parameters take 2
2013/9/2 jbo...@openmv.com
> On Mon Sep 2 08:52 AM, Sebastian Krebs wrote:
> > 2013/9/2 Pierre Joye
> >
> > > >
> > > > Any comments or feedback on the RFCs and the code are welcome,
> > > > especially pointing out the cases where it may not work (which means
> > > > we need more phpt's there :)
> > >
> > > Using default instead of ,,, is indeed much more readable.
> > >
> > > However I still wonder what prevents to finally implement named
> > > parameters too, it will provide the same feature while being even more
> > > handy and easier.
> >
> >
> > And it covers an additional use-case: Self-explaning parameters like in
> > "foo(is_strict = false)" instead of "foo(null, null, false)".
> >
> >
>
> Lots of overlap between variadic functions, this proposal & named
> parameters.
>
>
I don't think that variadic functions prevent any of the other two, or that
they are used for the same cases.
> interface foo {
> function formatUseCases(...$options);
> }
> - Advantage: No dependency on a class / object
> - Disadvantage: doesn't document what options are available, no default
> parameters
>
This is totally not a use case for variadic functions. The arguments of a
variadic function are indexed, not named. In addition, they have the same
type (or at least they are treated the same way).
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] [RFC] Argument unpacking
2013/8/31 Bob Weinand
> Hi!
>
> Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou :
>
> > 2013/8/30 Stas Malyshev
> >
> >>> don't see a reason why one should explicitly disallow doing multiple
> >>> unpacks.
> >>
> >> Because it makes very hard to understand what's going on and makes no
> >> sense semantically.
> >>
> >>> As you can see, here two arguments are unpacked in one call.
> >>
> >> This is very special use case to be hidden in library functions, I don't
> >> think we need to have language syntax specially directed at that, at the
> >> cost of making it overall more complex and hard to understand. I can see
> >> what "add all those params at the end" syntax mean. However having
> >> something like ($a, ...$b, $c, ...$d, $e, $f, $g, ...$h) I have no idea
> >> what's going on at all and what is sent where.
> >>
> >>
> > I agree with Stas here. If an argument comes after an unpacked array, its
> > position is not certain until runtime. This makes life difficult for
> static
> > analysis tools, which is one of the reasons for introducing the new
> syntax.
>
> The alternative is for users to use what we have now: call_user_func_array
> with some array_merge, which makes it as difficult for static analysis as
> the
> new syntax does. This really is a non-argument.
>
>
Please read carefully my argument. The alternative is to actually call the
function normally with the arguments expanded in the code.
In other words, the alternative to this:
strpos( ...$array , 3 ); // which cannot be verified statically
is this:
strpos( $array[0] , $array[1] , 3 ); // which is perfectly verifiable.
The power of this proposal is found when used with optional arguments (or
variadic arguments) which always come last anyway.
Lazare INEPOLOGLOU
Ingénieur Logiciel
> And should we really restrict the user's code with some arbitrary limits?
> It just makes the user use some really ugly hacks nobody wants to see.
>
> > Even in the use case of Nikita, the two arguments to be unpacked come
> > without any standard arguments between or after them.
> >
> > I suggest that argument unpacking should be limited to the last arguments
> > only.
>
> An example where it really would make sense is:
>
> function long ($arg, $arg2, $arg3, $arg4, $arg5, $arg6, $arg7, $string) {
> // do something with your arguments
> }
>
> // just instead of copying the seven parameters; increases readability
> // and don't argue this would be badly statically analyzable - it is, but
> this isn't
> // the point. I want to show that people may find here some use case.
> function short (...$args) {
> if (count($args))
> return long(...$args, "some value");
> }
>
> > Lazare Inepologlou
> > Ingénieur Logiciel
> >
> >
> >
> > --
> >> Stanislav Malyshev, Software Architect
> >> SugarCRM: http://www.sugarcrm.com/
> >> (408)454-6900 ext. 227
>
> I finally am in favor of the proposal, because it allows removing a lot of
> ugly
> call_user_func_array calls which aren't really well readable. (and
> naturally
> because it allows passing the variadic parameters if that rfc will be
> accepted)
>
> And I think you are really arguing about non-issues.
> Example: Multiple uses of unpacking syntax makes sense when you call a
> function with a variadic parameter:
>
> function variadic (...$args) {
> // do something
> }
>
> variadic(...$array1, ...$array2);
>
>
> Bob Weinand
>
>
Re: [PHP-DEV] [RFC] Argument unpacking
2013/8/30 Stas Malyshev > > don't see a reason why one should explicitly disallow doing multiple > > unpacks. > > Because it makes very hard to understand what's going on and makes no > sense semantically. > > > As you can see, here two arguments are unpacked in one call. > > This is very special use case to be hidden in library functions, I don't > think we need to have language syntax specially directed at that, at the > cost of making it overall more complex and hard to understand. I can see > what "add all those params at the end" syntax mean. However having > something like ($a, ...$b, $c, ...$d, $e, $f, $g, ...$h) I have no idea > what's going on at all and what is sent where. > > I agree with Stas here. If an argument comes after an unpacked array, its position is not certain until runtime. This makes life difficult for static analysis tools, which is one of the reasons for introducing the new syntax. Even in the use case of Nikita, the two arguments to be unpacked come without any standard arguments between or after them. I suggest that argument unpacking should be limited to the last arguments only. Lazare Inepologlou Ingénieur Logiciel -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Argument unpacking
2013/8/30 Stas Malyshev > Hi! > > > This RFC proposes to add a syntax for argument unpacking: > > > > https://wiki.php.net/rfc/argument_unpacking > > > > Basically, this is the "complement" of the variadics RFC: It is not about > > declaring variadic functions, but about calling them. > > This is just another way of doing call_user_func, I'm not sure we really > need it. And something like: > test(1, 2, ...[3, 4], 5, 6, ...[7, 8]) > > looks plain weird. What would be the use case for doing something like > that? I don't think we should add this. > > Yes, this example is weird, because every argument is hardcoded anyway. I guess it has been added just for completeness. A good example would be function forwarding for variadic functions, without resorting to call_user_func_array. An even better example is that there would be no need to have both call_user_func and call_user_func_array in the first place: The former would be enough. The same applies to userland functions, and I have been many times in a situation where I had to define two different functions to cover both cases. Lazare INEPOLOGLOU Ingénieur Logiciel > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Argument unpacking
2013/8/30 Stas Malyshev > Hi! > > > A good example would be function forwarding for variadic functions, > > without resorting to call_user_func_array. > > What's wrong with "resorting to" call_user_func_array? > call_user_func_array is a PHP function and not some dark magic that one > should avoid using unless it is absolutely must. > > The disadvantages of call_user_func_array are very well described in the RFC. Lazare INEPOLOGLOU Ingénieur Logiciel > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 >
Re: [PHP-DEV] [RFC] Syntax for variadic functions
2013/8/28 Nikita Popov
> Hi internals!
>
> I'd like to propose an RFC, which adds dedicated syntax for variadic
> functions:
>
> https://wiki.php.net/rfc/variadics
>
> Basically this allows declaring variadics directly in the function
> signature, rather than fetching the arguments using func_get_args().
> Example:
>
> public function query($query, ...$params) { /* ... */ }
>
> What are your thoughts on this?
>
>
+1, primarily because it makes the code self-documented.
However, I would like to hilight one shortcoming of variadic functions
(both with the old and with the proposed syntax): There is no way to call a
variadic function unless all the arguments are hard-coded.
I am extenting the example of the RFC:
class MySQL implements DB {
public function query($query, ...$params) {
// ...
}
public function query_and_log($query, ...$params) {
// this will not work:
$result = $this->query( $query, $params );
log( $query );
return $result;
}
}
Not only this does not work, but there is no way to make it work without
modifying the original function. Would it be possible to extend the RFC
with new syntax that could cover cases like that as well? Maybe something
like that:
$result = $this->query( $query, ...$params );
Other than that, the RFC is very welcome.
Lazare INEPOLOGLOU
Ingénieur Logiciel
> Thanks,
> Nikita
>
Re: [PHP-DEV] Cannot call constructor
2013/5/30 Anthony Ferrara
> Richard et al,
>
>
> On Thu, May 23, 2013 at 5:24 PM, Richard Lynch wrote:
>
> > Consider this common scenario:
> >
> > I use some OOP library, that is a "black box" and I like it that way.
> >
> > As part of the integration, I need to extend one of the library's
> > classes:
> >
>
> The problem with this entire thread (I've been thinking about this for a
> while) is that it's setup from the very beginning with a failed assertion.
> You want to treat a library as a black box. Great! However, you also want
> to extend one of the library's classes. That's not ok. Because you cannot
> ever treat inheritance as a black box. It goes against just about every
> principle out there. And it's provably not possible to do.
>
>
I cannot agree with you here. This is exactly why the "protected" keyword
exists: to provide a black-box interface for class usage through
inheritance. Yes, this is not automatic and, yes it needs designing, but it
is certainly not against the principles. If it were, we should remove the
"protected" keyword as well.
> Treating it like a black box will cause LSP violations (which PHP is so
> keen on enforcing). Why? Because if you treat the parent as a black-box,
> you can't guarantee that the pre-conditions, post-conditions
> and invariants are not enforced (which LSP requires). So without looking at
> the parent, you can't have a child that adheres to LSP.
>
> But let's get less "rule" and more practical. Imagine the parent has no
> constructor. So you, in future hindsight, decide to do this:
>
> if (method_exists(get_parent_class(), '__construct')) {
> call_user_func_array(array(get_parent_class(), '__construct'),
> func_get_args());
> }
>
> Now, what happens if the parent constructor now takes a parameter by
> reference? The reference will be lost. The conceptual implementation is now
> gone. Not to mention that the parameters may (and will likely) be different
> from what you were expecting.
>
> So basically, we can't ever develop completely in a black box. So if the
> parent has a constructor, we need to call it (or not). But the point is,
> it's never a conditional in the code. It requires you to look at, and make
> a decision.
>
> So that brings us to the case when you override a class that doesn't have a
> constructor, which then gets one later on down the road. This is really
> just the same as before and boils down to: 1. Test your code, as a test
> should catch that. 2. Don't blindly update and expect code to work. 3. Even
> if you did have a conditional, you're likely to get the arguments wrong (or
> worse)...
>
> So realistically, while I can see the appeal to having the ability to
> always call parent::__construct(), I think it's actually a red-herring to
> the actual problem. And it's not really necessary in the first place. In
> fact, using it is likely to be a source of *more* bugs, as the object still
> won't be initialized properly (but you think it is)...
>
> My $0.02 at least,
>
> Anthony
>
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] property de-referencing
2013/5/2 Bernhard Schussek > 2013/5/1 Rasmus Schultz > > > > One could > > > write a PropertyReference class right now with literally the only > > > difference being the lack of a builtin operator (ie new > > > PropertyReference($obj, 'prop') versus ^$obj->prop): the fact that > > > nobody seems to have done this in a major framework I know of suggests > > > that there isn't a strong need for encapsulating the indirection > > > beyond the $obj->$prop syntax that's worked forever. > > > > > > > Look at the Symfony form-builder example - encapsulating the indirection > is > > *precisely* what they're doing: the object reference is stored in the > > form-builder, and property-names are added subsequently. > > > > As the developer of the Symfony Form component, I would like to clarify > that this is not true. At the time the property reference is stored, the > object it refers to is not (necessarily) known. You could build an abstract > form definition for "Author" instances, but only later instantiate a form > for that definition with a concrete object. So to be really useful in a > form context, property references need to be separated from object > instances (something like "^Author::$firstName" could work). > > Second, it is important that references can span multiple nodes in an > object/array graph. In Symfony, we built the PropertyAccess component for > that [1] which allows references like > > "authors[0].personalDetails[firstName]" > > which translates to > > ->getAuthors()[0]->getPersonalDetails()['firstName'] > > or > > ->authors[0]->getPersonalDetails()['firstName'] > > I have an idea regarding the syntax. The suggested ^ operator is troublesome, because it does not make clear that whatever follows will not be evaluated. This becomes even more confusing when dealing with multiple nodes, as the example above, where part of the expression has to be evaluated. Let's have something different: $obj~>property MyClass::~property This syntax can be easily applied to multiple nodes, without confusion: ->getAuthors()[0]->getPersonalDetails()~>firstName And it can be applied statically: Author::~firstName Lazare Inepologlou Ingénieur Logiciel
Re: [PHP-DEV] property de-referencing
Hello,
2013/5/1 Stas Malyshev
> Hi!
>
> > In C#, they had the intention to introduce the operator infoof(...) to
> > get the reflection, not only of properties, but of virtually everything
> > in the language. They abandoned the idea because it is really hard to do
> > that for overloaded functions and they did not want to do all that work
> > for a half baked feature:
> >
> >
> http://blogs.msdn.com/b/ericlippert/archive/2009/05/21/in-foof-we-trust-a-dialogue.aspx
> >
> > However, PHP does not have overloaded functions, which makes things
> > significantly easier, so maybe it is worth examining the idea.
>
> PHP has functions that can be result of __call or arbitrary code that
> implements fcall handler in an extension. What would be returned then?
> --
>
The result is the same with "new ReplectionMethod('foo','bar')". The added
value is that it can be statically checked.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] property de-referencing
2013/4/30 Rasmus Lerdorf > On 04/30/2013 01:58 PM, Stas Malyshev wrote: > > Hi! > > > >> I'm proposing we need a way to statically reference an object property - > >> the object property itself, not it's value: > > > > You probably have use case for that, and it should be pretty easy to > > write a class that does that, but why it should be in the language? It > > certainly doesn't look like something sizeable portion of PHP devs would > > do frequently. > > It is certainly not worth overloading the XOR operator for. > > -Rasmus > > In C#, they had the intention to introduce the operator infoof(...) to get the reflection, not only of properties, but of virtually everything in the language. They abandoned the idea because it is really hard to do that for overloaded functions and they did not want to do all that work for a half baked feature: http://blogs.msdn.com/b/ericlippert/archive/2009/05/21/in-foof-we-trust-a-dialogue.aspx However, PHP does not have overloaded functions, which makes things significantly easier, so maybe it is worth examining the idea. Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] Continued try blocks
2013/4/28 Julien Pauli > On Sat, Apr 27, 2013 at 3:56 PM, Amaury Bouchard > wrote: > > > 2013/4/27 Ferenc Kovacs > > > >> please don't reuse the continue keyword for it. > >> > >> There are a bunch of code out there where which uses exceptions in a > loop > >> context. > >> For example you have a retry counter decremented in a loop and you catch > >> the exceptions and retry until the retry limit is reached. > >> > > Fair enough. We can use "resume". > > > > "continue" is just a keyword (syntactic sugar) we sure can change, I like > "resume" yes :-) > > Julien.Pauli > Does this sound familiar to anyone? Sub Foo( Bar ) On Error GoTo ErrorHandler . . . Exit Sub ErrorHandler: . . . Resume Next End Sub :-) Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] Continued try blocks
2013/4/26 Julien Pauli
> Hello internals,
>
> I had an idea recently with a friend, about a feature try-catch blocks
> could use.
> Let me just write an example, you will quickly understand the idea :
>
> * *
> *
> *try {*
> * foo();*
> * bar();*
> * baz();*
> *} catch (SomeException $e) {*
> *dosomestuff();*
> *continue; /* Here is the feature, go back to try block */*
> *} catch (Exception $e) {*
> *dosomething();*
> *}*
>
>
This seems like a BC break:
for ( ; ; ) {
try {
...
} catch (Exception $e) {
continue;
}
}
With the proposed syntax, "continue" will no longer refer to the "for" loop.
>
>
> The continue keyword would resume the execution from where it had
> diverged, according to the function which led to the SomeException
> catch block.
>
> So, in this example, if, say, bar() throws a SomeException , the code
> would then resume and execute baz() after the catch block.
>
> Just presenting the idea here, no RFC actually , I'm collecting
> thoughts and notices.
>
> Julien.Pauli
>
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] [RFC] Class instances counter
2013/4/10 Frank Liepert
> Hello internals,
>
> again an update on the RFC, see https://wiki.php.net/rfc/instance_counter:
>
> - added support for object as argument
> - added support for array argument (indexed array with class names)
> - added more code examples
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
It is not entirely clear how the function treats subclasses. Does it count
only the *direct* instances of a class, or does it also count the instances
of subclasses?
class A {}
class B extends A {}
echo get_objects_count('A');
// 0
$a = new B;
echo $a instanceof A;
// 1 (true)
echo get_objects_count('A');
// ??? - 0 or 1 ?
Lazare Inepologlou
Ingénieur Logiciel
Re: [PHP-DEV] a couple of thoughts on the DateTime type debate
2013/4/4 Madara Uchiha
> OOP is not a beginner's concept. I don't want to sacrifice good coding
> practices for a better learning curve.
>
>
This is interesting. Best practices from other languages, including C#,
Scala etc, have shown that some things are better represented by value
types. Even in PHP, strings are value types, because it is better this
way...
Besides, having to think whether to use a value type or a reference type
does not make anything easier to learn! Value types is an advanced,
post-OOP concept, not targeted to beginners anyway.
> Also, a glance on the manual would reveal that the method returns the same
> instance for chaining (which is also debatable, why do we even do that?)
> On Apr 4, 2013 7:46 PM, "Rasmus Schultz" wrote:
>
> > Is it a really big feature if it's just syntactic sugar and internally
> > stored as an array? say:
> >
> > struct Color
> > {
> > public $r = 1.0;
> > public $g = 1.0;
> > public $b = 1.0;
> > }
> >
> > Stored internally this might be something like:
> >
> > array('__type'=>'Color', 'r'=>1.0, 'g'=>1.0, 'b'=>1.0)
> >
> > Have you worked extensively with DateTime or other value-as-object types?
> >
> > $today = new DateTime();
> > $yesterday = $today->modify('-1 day');
> >
> > echo "today: " . $today->format('Y-m-d') . "\n";
> > echo "yesterday: " . $yesterday->format('Y-m-d');
> >
> > Code like this is a major mind-boggle to most programmers - it's not by
> any
> > means obvious from reading this code that $yesterday and $today are in
> fact
> > references to the same object, and the output of this script is the same
> > date, twice.
> >
> > Most programmers automatically think of "atomic" things like date/time
> and
> > color as being values, and it's easy (even for experienced developers) to
> > make mistakes. In my own code, for example, constructors that take
> DateTime
> > instances as arguments usually have to safeguard by doing something like
> > this:
> >
> > public function __construct(DateTime $begin, DateTime $end)
> > {
> > $this->begin = clone $begin;
> > $this->end = clone $end;
> > }
> >
> > This makes redundant copies of objects in every instance, which isn't
> > optimal - but enables code like this to actually do what you expect:
> >
> > $date = new DateTime();
> > $week = array();
> > for ($i=0; $i<7; $i++) {
> > $week[] = new Day($date);
> > $date->add('P1D');
> > }
> >
> > if the Day constructor doesn't clone $date, you have problems - that's
> what
> > started the debate about a new DateTime type in the first place, I think?
> >
> > existing DateTime is fine, if what you want is a timestamp you can
> > manipulate for reasons *other* than using the resulting value, e.g. for
> > printing out successive dates - as soon as you want to do something other
> > than using the immediate value contained in the object, trouble's
> > a-brewin'.
> >
> > a new DateTime-type would solve that by having the add() and sub()
> methods
> > clone internally - but I can already do that by extending DateTime myself
> > (as countless frameworks and libraries have done) with all the same
> > problems in terms of API issues and expected behavior. (in cases where
> you
> > do expect the internal value to change.)
> >
> > as said, it only addresses the problem for DateTime, which is just one
> > isolated example of natural value-types represented as dysfunctional
> > objects.
> >
> > why not address the real issue, which is the lack of value-types?
> >
> > other languages have them for the same reasons.
> >
> > had we had value-types at the time, no one would have thought to
> implement
> > DateTime as an object...
> >
>
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] feature request : easy shared memory
Hello, 2013/3/14 rene7705 > great! :) > > this will do nicely. is there much overhead for storing and fetching these > variables? (ideally I would like to get a pointer) > > Unfortunately there is. Every object stored in APC has to be serialised first and then unserialised on retrieval. You can improve performance by using a binary serialiser (such as igBinary) instead of the default php one. > > On Thu, Mar 14, 2013 at 12:45 PM, Nikita Nefedov > wrote: > > > On Thu, 14 Mar 2013 07:05:03 -, rene7705 wrote: > > > > Hi. > >> > >> I'd like to build a replacement for SQL (yes, talk about an ambitious > >> project! ;), because the constant transferal of data in and out of SQL > >> from > >> Javascript (where everything might as well be object-oriented and > >> hierarchial) is a pain in the neck. > >> > >> But in order to do so, I'd very much like PHP (the server still controls > >> the data after all) to support shared memory efficiently. > >> > >> Something like > >> > >> sharedmem $bigNestedArray; // $bigNestedArray would be shared accross > the > >> entire server and all CPUs on it. > >> > >> as you now have > >> > >> global $bigNestedArray; > >> > >> would be ideal. > >> > >> I bet this would be useful for a host of other applications as well, and > >> fairly easy to implement. > >> > >> I'm an application programmer by trade, or I would hack this in myself. > >> > >> I'd much rather see the PHP development team develop this in properly. I > >> don't think it would require much time, as OS-level shared memory has > been > >> easy to implement since the 1990s. > >> > >> Please put this on the agenda, and get back to us in this thread as to > >> when > >> this will be available. > >> > > > > Hi, > > > > You can already do it using APC's apc_store() and apc_fetch() functions > > which let you use shared memory. But of course you should 'commit' every > > change of the fetched variable. > > > Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] Memory warning hook
2013/3/5 Tom Boutell > Can't you do this already? memory_limit can be fetched via ini_read, > and together with memory_get_usage you should be able to check for > this sort of thing. Admittedly having to parse memory_limit (which can > be in various units) is not perfect. > This is not the same at all. When are you going to run this code? Memory allocations happen all the time. What Nathan asked for is an event that is triggered when the memory consumption reaches a threshold. However, there is a different solution, which is better IMHO in the case of caches: weak references. A weak reference automatically frees the memory of the object, when the memory is needed. http://php.net/manual/en/book.weakref.php. Having said that, none of these solutions scale up to multiple servers. This is why shared cache systems like memcached are recommended. > On Tue, Mar 5, 2013 at 1:23 PM, wrote: > > As PHP applications are turning into large frameworks one of the issues > > arriving is memory management. One of the issues is that many frameworks > use > > sophisticated caching techniques to make accessing the same data quickly, > > this improves speed it is at the cost of memory. Often the developer > knows > > these areas that cache and often times already have functions in place to > > clear out the cache, however in the case where PHP is approaching or > exceeds > > memory limits PHP runs the GC then dies if it cannot allocate enough > memory. > > If we implemented "memory warning" triggers or user function that will be > > called before the GC is executed which allows the user to try and free up > > some memory on their own. This hopefully would give more flexibility to > > allowing these advanced caching techniques but at the same time allow the > > cache to be cleared out in case memory is getting low. > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Software Developer > > > > Nathan Bruer > > > > > > > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] I would like to write an RFC for the addition of an internal keyword
t; > }
> >
>
>
"internal public" is too much here, unless you want also to have "internal
protected" like C#. I have extensivelly used "internal" and "package" in C#
and Java, and I can tell you that "internal protected" is so rare that is
not worh it.
>
> This doesn't explain, why the "InternalClass" should be hidden? Additional
> the "new" in "doStuff()" and the cyclic calls let me believe, that you'll
> have a "tight coupling"-problem anyway.
>
> abstract class APIAbstract {
> protected function doInternalStuff() {
> return PublicAPIClass::internalStuffHelper();
> }
> protected static function internalStuffHelper();
> }
>
>
> >
> > namespace NotTheFramework;
> >
> > $instance = new \Framework\PublicAPIClass();
> > $instance->doStuff();
> >
> > // You would not be able to do the following things:
> > use Framework\InternalClass;
> >
> > $instance = new \Framework\InternalClass();
> >
> > \FrameWork\PublicAPIClass::internalStuffHelper();
> >
>
> And the question remains: Why _should_ I not be able to do this? If it is
> that specific to the "PublicAPIClass" maybe it should be an abstract parent
> instead? Or a trait?
> If it is _not_ that specific to "PublicAPIClass" ... well, ehm, this can't
> be, because it calls "internalStuffHelper()", thus it is bound to the class
> in any case. :)
>
>
> >
> > ?>
> >
> > Please read my example carefully, before simply writing it off.
> >
> > ...And a question: Am I wrong when I assume that this should be
> > "relatively" easy to implement?
> >
>
Relatively is the right word here. It might be easy for class members as
the mechanism already exists. However, for direct namespace members there
is no such concept. Can you make a proof-of-concept patch?
> > -Jens Riisom Schultz
> >
> >
> > On Feb 27, 2013, at 10:11 AM, Lazare Inepologlou
> > wrote:
> >
> > > Hello,
> > >
> > > 2013/2/27 Jens Riisom Schultz
> > > Hi,
> > >
> > > I just want to get a feel for whether the following idea would be
> > instantly rejected (for example I get the feeling that adding keywords
> is a
> > big deal):
> > >
> > > Often, when writing frameworks, you need to make public or protected
> > functionality or classes which should only be called from inside the
> > framework. You CAN ensure this with a lot of ninja tricks and
> > debug_backtrace, but it is very cumbersome and often hides your methods
> and
> > properties from class signatures.
> > >
> > > Therefore I would propose adding a C# style "internal" keyword. (
> > http://msdn.microsoft.com/en-us/library/7c5ka91b(v=vs.80).aspx )
> > >
> > > The idea is, simply, that functions, methods and classes marked as
> > "internal" would only be accessible from within the namespace in which
> they
> > are defined.
> > >
> > >
> > > The "internal" keyword in C# restricts access to the same *assembly*.
> An
> > assebly in .NET jargon is a .dll or a .exe, ie a package of code compiled
> > by the same developper at once. As packages in PHP do not exist, or exist
> > in some vague form (.phar, composer etc), I do not see how this keyword,
> > with its original meaning, could find a place here.
> > >
> > > Namespaces are not restricted to the same develloper and anyone can add
> > to them. Therefore, the meaning of the keyword would be totally different
> > from that of C#.
> > >
> > >
> > >
> > >
> > > For example the following class, "namespace Framework; internal class
> > Something {}", would only be visible from within the "Framework"
> namespace.
> > >
> > > I have a hunch that this would be relatively easy to implement.
> > >
> > > If noone objects I would attempt to create a patch and an RFC.
> > >
> > > What do you think?
> > >
> > >
> > > -Jens Riisom Schultz
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
> >
>
>
> --
> github.com/KingCrunch
>
Lazare Inepologlou
Ingénieur Logiciel
Re: [PHP-DEV] I would like to write an RFC for the addition of an internal keyword
Hello,
2013/2/27 Jens Riisom Schultz
> Hi,
>
> I just want to get a feel for whether the following idea would be
> instantly rejected (for example I get the feeling that adding keywords is a
> big deal):
>
> Often, when writing frameworks, you need to make public or protected
> functionality or classes which should only be called from inside the
> framework. You CAN ensure this with a lot of ninja tricks and
> debug_backtrace, but it is very cumbersome and often hides your methods and
> properties from class signatures.
>
> Therefore I would propose adding a C# style "internal" keyword. (
> http://msdn.microsoft.com/en-us/library/7c5ka91b(v=vs.80).aspx )
>
> The idea is, simply, that functions, methods and classes marked as
> "internal" would only be accessible from within the namespace in which they
> are defined.
>
>
The "internal" keyword in C# restricts access to the same *assembly*. An
assebly in .NET jargon is a .dll or a .exe, ie a package of code compiled
by the same developper at once. As packages in PHP do not exist, or exist
in some vague form (.phar, composer etc), I do not see how this keyword,
with its original meaning, could find a place here.
Namespaces are not restricted to the same develloper and anyone can add to
them. Therefore, the meaning of the keyword would be totally different from
that of C#.
> For example the following class, "namespace Framework; internal class
> Something {}", would only be visible from within the "Framework" namespace.
>
> I have a hunch that this would be relatively easy to implement.
>
> If noone objects I would attempt to create a patch and an RFC.
>
> What do you think?
>
>
> -Jens Riisom Schultz
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Allow (...)->foo() expressions not only for `new`
Hello Nikita,
2013/2/25 Nikita Popov
> Hi internals!
>
> PHP 5.4 added support for expressions of the kind (new Foo)->bar(), (new
> Foo)->bar and (new Foo)['bar'].
>
>
I guess it must have been discussed, but Is there any technical reason or
conflict that prevents us from having something like new Foo->bar(),
without the extra parenthesis?
> I'd like to extend this support to any expression instead of just new.
>
> Why should be do this? Because it's just an arbitrary restriction. Removing
> it would for example allow clone calls in the parens, so you could do
> something like (clone $date)->modify('...'). Which - you may have already
> noticed this - is more or less a replacement for the DateTimeImmutable
> class that was added for 5.5 (with the nice benefit of being fully
> compatible and not being an object oriented abomination :) That's just one
> example, but I think there are a lot more (especially if you also consider
> that it allows array dereferencing too). One further use that is of
> interest to me personally is for https://github.com/nikic/scalar_objects,
> so I can do calls like ("foo")->bar().
>
> A nice side benefit from this is that it removes a shift/reduce conflict
> from the parser.
>
> The patch for the change can be found here:
> https://github.com/php/php-src/pull/291/files. It's a very simple patch,
> it
> basically just changes one parser rule and adjusts the allowed opp types
> for some opcodes. The rest is just the vm regeneration for the new op
> types.
>
> I hope that this change is trivial enough to not require dragging it
> through the whole RFC process. If there are no objections I'd commit it
> sometime soon.
>
> Thoughts?
> Nikita
>
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
2013/2/21 Levi Morrison
> On Thu, Feb 21, 2013 at 4:17 AM, David Muir wrote:
> >
> > On 21/02/2013, at 6:12 AM, Lazare Inepologlou
> wrote:
> >
> >> 2013/2/20 Sanford Whiteman <
> swhitemanlistens-softw...@cypressintegrated.com>
> >>
> >>>> It still looks like some random characters bashed together by a monkey
> >>>> with a keyboard.
> >>>
> >>> +1, I am a fiend for ternary expressions and crazy one-liners, but
> >>> this makes me want to go back and unroll everything I've ever done
> >>> into readable code. :)
> >>>
> >>
> >> Long code is not always equivalent to readable code. A shorter syntax
> could
> >> improve readability in *some* cases.
> >>
> >> Long:
> >> $users->OrderBy( function( $x ){ return $x->Surname; } );
> >>
> >> Short:
> >> $users->OrderBy( $x ==> $x->Surname );
> >>
> >
> > I think your example proves the opposite. The fist example was much
> easier to read and understand than the second.
> >
>
> Obviously that's up to interpretation; I think the second is better
> though I don't understand why `==>` is there instead of something
> simpler.
>
It's just an example, and it's not important. I wanted to use something
that is similar to the key-value mapping operator, but not the same.
What is important is that the short version is declarative: emphasis is put
to what to do, not how to do it. The mechanics are not exposed, and this is
why some may find it harder to understand at first sight.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
2013/2/20 Sanford Whiteman
> > It still looks like some random characters bashed together by a monkey
> > with a keyboard.
>
> +1, I am a fiend for ternary expressions and crazy one-liners, but
> this makes me want to go back and unroll everything I've ever done
> into readable code. :)
>
> -- S.
>
Long code is not always equivalent to readable code. A shorter syntax could
improve readability in *some* cases.
Long:
$users->OrderBy( function( $x ){ return $x->Surname; } );
Short:
$users->OrderBy( $x ==> $x->Surname );
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] Voting periods
2013/1/28 Zeev Suraski > > -Original Message- > > From: Clint Priest [mailto:cpri...@zerocue.com] > > Sent: Monday, January 28, 2013 3:15 PM > > To: Peter Cowburn > > Cc: Zeev Suraski; Pierre Joye; PHP internals > > Subject: Re: [PHP-DEV] Voting periods > > > > > > On 1/28/2013 6:12 AM, Peter Cowburn wrote: > > > On 28 January 2013 12:03, Clint Priest wrote: > > >> If you're still worried about this making it in, don't worry. Nikita > > >> and I have given up, to the determinant of the community. > > >> > > > Then please close the voting. > > Since there is no "maximum voting period" and 5.5 is not in a feature > freeze yet, > > I left the voting open, in case some people decided to read the patch > and change > > their minds. I see no reason to close the vote unless I'm required to > do so or the > > game is up. > > I think there's an almost-consensus that voting periods need to be well > defined. Two reasons: > > 1. If you care enough about it you should be able to vote about it within > one or two weeks. > 2. Leaving it open ended gives the RFC proposer too much power. He could > simply end the vote once it happens to reach the necessary majority. > > So I'd say yes, you're required to end it, either immediately or at most > at the end of the two week boundary. > > > asking for this feature (present in every other modern > > language) for 5+ years. I spent two years going through the *tedious* > RFC > > discussion process, wrote the software, Nikita made it even better to > have it > > shot down without even reasonable explanations as to why "from most > people." > > There are two very reasonable explanations, and it's fine you may disagree > with them: > > 1. It makes the language more complex. > 2. It makes the language more difficult to maintain. > This is not accurate. There are people who would like to see a feature implemented, but voted no because they did not like the proposed implementation. This is important. A blunt "No" blocks not only the RFC itself but also all attempts for alternative or improved solutions. I believe that all proposals should have 3 options: "Yes, all the way", "Yes in principle, but not this implementation" and "No in principle". This would leave room for better approaches. > > In both cases, the people who opposed it thought that the gain from adding > it doesn't outweigh these loss in complexity and maintenance overhead. > > > Some are resting on the idea that the ROI isn't there just aren't > listening to the > > community. > > The vast majority of the PHP community is a silent one; These people > don't participate here on internals; They don't attend conferences; They > use it - the vast majority of them in a professional manner - and they > picked it because they like it the way it is, not because of what it needs > to become. For every person that subscribes to internals, there's a > thousand (yes, a THOUSAND) people who don't (it's several thousands vs.~5 > million). In fact, they're not completely silent. They speak in volumes > - PHP 5.4 is used in less than 1% of the sites using PHP today, and even > the relatively revolutionary 5.3 is still a lot less popular than 5.2. > The new shiny features are not all that interesting for most people. > > The community that participates in internals isn't necessarily > representative of the community at large. > > Zeev > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
Nikita,
2013/1/10 Nikita Popov
> On Tue, Jan 8, 2013 at 7:03 PM, Steve Clay wrote:
>
> > On 1/8/13 2:56 AM, Christian Stoller wrote:
> >
> >> But the way 'nullable' properties are defined is not very intuitive and
> >> unclean, in my opinion. Stas has already mentioned that.
> >> `public DateTime $date = NULL;` // this looks like the property is
> >> initialized with null, but it does not show that the property is
> 'nullable'
> >>
> >
> > Much agreed. After instantiation, these shouldn't behave differently:
> >
> > public $foo = null;
> > public Foo $foo = null;
> >
> > Sure, method signatures have special behavior based on a default value,
> > but IMO:
> > 1. those semantics aren't entirely intuitive to begin with
> > 2. property initializers aren't method sigs
> > 3. the semantics would apply only to some properties
> >
> >
> >
> > public DateTime? $date;
> >>
> >> In C# the question mark after a type is a short hand for a generic
> >> Nullable type.
> >>
> >
> > I like that it's an established practice of doing exactly what we're
> > trying to do.
> >
> > Could we not just make it obvious?:
> >
> > public Foo|null $foo;
> >
>
> I updated the RFC to include the current state regarding default value and
> nullability:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax
>
> One question that still needs to be discussed is what syntax regarding
> parentheses we want to use if this makes it. Currently both set { } and
> set($foo) { } style accessors are supported. Do we want to keep those two
> with the new syntax?
>
> Nikita
>
> PS: I hope I'm not interrupting all those heated annotations discussion too
> much ^^
>
In the RFC, one thing is not clear: How to provide typehints for nullable
properties that actually have accessors.
Will it be like this?
public DateTime $date = null {
get { ... }
set { ... }
}
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
2013/1/8 Lars Schultz
> Am 08.01.2013 10:03, schrieb Lazare Inepologlou:
>
>> The fact is that the existing syntax for nullable type hinting has its own
>> problems. For example, this is not possible:
>> function foo( Bar $bar = null , $mandatory ) { ... }
>>
>
> Sure it's possible;) I did not get a syntax error for that...I even use
> that case many times in my code exactly for that purpose, to allow $bar to
> be null but require $mandatory to be defined explicitly.
>
Seems you are right. Sorry.
>
> I would love to have the question mark syntax for both properties and
>> argument type hinting.
>>
>
> Introducing a BC-Break and/or yet another syntax? Is that worth it?
>
> This does not apply in all cases. Here is an example of a property that is
>> guaranteed not to be null:
>>
>> class Foo {
>>private $_date;
>>public DateTime $date {
>> get {
>>return is_null($date) ? new DateTime() : $this->date;
>> }
>> set {
>>$this->date = $value;
>> }
>>}
>> }
>>
>
> The property is still null;) Only the return value of the getter will not
> be null. But that's not the issue, is it? I am not arguing the case of NOT
> allowing null, Stas wanted to always allow null because of this reason and
> not have a special syntax to declare this.
>
>
>
No, the field $_date can be null. The property $date is not null, cannot be
set to null and cannot return null. Furthermore, it cannot be unset (should
fail with an error) and isset always returns true.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
> It takes up the syntax php has been using for method-definitions.
The fact is that the existing syntax for nullable type hinting has its own
problems. For example, this is not possible:
function foo( Bar $bar = null , $mandatory ) { ... }
I would love to have the question mark syntax for both properties and
argument type hinting.
> Although, as Stas has pointed out, *not* allowing NULL for a property
will not prevent it from being NULL...depending on wether it has been
initalized.
This does not apply in all cases. Here is an example of a property that is
guaranteed not to be null:
class Foo {
private $_date;
public DateTime $date {
get {
return is_null($date) ? new DateTime() : $this->date;
}
set {
$this->date = $value;
}
}
}
Lazare INEPOLOGLOU
Ingénieur Logiciel
2013/1/8 Lars Schultz
> Am 08.01.2013 08:56, schrieb Christian Stoller:
>
>> But the way 'nullable' properties are defined is not very intuitive and
>> unclean, in my opinion. Stas has already mentioned that.
>> `public DateTime $date = NULL;` // this looks like the property is
>> initialized with null, but it does not show that the property is 'nullable'
>>
>
> To me this makes perfect sense. It takes up the syntax php has been using
> for method-definitions. A syntax we would be using to create a classic
> setter method if there wasn't a fancy new one.
>
> public function setDate(DateTime $date = NULL) {
> $this->date = $date;
> }
>
> Anything other than this would result in an inconsistency. Having accepted
> that syntax previously and now introducing yet another one, would be
> confusing and unnecessary.
>
> Although, as Stas has pointed out, *not* allowing NULL for a property will
> not prevent it from being NULL...depending on wether it has been initalized.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] DateTime improvement
> Of course, I have no idea if anyone in userspace is using DateTimeImmutable... Well, it seems unlikely, unless he is Yoda or French. I mean, in English, it is common to put the adjective in front of the noun, isn't it? Lazare INEPOLOGLOU Ingénieur Logiciel 2012/12/20 Larry Garfield > I've seen DateTimeValue used elsewhere for userspace immutable date time > objects. Whether that indicates we SHOULD or SHOULD NOT use that for an > in-C version, I don't know. (I'm inclined to say should-but-namespace, but > I don't know if we're doing that yet.) > > Of course, I have no idea if anyone in userspace is using > DateTimeImmutable... > > --Larry Garfield > > On 12/17/12 2:52 PM, Lars Strojny wrote: > >> Hi Derick, >> >> I would go with DateTimeValue or DateTimeImmutable as well. >> >> Am 17.12.2012 um 19:42 schrieb Benjamin Eberlei : >> >> On Mon, Dec 17, 2012 at 5:48 PM, Derick Rethans wrote: >>> I went for DateTimePoint. Point as in "Point in time". I am not too >>> happy with the name, but I think it works better than DateTimeImmutable >>> as that just sounds quircky. I'm still fixing up a few things and adding >>> some test cases. I think I need to make it work with DatePeriod too - >>> but I haven't looked at that yet. >>> >>> some suggestions: >>> >>> DateTimeValue >>> DateTimeImmutable >>> DateImmutable >>> DateFixed >>> DateStatic >>> (and as a bonus: DateTime2) >>> >> >> >> > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Generators in PHP
Hello Ivan,
Moreover, I wonder how a “recursive yield” would act (something like
> “public function *f ( … ) { … yield $this->f(…); … }”). It is possible? Is
> it anticipated?
>
According to the RFC, your syntax will yield an entire generator and not
its intividual values. Please consider this example:
function * f() { ... }
function * g() {
yield f();
}
function * h() {
foreach( f() as $key => $value )
yield $key => value;
}
The pattern in function h() is quite common, and it is what you ask for. It
would be nice to have some syntactical sugar for it, maybe something like
that:
public function * h() {
yield foreach f();
}
Good work, I am looking forward to having generators in php.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/6/6 Ivan Enderlin @ Hoa
> On 05/06/12 19:35, Nikita Popov wrote:
>
>> Hi internals!
>>
> Hi Nikita,
>
> Before going any further I'd like to get some comments about what you
>> think of adding generator support to PHP.
>>
> I have always hoped to see the “yield” keywork introduced in PHP. I even
> suggested that in this mailing-list at least one time but I'm very glad to
> see some patches coming out.
>
> In addition to Gustavo's remarks, I wonder how the GC would collect a
> Generator object that is not use anymore (especially with a referenced
> yield). Does it fit to the current CG strategy or do we need an extra
> strategy? I would notice that the “Yield by reference” section does not
> exist but you have targeted it).
> Moreover, I wonder how a “recursive yield” would act (something like
> “public function *f ( … ) { … yield $this->f(…); … }”). It is possible? Is
> it anticipated?
>
> Thanks for you work.
>
> Cheers.
>
> --
> Ivan Enderlin
> Developer of Hoa
> http://hoa.42/ or http://hoa-project.net/
>
> PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
> http://disc.univ-fcomte.fr/ and http://www.inria.fr/
>
> Member of HTML and WebApps Working Group of W3C
> http://w3.org/
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
Hello Simon,
> in_array("123abc", array(3, 7, 123, 28)) === true
This is a pointless example, because the first argument of in_array is of
type "mixed" and not "int". So, this may cause many headaches, but it is
irrelevant to the discussion about scalar type hints.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/19 Simon Schick
> 2012/3/18 Adam Jon Richardson :
> > On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick
> > wrote:
> >
> >>
> >> Hi, All
> >>
> >> Just to add an example why I want a more strictly type-check here as
> >> we have in the current type-juggling:
> >>
> >>
> http://www.brandonsavage.net/an-xss-vulerability-in-the-making/?utm_source=rss&utm_medium=rss&utm_campaign=an-xss-vulerability-in-the-making
> >
> >
> > I see the example given as one of poor validation, not a reason for more
> > strict type checking in a dynamic, weakly typed language.
> >
> > One could:
> >
> > - use a regex
> > - setting the third argument (strict comparison) of in_array() to true
> -OR-
> > looping through the array and checking equivalence with ===
> > - ensure the type juggled value (the integer form) was returned and used
> > rather than using the original string
> >
> > I actually like the conversation on scalar type hinting, and I've even
> > offered some ideas for integrating a form of it, too. However, poor input
> > validation is not one of the reasons that I would use to justify its
> > inclusion. The goal of proper input validation should be to account for
> > page requests that include invalid data and provide appropriate feedback
> > within the natural flow of the application. Erring out when calling a
> more
> > strongly typed function at runtime does not provide this type of
> > application flow.
> >
> > Adam
>
> Hi, Adam
>
> I totally agree that type-hinting should not cover what the programmer
> should do for validating the given input ...
> But I just wanted to point out that this is something the author (and
> I) would never expect to happen ...
>
> in_array("123abc", array(3, 7, 123, 28)) === true
>
> But that's another thing :)
> I just wanted to point out that I don't want to have the string
> "123abc" accepted as an integer :)
>
> Anyways ... This thread should be a discussion about the whole
> concept, not the details.
> Sorry for getting off-context here.
>
> Bye
> Simon
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
Thank you for the confirmation.
What I am saying here is that, although this behavior was fine for objects,
it is not enough for scalars. One of the main arguments in favor of the
adoption of this syntax was that null was the only possible default value
for objects anyway. This obviously is not the case with for scalar types.
This is why I suggest a different syntax (which can also be used by object
types for consistency).
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/12 Anthony Ferrara
> Lazare,
>
> > The patch of Anthony, clearly states that this is accepted:
> >
> > function foo ( int $bar = null ) { }
> >
> > And this is what I called an int|null.
>
> Yup, it does. Because that's the current behavior with array and
> object casting. If you default it to null in the declaration, null is
> a valid value. If you don't, it's not...
>
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
Hello Arvids,
The patch of Anthony, clearly states that this is accepted:
function foo ( int $bar = null ) { }
And this is what I called an int|null.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/12 Arvids Godjuks
> 2012/3/12 Lazare Inepologlou
>
>> > I'm not sure about you, but I don't wanna see that kind of thing
>> eventually making it's way into the language
>>
>> Me neither. All I am saying is that, since int|null is already here from
>> the back door, I think it should be properly supported.
>>
>
> There is no int|null at the moment, and should not be. You can pass
> anything - object, array, string, bool, int, float resource, callable -
> they all are accepted and are checked in function body if it's writer wrote
> that code.
> Hint should provide a hint for a single type, or hint doesn't belong there.
>
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
> I'm not sure about you, but I don't wanna see that kind of thing eventually making it's way into the language Me neither. All I am saying is that, since int|null is already here from the back door, I think it should be properly supported. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/12 Arvids Godjuks > I think that the "null issue" is not an issue. Strictly speaking if you > want null or an int - leave out the type hint and use generic argument that > will accept anything. > I think it's over-engineering to try and push a special treatment for the > null. If function/method argument accepts anything but a single type - > it's type-less and does not need a type hint. > > Developers should not abuse type hints and adding a special case for > handling null will make many start to request things like this: > function foo(string|array $data) > function foo(bool|int $flag) > function foo(mixed $someVar) > etc. > > I'm not sure about you, but I don't wanna see that kind of thing > eventually making it's way into the language (believe me - even I > considered that at some point, but i'm more mature now and more settled in > my wishes :)) >
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
Hello Simon,
First of all, none of your examples cover the case I mentioned, and so, my
concerns are still valid.
Secondly, you make some wrong assumptions about how this specific POC
works. For example, you write:
> function foo(int $d = 20) { var_dump($d); }
> foo(null); // This should then also simply fail.
Unless I am wrong, the patch will convert null to 0.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/12 Simon Schick
> 2012/3/12 Lazare Inepologlou
> >
> > function set_check_box_state( bool state = false ) { ... }
> > set_check_box_state( null ); // null will be converted to false here...
> >
> > Therefore, this cannot work, unless the default value becomes null, which
> > is against the requirements. What I suggest is something like this:
> >
> > function set_check_box_state( bool? state = false ) { ... }
> > set_check_box_state( null ); // works fine
> >
> > In my opinion this is much clearer, as it separates the notions of the
> > type
> > and that of the default value.
> >
> >
> > Lazare INEPOLOGLOU
> > Ingénieur Logiciel
>
> Hi Lazare,
>
> I'd like to keep the accptance of null as it is for classes and arrays.
> Here's an example I wrote earlier:
>
> function foo(array $d = array()) { var_dump($d); }
> foo(null); // This fails with the message: Argument 1 passed to foo()
> must be an array, null given
>
> As this code fails I'd not expect to change this behavior for the new
> feature we're discussing here.
>
> function foo(int $d = 20) { var_dump($d); }
> foo(null); // This should then also simply fail. Don't care about
> what's the default-value or defined type.
>
> function foo(int $d = null) { var_dump($d); }
> foo(null); // And this should pass it through, providing the
> NULL-value in the function.
>
> function foo(int $d = 20) { var_dump($d); }
> foo( (int)null ); // This can provide 0 as the programmer forcing it
> to be an integer before putting it into this function-call.
>
> I would personally not like to give the user the option to set a
> null-value if it's not the default.
> But .. I don't wanna screw up your idea.
>
> Bye
> Simon
>
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
Hello Anthony,
I will raise once again the question about accepting null. According to
your POC, null is an acceptable value if it is also declared as a default
value. This is problematic for the scalar types, because they can very well
have a different default value.
An example: There is a check box with three states (check, unchecked and
mixed). This is usually translated to a three state boolean (true, false
and null). The default value of the check box is false.
function set_check_box_state( bool state = false ) { ... }
set_check_box_state( null ); // null will be converted to false here...
Therefore, this cannot work, unless the default value becomes null, which
is against the requirements. What I suggest is something like this:
function set_check_box_state( bool? state = false ) { ... }
set_check_box_state( null ); // works fine
In my opinion this is much clearer, as it separates the notions of the type
and that of the default value.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
> what if we added extra out and inout hints for references?
With the danger of becoming boring, I have to say that C# also support
"ref" and "out" arguments... Are we reinventing the wheel here?
To be honest, this is going too far. Can we have the basics first? Passing
by reference is a corner case, at least for PHP.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/9 John Crenshaw
> From: Simon Schick [mailto:simonsimc...@googlemail.com]
> >
> > 2012/3/9 Lazare Inepologlou
> > >
> > > Type casting combined with passing by reference is problematic in many
> ways. Just an example:
> > >
> > > fuction foo( string & $buffer) { ... } foo( $my_buffer );
> > >
> > > Here, $my_buffer has just been declared, so it is null. Should this be
> an error? I don't know! So, I think that that passing by reference should
> not be (immediately) supported.
> > >
> >
> > Hi, Lazare
> >
> > This should at least throw an E_NOTICE :) And also an error as NULL is
> not allowed here.
> >
> > Let me modify your example:
> >
> > fuction foo( string & $buffer = NULL) { ... } foo( $my_buffer );
> >
> > This would only raise the E_NOTICE because the variable has not been
> declared.
> > Or would you say that NULL is equal with an empty string (talking about
> implicit casting)? I would not like that, but if, don't let it be (int)0 or
> (bool)false as well.
> >
> > Bye
> > Simon
>
> The reason you have to validate the input type in this case is because
> even though it is a reference, we don't ACTALLY know that it isn't supposed
> to contain an input (even though that would be against all sane rules most
> of the time).
>
> I'm not attached to this idea at all, but I thought I'd throw it out and
> see if anyone can think of a problem with it; what if we added extra out
> and inout hints for references?
>
> // So this would give no error at all. Parameter is anticipated to be for
> output. Just silently change the type and don't warn on anything.
> fuction foo( out string & $buffer) { ... } foo( $my_buffer );
>
> // This WOULD give an error, because the parameter is also an input
> parameter:
> fuction foo( inout string & $buffer = NULL) { ... } foo( $my_buffer );
>
> // In any case no errors on these:
> fuction foo( inout string & $buffer = NULL) { ... } foo(
> (string)$my_buffer );
> fuction foo( string & $buffer = NULL) { ... } foo( (string)$my_buffer );
>
> If we assumed that all references were out unless stated otherwise we
> could avoid reserving an "out" keyword, and only add "inout", which is
> unlikely to conflict with stuff.
>
> Like I said, no attachment to this at all. My gut tells me I may have
> missed something really stupid here. Just brainstorming.
>
> John Crenshaw
> Priacta, Inc.
>
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
> What the current idea would be is an implicit casting (as I understood it
right).
Yes, exactly.
> This won't make it easy passing a variable as reference.
Type casting combined with passing by reference is problematic in many
ways. Just an example:
fuction foo( string & $buffer) { ... }
foo( $my_buffer );
Here, $my_buffer has just been declared, so it is null. Should this be an
error? I don't know! So, I think that that passing by reference should not
be (immediately) supported.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/9 Simon Schick
> 2012/3/9 Lazare Inepologlou
> >
> > Yes, like that, only better. Since automatic type casting is central in
> > PHP, as this is evident after all this discussion, I believe that it
> > should
> > be better supported. There are two thinks that I would like to see here:
> >
> > 1. No more magic methods, please.
> > 2. It should cover (eventually) casting to and from any type.
> >
> > :-)
> >
> > Lazare INEPOLOGLOU
> > Ingénieur Logiciel
> >
>
> Hi, Lazare
>
> As you mentioned it in another thread, I like the idea of C# you described
> ...
> Draw a line between explicit and implicit casting.
>
> What the current idea would be is an implicit casting (as I understood
> it right).
> Let me just repeat your examples:
>
> 2012/3/7 Lazare Inepologlou
> > function test_float( float test ) { ... }
> > test_float( 1.0 ); // ok
> > test_float( 1 );// implicit int to float cast, ok
> >
> > function test_array( array test ) { ... }
> > test_array( array() ); // ok
> > test_array( 1 );// no implicit int to array cast, error!
> > test_array( (array)1 ); // explicit int to array cast, ok
>
> An explicit type-cast should be always possible and try to get the
> very last bit of useful information out of the given bunch. Here it
> makes sense to have magic functions for integer, float, string etc.
>
> But as we're here talking about an implicit casting when passing a
> class to a function, I don't like the idea of calling the
> magic-functions if you paste a class in here as it changes the content
> of the variable. This won't make it easy passing a variable as
> reference. If you just switch to another type, you can afterwards do
> whatever you was able to do before.
>
> Bye
> Simon
>
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
> What other types (except from other classes)... I was talking about other classes... Of course, this does not have to be implemented right now, but the syntax should not close the door for something like that in the future. > If the magic is useful, why not add the ability? Because it is ugly and limited. All the resent discussion resulted to the fact that type casting is one of the central features of PHP that we cannot live without. So I think that the mechanism to expand type casting should be promoted, even with some special new syntax. :-) Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/9 Anthony Ferrara > Lazare, > > On Fri, Mar 9, 2012 at 8:54 AM, Lazare Inepologlou > wrote: > > Yes, like that, only better. Since automatic type casting is central in > PHP, > > as this is evident after all this discussion, I believe that it should be > > better supported. There are two thinks that I would like to see here: > > > > 1. No more magic methods, please. > > Any particular reason? If the magic is useful, why not add the > ability? I'm not saying we should get to python level with the shear > number of magic methods, but to artificially limit when useful > behavior can be added... I'm not so sure... > > > 2. It should cover (eventually) casting to and from any type. > > This doesn't? What other types (except from other classes) would you > like to see (or could we do besides resource and null)??? > > Anthony >
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
Yes, like that, only better. Since automatic type casting is central in PHP, as this is evident after all this discussion, I believe that it should be better supported. There are two thinks that I would like to see here: 1. No more magic methods, please. 2. It should cover (eventually) casting to and from any type. :-) Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/9 Anthony Ferrara > > (Now, it would be nice to have another RFC about custom object casting to > > int, float and bool...) > > You mean like https://wiki.php.net/rfc/object_cast_to_types which is > still in draft? > > Note that __toBool would be problematic, since it would be called if > the object was used in an if statement, which could yield some very > strange results if it returned false (it would break the existing > semantics about how we can use if statements to determine if the type > is populated)... > > Anthony >
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
I like it.
(Now, it would be nice to have another RFC about custom object casting to
int, float and bool...)
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/9 Anthony Ferrara
> Hey all,
>
> As promised, I've created a POC patch to implement scalar type hints,
> the way that zend_parse_parameters handles hinting. First off, here's
> the patch:
>
> Directly apply-able without re2c:
> https://gist.github.com/2004623
>
> Removing generated files (requires re2c to compile):
> https://gist.github.com/2004650
>
>
> It's a POC, but it mostly works. There is one known issue: passing a
> class implementing __toString to a string hinted function will raise a
> segmentation fault. There's also an issue of not separating the
> argument on cast yielding to reference whether indicated or not, but
> that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in
> the cases where it would cast)... I'll work on cleaning it up, but I
> wanted to show the concept before investing too much work...
>
> So, basically, there are 4 new parameters:
>
> bool
> int
> float
> string
>
> The casting vs error rules are identical to zend_parse_parameters. So:
>
> function fooi(int $i) { var_dump($i); }
>
> fooi(1); // int(1)
> fooi(1.5); // int(1)
> fooi("1"); // int(1)
> fooi("1abc"); // int(1) + notice about non-well-formed numeric
> fooi("foo"); // E_RECOVERABLE_ERROR
> fooi(true); // int(1)
> fooi(array()); // E_RECOVERABLE_ERROR
> fooi($obj); // E_RECOVERABLE_ERROR
>
> function foob(bool $b) { var_dump($b); }
>
> foob(1); // bool(true)
> foob(1.5); // bool(true)
> foob("1"); // bool(true)
> foob("abc"); // bool(true)
> foob(true); // bool(true)
> foob(array()); // E_RECOVERABLE_ERROR
> foob($obj); // E_RECOVERABLE_ERROR
>
> function foos(string $s) { var_dump($s);
> foos(1); // string("1")
> foos(1.5); // string("1.5")
> foos("1"); // string("1")
> foos(true); // string("1")
> foos(array()); // E_RECOVERABLE_ERROR
> foos(new StdClass); // E_RECOVERABLE_ERROR
> foos($objImpl__toStringORcast_object); // string(result)
>
> Float works like int, so I won't list it out here...
>
>
>
> So, what do you think?
>
> Thanks,
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Scalar Type Hinting
> You could try some kind of stricter casting. Where odd conversions
between array/object <-> bool/int/float/string do not work on parameter
casting .. but then you end up with two types of casting ...
I have used in depth the casting operators of C#, which are incredibly
flexible and powerful, and they are based on this exact idea. In C#, there
are two types of casting: implicit and explicit. The first is used for
trivial conversions and the later for the "odd" ones. It is possible to
classify PHP's casts into these two categories:
int to string: implicit
int to float: implicit
int to object: explicit
int to array: explicit
...
Once this classification is done, the code becomes much more sane. Examples:
function test_float( float test ) { ... }
test_float( 1.0 ); // ok
test_float( 1 );// implicit int to float cast, ok
function test_array( array test ) { ... }
test_array( array() ); // ok
test_array( 1 );// no implicit int to array cast, error!
test_array( (array)1 ); // explicit int to array cast, ok
I deliberately avoided using Anthony's cast-like syntax, because it does
not fit nicely here. Calling a function may cause an implicit cast, but it
will never do an explicit one.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/7 Alan Knowles
> Comment in-line below...
>
> On Wednesday, March 07, 2012 07:10 AM, Simon Schick wrote:
>
>> Hi,:
>>
>> It got quite around that because we have some RFCs to this where the
>> functionality seems to be defined as the people thought it should be.
>> Otherwise they can raise their hands and write a mail that they want to
>> update the RFC - but as there's no one doing that, I think we're quite
>> close to what we wanted.
>>
>> Take a look at it and feel free to add your ideas in this thread.
>> https://wiki.php.net/rfc/parameter_type_casting_hints
>> https://wiki.php.net/rfc/object_cast_to_types
>>
>
> Been watching this for a while, got slightly interested in the parameter
> casting thing, but then ran a little test
> http://www.roojs.com/examples/types.php
>
> Casting on PHP may help the code inside the function, but the result is
> some weird and wonderful magic for the calling code, not to mention that
> the docs for (int) casting say the behavior may change, don't expect it to
> work like that forever..
>
> You could try some kind of stricter casting. Where odd conversions between
> array/object <-> bool/int/float/string do not work on parameter casting ..
> but then you end up with two types of casting ...
>
> Anyway, will go back to lurking for a while..
>
> Regards
> Alan
>
>
>> Bye
>> Simon
>>
>> 2012/3/6 Kris Craig
>>
>> Wow no offense, but your timing is terrible, Raymond! We've been going
>>> back and forth on this for the past couple weeks now, though the
>>> discussion
>>> has quieted for the moment.
>>>
>>> I would suggest you go through some of the recent posts on Internals.
>>> Right now there basically is no solid consensus on this issue, though
>>> some
>>> of us have been working to change that. But as it stands now, I'm not
>>> aware of any plans to introduce expanded typing of any kind in the
>>> foreseeable future. And even if we did, I highly doubt it would happen
>>> before PHP 6.
>>>
>>> --Kris
>>>
>>>
>>> On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving
>>> wrote:
>>>
>>> Hello,
>>>>
>>>> I came across some info on the web that states that scalar type hinting
>>>>
>>> was
>>>
>>>> added to the PHP trunk but it did not make it's way into 5.4 because of
>>>> objections from the community. Will it ever make it's way into 5.5?
>>>>
>>>> I know PHP is considered to be a weak typed language but it should also
>>>>
>>> be
>>>
>>>> about freedom. Freedom for a PHP developer to choose to use scalar type
>>>> hinting whenever he/she sees the need.
>>>>
>>>>
>>>> Best regards,
>>>> __
>>>> Raymond
>>>>
>>>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Hi Daniel, No, it is not inspired from the short ternary operator. It's a rather common conversion. C# has a similar notion of nullable types (with totally different mechanics however). By the way, in this particular area PHP's type system is more sound than that of C#, because null is not just a special value of any type but it is a value of a separate null type. Kudos to the original designers for this choice. Your proposal for (int unset) is not very far away from what I propose. In PHPDoc, and in many IDEs, there are often mixed types like these: int|string int|null string|bool|null bool|null DateTime|null ... Of all different combinations, the ones between a type and null are very usual. So, I propose "int?" as a shortcut for "int|null". In that sense, it is totally equivalent to "int unset" that you say. Personally, I find "unset" not proper for this case, because it is not going to unset anything that is not already null. > BTW: Order would equal what is type casted OR simply accepted! Do you have any examples where this could be useful? Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/5 Daniel Macedo > > This could be usefull for other instances as (string null) or (bool > > null) as well... Your thoughts? > > Typo! The examples should read (string unset) and (bool unset) > > BTW: Order would equal what is type casted OR simply accepted! > > ~ Daniel Macedo >
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
> > In your examples you are accessing an maybe non-existing array-key Yes, this is why I used the error silencing (@) operator. But anyway, it is irrelevant to the whole proposal. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/5 Simon Schick > Hi, Lazare > > In your examples you are accessing an maybe non-existing array-key. > This will raise an E_NOTICE. See the note below this example: > http://php.net/manual/en/language.types.array.php#example-85 > > Maybe you also want something like that: > isset($x) ? (is_null($x) ? null : (int)$x) : null > > But let's discuss that in a different thread. > > Bye > Simon > > 2012/3/5 Lazare Inepologlou > >> Anthony, >> >> I still don't like the null-as-a-default-value solution. I find it >> confusing. >> >> I know that something similar appears in class type hinting, but: >> 1. Class type hinting does not do casting (yet). >> 2. Apart from null, no other value could be placed anyway. (Even that is a >> little bit wrong as null belongs to a different type than the hinted >> class). >> >> --- >> >> I have a different proposal. The argument type hinting/casting should not >> be bothered with that at all. Instead, we could expand the type juggling >> system a little bit, with the introduction of a special type of casting >> that leaves null unchanged. Something like this: >> >> (int?) $x >> >> which should be strictly translated to the following, without any way to >> change that behavior by any type casting overload system: >> >> is_null($x) ? null : (int)$x >> >> Examples: >> >> (int?) 13 // 13 >> (int?) '' // 0 >> (int?) 0// 0 >> (int?) null // null >> (int?) '342.3Test' // 342 >> >> I can think of many real world scenarios that could benefit from this. The >> first that comes to my mind is reading from a database, in cases that the >> value of null totally different than the value of 0. >> >> $parent_id = (int?) $db['PARENT_ID']; // null and 0 mean different things >> here... >> >> A second example is reading from the query string: >> >> $id = (int?) @$_GET['id']; // the error-silencing operator will return >> null on error. >> >> >> Thoughts? >> >> >> Lazare INEPOLOGLOU >> Ingénieur Logiciel >> >> >> 2012/3/5 Anthony Ferrara >> >> > Matthew, >> > >> > Have you seen the new thread and RFC around this? >> > https://wiki.php.net/rfc/parameter_type_casting_hints >> > >> > I went with option A, as I see erroring on cast as a more general >> > problem. So for consistency, I implemented it exactly like normal >> > explicit casts... >> > >> > Anthony >> > >> > On Mon, Mar 5, 2012 at 10:27 AM, Matthew Weier O'Phinney >> > wrote: >> > > On 2012-03-02, Anthony Ferrara wrote: >> > >> Well, there are a few questions about the implementation: >> > >> >> > >> 1. *Which* type casting rules should it follow? >> > >> >> > >> a. Regular cast rules (like $foo = (int) $foo), where it converts >> > >> always without error? >> > >> b. Internal function cast rules, where it warnings on error and >> > >> prevents execution of the function. >> > >> c. Current type hinting rules, where if it can't convert cleanly it >> > >> E_RECOVERABLE_ERRORS >> > >> >> > >> Personally, I like C the best. Where if it is passed an invalid >> > >> value, it attempts to cleanly convert, but errors out if it can't... >> > >> But I can see other arguments being made... >> > > >> > > (c) seems the most sane option ot me as well. >> > > >> > >> 2. Should (array) be supported? Perhaps. So at that point, >> foo(array >> > >> $bar) would do a "strict" check, and foo((array) $bar) would attempt >> > >> to cast. But my question would be: what would attempt to cast mean? >> > >> Should it error out if you pass foo(1)? That's what the internal >> > >> function cast rules do. And to me that's more obvious than silently >> > >> converting it to foo(array(1))... >> > > >> > > Turn this around and look at it from the current state of PHP: >> > > >> > >function foo($bar) >
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Anthony,
I still don't like the null-as-a-default-value solution. I find it
confusing.
I know that something similar appears in class type hinting, but:
1. Class type hinting does not do casting (yet).
2. Apart from null, no other value could be placed anyway. (Even that is a
little bit wrong as null belongs to a different type than the hinted class).
---
I have a different proposal. The argument type hinting/casting should not
be bothered with that at all. Instead, we could expand the type juggling
system a little bit, with the introduction of a special type of casting
that leaves null unchanged. Something like this:
(int?) $x
which should be strictly translated to the following, without any way to
change that behavior by any type casting overload system:
is_null($x) ? null : (int)$x
Examples:
(int?) 13 // 13
(int?) '' // 0
(int?) 0// 0
(int?) null // null
(int?) '342.3Test' // 342
I can think of many real world scenarios that could benefit from this. The
first that comes to my mind is reading from a database, in cases that the
value of null totally different than the value of 0.
$parent_id = (int?) $db['PARENT_ID']; // null and 0 mean different things
here...
A second example is reading from the query string:
$id = (int?) @$_GET['id']; // the error-silencing operator will return
null on error.
Thoughts?
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/5 Anthony Ferrara
> Matthew,
>
> Have you seen the new thread and RFC around this?
> https://wiki.php.net/rfc/parameter_type_casting_hints
>
> I went with option A, as I see erroring on cast as a more general
> problem. So for consistency, I implemented it exactly like normal
> explicit casts...
>
> Anthony
>
> On Mon, Mar 5, 2012 at 10:27 AM, Matthew Weier O'Phinney
> wrote:
> > On 2012-03-02, Anthony Ferrara wrote:
> >> Well, there are a few questions about the implementation:
> >>
> >> 1. *Which* type casting rules should it follow?
> >>
> >> a. Regular cast rules (like $foo = (int) $foo), where it converts
> >> always without error?
> >> b. Internal function cast rules, where it warnings on error and
> >> prevents execution of the function.
> >> c. Current type hinting rules, where if it can't convert cleanly it
> >> E_RECOVERABLE_ERRORS
> >>
> >> Personally, I like C the best. Where if it is passed an invalid
> >> value, it attempts to cleanly convert, but errors out if it can't...
> >> But I can see other arguments being made...
> >
> > (c) seems the most sane option ot me as well.
> >
> >> 2. Should (array) be supported? Perhaps. So at that point, foo(array
> >> $bar) would do a "strict" check, and foo((array) $bar) would attempt
> >> to cast. But my question would be: what would attempt to cast mean?
> >> Should it error out if you pass foo(1)? That's what the internal
> >> function cast rules do. And to me that's more obvious than silently
> >> converting it to foo(array(1))...
> >
> > Turn this around and look at it from the current state of PHP:
> >
> >function foo($bar)
> >{
> >$bar = (array) $bar;
> >}
> >
> > If you pass a value of 1 for $bar, $bar is then converted to array(1).
> > That's what I'd expect the following to do as well:
> >
> >function foo((array) $bar)
> >{
> >}
> >
> > It's casting, and clearly different than:
> >
> >function foo(array $bar)
> >{
> >}
> >
> > which is doing a typehint check.
> >
> >> 3. Should references be supported? My feeling is yes, they should.
> >> So if you do foo((array) &$bar), it would cast the original value (if
> >> possible) as well.
> >
> > I personally would expect casting and references to be mutually
> > exclusive -- if you're casting, you're changing the value type, and I
> > wouldn't expect a destructive operation like this from passing a value
> > to a function/method call.
> >
> >
> >
> >> 5. What about BC breaks? Well, this entire patch (up to this point)
> >> wouldn't require one. it's only adding the casting functionality
> >> (which is not implemented today), so no problem. Existing code would
> >> still function fine.
> >
> > This is something that should be highlighted. I've seen a lot of folks
> > claiming type hinting is viral, and the arguments make no sense to me.
> > What your patch is offering is _opt_in_ type casting of
Re: [PHP-DEV] [RFC - Discussion] Parameter Type Casting Hints
Anthony, just a tiny detail in your RCF: So (int) $foo = null and (int) $foo = 1 are both supported, but (int) $foo > = “1” will generate an E_COMPILE_ERROR. > If null is going to be cast, (int)null is 0. So I don't think it should be a valid default value. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/4 Anthony Ferrara > Hey all, > > I've drafted an RFC for the Parameter type casting hint proposal that > I posted to before. Attached to the RFC is a patch that's proposed > for inclusion in core for functionality (it doesn't include news > entries, or documentation, or any of the other steps that would be > needed prior to commit). > > https://wiki.php.net/rfc/parameter_type_casting_hints > > Please provide feedback here on the implementation and RFC topics. > > Thanks, > > Anthony > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC - Discussion] Parameter Type Casting Hints
>
> I wouldn't want people to put class typehints in there such as
>
function foo( (SomeClass) $foo)
>
Why not? I would definitely like something like that, in the future. Here
is an example:
class DateTime {
...
public function add( (DateInterval) $interval ) { ... }
...
}
$date = new DateTime;
$date->add( 'P3D' ); // string to DateInterval casting
$date->add( 3600 ); // int (seconds) to DateInterval casting
Personally, I find this to be much closer to free type-juggling PHP style
than the current implementation with type hints (
http://www.php.net/manual/en/datetime.add.php).
[ Actually, I would prefer even type hints to work like this. Check if the
passed argument if of the correct type and, if not, try to cast it. Failure
to do so will lead to the E_RECOVERABLE_ERROR as today. ]
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/4 Paul Dragoonis
> Can you make sure that only scalar or array casts can be done?
>
> I wouldn't want people to put class typehints in there such as
> function foo( (SomeClass) $foo)
>
> - Paul.
>
> On Sun, Mar 4, 2012 at 1:28 AM, Anthony Ferrara
> wrote:
> > Hey all,
> >
> > I've drafted an RFC for the Parameter type casting hint proposal that
> > I posted to before. Attached to the RFC is a patch that's proposed
> > for inclusion in core for functionality (it doesn't include news
> > entries, or documentation, or any of the other steps that would be
> > needed prior to commit).
> >
> > https://wiki.php.net/rfc/parameter_type_casting_hints
> >
> > Please provide feedback here on the implementation and RFC topics.
> >
> > Thanks,
> >
> > Anthony
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
>
> To be honest, I'm not as sold on this version (I built it as a POC, but to
> see how useful it is). It feels like it's not doing "enough". All it really
> does is save 6 characters.
>
Personally, I think it saves much more characters (,,,in the
documentation).
And I think, that's enough. Nothing more is needed here. If we want to
expand further on, I believe that the type casting system should be
enhanced with custom casting functions. The other proposal that you've made
fits perfectly here. Would you like to test them combined?
Another point of expansion is to have something similar for object types.
However, this requires first the introduction of custom casting rules for
objects types as well. Maybe in the future.
Great work.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/3 Anthony Ferrara
> Hey all,
>
> Here's a much more robust and updated patch (actually, it seems good
> to go to me, but needs significant review)...
> https://gist.github.com/1963999
>
> One potential issue is that it requires an API change to
> zend_verify_arg_type (which appears to only be called in zend_vm_def.h
> - and by generation zend_vm_execute.h)... Otherwise, it's functional
> from my perspective...
>
> Here's what's implemented:
>
> The following cast syntaxes to the parameter type hints:
> (int)
> (float)
> (bool)
> (string)
> (array)
> (object)
>
> Basically, they behave exactly as the normal cast works. So it won't
> error except in odd edge cases (for example, passing StdClass object
> into (string)...
>
> So, based on that:
>
> function ((int) $i) {}
>
> is identical to:
>
> function ($i) {
>$i = (int) $i;
> }
>
> Additionally, the last 2 are a bit more interesting, as they will cast
> it to an array/object if necessary.
>
> To be honest, I'm not as sold on this version (I built it as a POC,
> but to see how useful it is). It feels like it's not doing "enough".
> All it really does is save 6 characters.
>
> Instead, I think I'd rather see it check for a clean cast, and at
> least throw an error on unclean cast (casting (int) "foo" in this
> context). However, that's not how the current cast handler works, so
> that's not what this does.
>
> Any feedback?
>
> Thanks,
>
> Anthony
>
>
> On Fri, Mar 2, 2012 at 3:15 PM, Adam Jon Richardson
> wrote:
> > On Fri, Mar 2, 2012 at 7:51 AM, Anthony Ferrara
> wrote:
> >>
> >> Well, there are a few questions about the implementation:
> >>
> >> 1. *Which* type casting rules should it follow?
> >>
> >> a. Regular cast rules (like $foo = (int) $foo), where it converts
> >> always without error?
> >> b. Internal function cast rules, where it warnings on error and
> >> prevents execution of the function.
> >> c. Current type hinting rules, where if it can't convert cleanly it
> >> E_RECOVERABLE_ERRORS
> >>
> >> Personally, I like C the best. Where if it is passed an invalid
> >> value, it attempts to cleanly convert, but errors out if it can't...
> >> But I can see other arguments being made...
> >>
> >> 2. Should (array) be supported? Perhaps. So at that point, foo(array
> >> $bar) would do a "strict" check, and foo((array) $bar) would attempt
> >> to cast. But my question would be: what would attempt to cast mean?
> >> Should it error out if you pass foo(1)? That's what the internal
> >> function cast rules do. And to me that's more obvious than silently
> >> converting it to foo(array(1))...
> >>
> >> 3. Should references be supported? My feeling is yes, they should.
> >> So if you do foo((array) &$bar), it would cast the original value (if
> >> possible) as well.
> >>
> >> 4. What about consistency? Well, there currently is no consistency.
> >> Internal function parameters behave one way, and explicit casts behave
> >> another. And even more confusing implicit casts behave yet another
> >> way ($a + $b). So to implement this, we'd need to be consistent with
> >> one of them. Frankly, I would only want to add consistency to
> >> internal function parameters, since the explicit cast is not useful
> >> IMHO (it's identical to $bar = (int) $bar), at which point it's not
> >> worth adding to save only that one line. But if we're consistent with
> >> internal function parameter checking, then it becomes quite useful.
> >> We can throw warnings on unclean conversion and prevent execution
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
+1 for the syntax. There are two nice side effects I would like to
underline.
1.
Error-raising can be clearly delegated to the type juggling mechanism.
There will be no need to implement anything new here but reuse the existing
type juggling system of PHP. That would be very consistent. At the end of
the day, these two syntaxes are completely equivalent:
function foo((int) $bar) { ... }
function foo($bar) { $bar = (int)$bar; ... }
2.
If we put passing by reference into the picture, it is easy to see why the
following syntax should be a parsing error:
function foo((int) & $bar) { }// parsing error
On the contrary, were there no brackets, the resemblance to the syntax of C
would be confusing.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/2 Anthony Ferrara
> Hey all,
>
> I know given all the discussion about this topic lately, this is a hot
> topic. But I whipped together a quick POC patch to implement scalar
> type casting for function parameters. Let me describe it:
>
> Patch: https://gist.github.com/1947259
>
> Example:
>
> function foo( (int) $bar ) {
>var_dump($bar);
> }
>
> foo(1); // int(1)
> foo("1"); // int(1)
> foo(1.5); // int(1)
> foo("foo"); // E_RECOVERABLE_ERROR - Expected integer
> foo(array()); // E_RECOVERABLE_ERROR
>
> Right now, I only implemented the checks for (int), but I add the
> parser constructs for (int), (float), (bool), (string) and (object)...
>
> Now, let's talk why I did what I did:
>
> Why did I use cast syntax? Well, there are really three main reasons.
> First off, to indicate that a cast may happen. Second, to prevent
> needing new tokens (and hence reserved words). And third to provide a
> distinction between a string class type hint and a string scalar type
> hint.
>
> Why did I only implement (int)? Well, because I just wanted to build
> a quick dirty POC that can be executed to see the semantics of
> operation. There are issues with it now, so rather than doing all the
> work to re-do it later, I just implemented int...
>
> Why implement (object)? Because right now, there's no way to say you
> want to accept a generic object without caring about type. So the
> (object) cast/hint would then provide that ability to accept a generic
> object.
>
> Why not implement (resource)? Because that would require a new parser
> token, as it's not available now...
>
> How does the casting work? Right now, it's using a copy of the same
> rules that internal functions use with zend_parse_parameters. That
> way, it brings the operating semantics of internal functions and
> userland functions more inline with each other.
>
>
>
> So with that said, there are some (significant) issues with the patch:
>
> 1. First off, the arg checks happen before separation of the zval on
> non-referenced calls. So that means the cast effects the original
> zval AND the argument. Which is a no-go for a production patch. So
> that means that the cast logic would need to be put after the zval
> split. But we'd still want the checks first, so it's not too
> difficult to segregate, just requires deeper changes. It's not
> difficult (that I can see yet), just more work... Example of the
> problem:
>
> # sapi/cli/php -r 'function foo((int) $bar) { var_dump($bar); } $a =
> "1"; foo($a); var_dump($a);'
> int(1)
> int(1)
>
> 2. Right now, the zend_aprse_arg_impl (
> http://lxr.php.net/xref/PHP_5_4/Zend/zend_API.c#zend_parse_arg_impl )
> that's used by internal functions is defined as static. So we'd be
> copying a lot of the code back and forth. In the production patch,
> I'd also want to re-factor that out a bit into either functions or
> macros to handle the type conversion and casting in both places. That
> way, both systems would behave identical (or as close as possible).
>
>
> So, with that said, what do you think? Is this something worth
> pursuing? Are there any fundamental issues that I'm missing? What
> else would we need to cover in a production patch and RFC?
>
> Thanks,
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Scalar Type Intentions
> > This is a potential concern if the aliases for scalar were included (bool, > int, float, string), as Anthony mentioned, although merely implementing the > first part of the proposal (scalar type hinting) wouldn't cause any trouble. > Yes, exactly. I was only talking about this specific aspect. Otherwise, it is a fine and welcome proposal. I would love to have type-checking as long as it does not close the door to type-juggling some time in the future. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/1 Adam Jon Richardson > On Thu, Mar 1, 2012 at 10:36 AM, Lazare Inepologlou wrote: > >> Of note, the scalar type hinting I've outlined does not automatically >>> perform casts... >> >> >> Thank you for your answer. Maybe, this exact fact is what I don't like >> about your suggestion. Please read the following RFC, where Lukas Smith and >> Zeev Suraski explain very well why strict type checking without >> auto-casting is a not a great idea. Of course it is just an RFC, but I find >> it quite correct. >> > https://wiki.php.net/rfc/typecheckingstrictandweak > > > I believe we interpret that RFC differently. Those who wrote it can > correct me if I'm in error. The RFC is a very interesting approach to > providing some form of type hinting for scalar parameters in functions and > methods. I liked the RFC, but I understand some of the concerns that come > up when discussing something like it. > > First, I believe that when the RFC contrasts strict and weak typing, it > would be fair to say this is what many others would describe as strong vs > weak typing: > > http://en.wikipedia.org/wiki/Type_system#Strong_and_weak_typing > > The RFC makes the case that strict typing is "is an alien concept to PHP", > and that it "goes against PHP's type system", while pointing out other > issues. The RFC makes it clear that trying to map strict typing onto PHP is > problematic, and on this issue I tend to agree. > > The RFC then offers three options for weak type hinting. One main point > I'd bring out for all of the options is that they all strengthen the typing > (that is, while still a weak type system, it moves slightly towards the > strong side of the continuum) beyond PHP's default type juggling rules > because some type of error would be raised in the event of data loss. > > So, their proposal outlines weak forms of type hinting for scalars, and > mine is similar but weaker, as there is no auto casting, there are no new > errors raised for data loss, and all checks are against the generic scalar > type (whether with or without the aliases.) This brings my proposal even > closer to the fundamental typing characteristics of PHP, whilst protecting > against the potential errors pointed out in my earlier examples. > > >> >> My concern is that if your suggestion is adopted (as it is, without >> auto-casting) then an eventual introduction of auto-casting will be >> impossible without breaking BC. >> > > This is a potential concern if the aliases for scalar were included (bool, > int, float, string), as Anthony mentioned, although merely implementing the > first part of the proposal (scalar type hinting) wouldn't cause any trouble. > > However, the more a proposal moves away from PHP's current typing > conventions, the less likely it is to be considered, let alone approved. > I'm not confident a more aggressive proposal (e.g., auto-casting with > checks for information loss) would be approved any time soon. PHP is one of > the most practically oriented programming languages I'm aware of, and my > practicalities just want to put forward ideas that improve some issues AND > that might actually get done :) > > Again, thanks for the commentary, Lazare. > > Adam >
Re: [PHP-DEV] Scalar Type Intentions
>
> Of note, the scalar type hinting I've outlined does not automatically
> perform casts...
Thank you for your answer. Maybe, this exact fact is what I don't like
about your suggestion. Please read the following RFC, where Lukas Smith and
Zeev Suraski explain very well why strict type checking without
auto-casting is a not a great idea. Of course it is just an RFC, but I find
it quite correct.
https://wiki.php.net/rfc/typecheckingstrictandweak
My concern is that if your suggestion is adopted (as it is, without
auto-casting) then an eventual introduction of auto-casting will be
impossible without breaking BC.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/1 Adam Jon Richardson
> On Thu, Mar 1, 2012 at 8:33 AM, Lazare Inepologlou wrote:
>
>> Yes, I agree, the casting (or the failing to cast) has to happen on
>> entry, for the reasons that you have very well explained.
>>
>> However, I cannot understand what it means to cast an object to a scalar.
>> Does it always mean casting to string? Wouldn't that be slow in many cases?
>> Simple example:
>>
>
> I'm not sure I understand, so if I mischaracterize your concerns, please
> let me know.
>
> Of note, the scalar type hinting I've outlined does not automatically
> perform casts to any particular type of scalar. Rather, it would be the
> programmer's responsibility to perform the cast (as I performed in my
> example.) This way, only necessary, reasonable casts are performed, and
> information loss can be avoided.
>
> That said, in terms of performance, PHP's type juggling performs these
> types of casts all the time, so I don't think I'd be concerned. Any time we
> check for equality using ==, perform string concatenation with ints, etc.,
> PHP's beautiful type juggling automatically performs these conversions for
> us without any effort on our part. I've never seen where this is the source
> of any performance issues in my profiling, but I must admit that I don't
> know the internals well enough to preclude this from ever being an issue.
>
> class A {
>> public $value = 1234;
>> public function __toString(){ return (string)$this->value; }
>> }
>>
>> function foo( int $x ) { // here "int" is used as an alias to "scalar"
>> as you suggest
>> return $x + 1;
>> }
>>
>> $a = new A;
>> foo( $a ); // casting $a to scalar upon calling, as it is possible
>> after all
>>
>> In this example, the integer value will have to be cast to a string only
>> to be cast back to integer (unless something else happens under the hoods
>> that I am not aware).
>>
>
> Speaking to your example, it would throw a catchable fatal error because
> the variable $a contains an object of type A and the function foo expects a
> scalar. The object would first have to be cast to a scalar. However, as you
> pointed out, currently objects can only implement the __toString() method
> (i.e., there's no __toInt, etc.), so one can't directly cast an object to
> an int.
>
> This seems contrived, though, because in the case of your example, if a
> function expects an integer, wouldn't you just call it with the appropriate
> object property:
>
> foo ($a->value); // works because the value property is a scalar (int)
>
> Thanks for your commentary :)
>
> Adam
>
>
Re: [PHP-DEV] Scalar Type Intentions
Yes, I agree, the casting (or the failing to cast) has to happen on entry,
for the reasons that you have very well explained.
However, I cannot understand what it means to cast an object to a scalar.
Does it always mean casting to string? Wouldn't that be slow in many cases?
Simple example:
class A {
public $value = 1234;
public function __toString(){ return (string)$this->value; }
}
function foo( int $x ) { // here "int" is used as an alias to "scalar" as
you suggest
return $x + 1;
}
$a = new A;
foo( $a ); // casting $a to scalar upon calling, as it is possible after
all
In this example, the integer value will have to be cast to a string only to
be cast back to integer (unless something else happens under the hoods that
I am not aware).
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/1 Adam Jon Richardson
> On Thu, Mar 1, 2012 at 4:36 AM, Lazare Inepologlou wrote:
>
>> And, *what if PHP added the following aliases for the hint scalar*:
>>
>> - bool
>>
>> - int
>>
>> - float
>>
>> - string
>>>
>>
>> If an object has a __toString method, does it qualify as a valid value to
>> be passed to a scalar argument? In my opinion, it should.
>>
>> Your suggestion has a future compatibility problem. The introduction of
>> new type casting methods (like __toInt or like __castTo) is an open
>> possibility. In such a case, if those keywords are nothing but aliases for
>> "scalar", then there will be no way to choose which type casting method
>> should be chosen.
>>
>>
>> Lazare INEPOLOGLOU
>> Ingénieur Logiciel
>>
>
> You raise interesting points, Lazare, but I don't believe the
> compatibility issues you're concerned about are valid.
>
> Failing fast, similar to the Poka-Yoke principal in manufacturing,
> suggests that system failure should occur as soon as possible to reduce
> software bugs:
> http://www.martinfowler.com/ieeeSoftware/failFast.pdf
>
> Consider the following example:
>
> // example class that does not implement __toString()
> class test{
> }
>
> function foo($arg1, $arg2, $arg3){
>if ($arg1) {
> return "The answer is: " . $arg1;
>}
>
>if ($arg2) {
> return "The answer is: " . $arg2;
>}
>
>if ($arg3) {
> return "The answer is: " . $arg3;
>}
> }
>
> $test = new test();
>
> echo foo($arg1 = "string", $arg2 = 100, $arg3 = $test); // echos The
> answer is: string
> echo foo($arg1 = false, $arg2 = 100, $arg3 = $test); // echos The answer
> is: 100
> echo foo($arg1 = false, $arg2 = false, $arg3 = $test); // catchable fatal
> error
>
> A developer using this function would only see this issue some of the
> time, as this code fails late WITHIN some branches of the function, and the
> bug is harder to identify.
>
> We can do better, though. If the scalar type hint were applied, users
> would merely have to cast the object to a string ON ENTRY to the function
> (and, of note, this would work for your __toInt and __castTo concerns):
>
> echo foo($arg1 = "string", $arg2 = 100, $arg3 = (string)$test);
> // catchable fatal error
>
> Because the cast is performed on entry to the call, the bug shows up
> immediately. I would argue that this code is clean (the cast to string in
> the foo() call is a small amount of noise/keystrokes), visibly conformant
> to the intentions of the foo() function, and more likely to catch bugs
> early on in the process.
>
> Adam
>
>
Re: [PHP-DEV] Scalar Type Intentions
>
> And, *what if PHP added the following aliases for the hint scalar*:
- bool
- int
- float
- string
>
If an object has a __toString method, does it qualify as a valid value to
be passed to a scalar argument? In my opinion, it should.
Your suggestion has a future compatibility problem. The introduction of new
type casting methods (like __toInt or like __castTo) is an open
possibility. In such a case, if those keywords are nothing but aliases for
"scalar", then there will be no way to choose which type casting method
should be chosen.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/1 Adam Jon Richardson
> PHP currently allows users to provide type hints for functions and methods,
> although the type hints are currently limited to objects and arrays:
> http://en.wikipedia.org/wiki/Type_system#Variable_levels_of_type_checking
>
> Restricting the type hinting to arrays and objects makes sense, as PHP's
> type juggling (similar in many ways to JavaScript's), a core feature of the
> language, performs automatic conversions between scalars as determined by
> context:
> http://php.net/manual/en/language.types.type-juggling.php
>
> However, the lack of scalar hinting does limit the ability of a developer
> to declare his/her intentions for function/method parameters. A non-hinted
> parameter expecting a scalar could be sent an object or an array, breaking
> the expectations (and much of the time, the functionality) of the code.
> That is to say, there is a value in declaring what the parameter IS NOT,
> too.
>
> For example, the function below could have an object or array passed as the
> first argument, even though the expectation is a scalar:
>
> function foo($arg){
> // $arg is supposed to be a scalar and will be used as an int
> }
>
> *What if PHP added the hint scalar?* The example could be rewritten as:
>
> function foo(scalar $arg){
> // $arg is supposed to be a scalar and will be used as an int
> }
>
> The idea is that the failure to send a valid scalar argument to the
> function would result in the same feedback that currently occurs when array
> or object hints are not heeded. Now, the expectations for each
> function/method parameter can be explicitly declared (or, at least, more
> explicitly.)
>
> And, *what if PHP added the following aliases for the hint scalar*:
>
> - bool
> - int
> - float
> - string
>
> The function could then be rewritten as below:
>
> function foo(int $arg){
> // $arg is supposed to be a scalar and will be used as an int
> }
>
> Now, the aliases wouldn't buy any more precision in terms of PHP's parser
> expectations. Your function/method parameters can only expect objects,
> arrays, or scalars. However, the aliases would allow developers to better
> communicate intentions AND provide more information for IDE's and static
> analyses tools. And, again, the use of the scalar hint and its aliases
> would preclude sending objects and arrays to functions expecting otherwise.
>
> I realize this subject is heated, and people's patience has worn thin. I'm
> just hoping to toss out this idea I've had for some time while all of the
> concerns on both sides are still fresh in my head.
>
> Thanks for reading :)
>
> Adam
>
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
> That's what I was calling "inconsistent", specifically because (int)'foo' > == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an > error of some sort. Behavior with respect to when an error is raised is > inconsistent. In both cases there is a very lossy conversion, why is there > an error in one case and not the other? Inconsistent. > +1 However, I would love to have int $a = 'foo' cast to 0 without any error. New functionality without breaking BC. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/1 John Crenshaw > From: Simon Schick [mailto:simonsimc...@googlemail.com] > > > > Hi, John > > > > Just to add an idea to yours .. > > > > Do you think it's a compatibility-break if we'd decide to send a > E_NOTICE or E_WARNING if we f.e. try to give a string to a method that just > allows integer for this argument? > No break at all, just a E_NOTICE or E_WARNING as the script can succeed > anyways. > > > > Bye > > Simon > > That's what I was calling "inconsistent", specifically because (int)'foo' > == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an > error of some sort. Behavior with respect to when an error is raised is > inconsistent. In both cases there is a very lossy conversion, why is there > an error in one case and not the other? Inconsistent. > > On the other hand if you add an error in the legacy case now that's a BC > break. One might argue that it should always have given a notice, but it > didn't, so it's a change, and a BC break. Pick your poison. > > John Crenshaw > Priacta, Inc. >
Re: [PHP-DEV] Scalar type hinting
> int $a = "1"; // no error. 1 == "1" so who cares? > int $a = 'House'; // error 0 != 'House', so this is a problem. For the sake of consistency, please take into account this example, which works in the current implementation of PHP: $b = 1 + "1"; // no error, $b == 2 $b = 1 + "House"; // no error, $b == 1 So, I believe that, raising an error or not, is not a question of the new RFC. Should there be an error, then it has to be in every unsuccessful type juggling, regardless of the final assignment to a type-locked variable. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/2/29 Michael Morris > Agreed. If conversion can occur without data loss (that is, if the > value being assigned is == the value that actually IS assigned) then > no error should occur. > > So > > int $a = "1"; // no error. 1 == "1" so who cares? > int $a = 'House'; // error 0 != 'House', so this is a problem. > > Again, errors should only raise if the final value != source value. > > On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer > wrote: > > On 2/28/2012 2:58 PM, Kris Craig wrote: > > > >> strong int $a = "1"; // Converts to 1. May or may not throw an error > (I'm > >> still on the fence). > > > > > > It this is an error, it is no longer PHP. > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
Hello Antony, You did a nice work for the RFC. However, I have to disagree with the name __assign, because it limits the type casting operation only to assignments. An implicit type casting could very well happen upon calling a function with type hints. Therefore, I would suggest the use of something like __castFrom(mixed $value). Of course, this changes the semantics a little bit: 1. The function has to be static. 2. The function has to return the new object. I would suggest to check out C# implicit casting, which does exactly this thing (in compile-time however). Check this example: http://msdn.microsoft.com/en-us/library/z5z9kes2.aspx This way we don't mess up with the assignment operator. Meanwhile, there is another interesting RFC under discussion (check the thread "Scalar Type Hinting") which seems to be far more promising than overloading the assignment operator. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/2/29 Anthony Ferrara > Hey all, > > I've created a draft version of the RFC for implementing __castTo() > and __assign(): > > https://wiki.php.net/rfc/object_cast_magic > > It's still a draft, and has a lot more work to do, but I figured this > would be enough to start triggering some discussion (or at least a > little bit more focused discussion). > > > > One plea: Please keep this thread on-topic discussing the RFC and its > implications... > > Thanks! > > Anthony > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Scalar type hinting
Hello everyone, Let's stop the religious war between strongly and weekly typed languages. In software, there is no silver bullet. Both approaches have their benefits and their disadvantages, so trying to prove that one is better to the other leads to nowhere. Having said that, I don't think that PHP will any time soon become a strongly typed language. However, as there are indeed benefits to strongly typed languages, I see no reason to just close the door. I think it's high time that we separated the PHP *platform* from the PHP *language*. That will eventually lead to the creation of strongly typed languages that could be executed on the PHP platform. Just my two cents :-) Lazare INEPOLOGLOU Ingénieur Logiciel 2012/2/28 Arvids Godjuks > Aren't you people getting tired of saying that arguments like "it's > not the PHP way" or "that does not fit the PHP paradigm" are invalid. > Are you even aware, that language is not only about the features, but > is also about the paradigm, syntax, philosophy and methods of how it > achieves it's goals? It's not as simple as "nah, lets add feature X, > it looks weird and alien, but who cares as long as it's cool!". > On the terminology - strict is strict, weak is weak. Writing a > statement at the start of the thread and adding a few new words will > make no difference. Because half the people will just skip it, or > didn't read carefully because it's not interesting and so on. Some > people on the list just assume that we are perfect beings and read > every line of what's written on the list (hell, I skim the text and > read only the important things. I have ~15 threads active in my > mailbox (only the internals, not counting other mail) and reading each > of it carefully will just take too long). > > Besides that - a scripting language is much easier to learn, use it > and learn it. Things like strict typing, strict type hinting and so on > are not as trivial to understand and learn unless you start with a > strict typed compiled language. When you deal with the script language > and loose variable typing you get used to being able to convert types > on the fly. And imagine the shock when you start using some strict > typed library and now you have to convert all your variables > explicitly. And now the code looks just like C/C++/Java/Delphi code - > type conversion statements all over the place. I sure don't want such > code. And not because it is hard to combine (or impossible) weak and > strict type hinting - that just does not suit a scripting language > created with loose/weak typing in the first place. And adding such > things will not improve the code - it will mess it up big time. I > don't know about you, but I have seen and worked with folks who did > some really weird things in PHP. An instrument like strict type > hinting will just give them the ability to write code that is plain > stupid. It will be just like OOP for the sake of OOP. Too many people > do not understand the philosophy behind the PHP and they build over > complex things and complain that they had to become "inventive" to be > able to do implement something from the C++/Java/Python/Ruby world. > And they complain that PHP is a bad language, but still eat the > cactus. I wonder why? > > I really liked what the O'Raily wrote here: > > http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html > I know, some things are a little over the top, but in general it > describes the best PHP feature - it's easy to work with, it's easy to > make something without using any frameworks, libraries and just do the > work you need for the WEB. > And I think it should stay that way. And I personally like it that > way. And it's because of that I don't want to migrate to Ryby or > Python. Adding strict type hinting will ruin it because I know for a > fact that there are plenty of programmers who will turn their API's > into strict typed all over the place. And I will have to select my > data from the database and go through the records and explicitly > convert all my data to the correct types so I can use that wonderful > library whose author is a fond of strict typing. I see such things > with OOP right now in many places - they ask you for an object, but I > know it just really needs a string with the data to do the work. > Many people migrate to PHP from different languages, and mostly those > are strictly typed compile languages (I actually had teached PHP for 2 > years at the private school of web technologies - I saw many people > learning PHP after Java, C++, Delphi, even assembler). > It's not the problem that will become a problem in a year or two - it
Re: [PHP-DEV] An implementation of a short syntax for closures
> ... ( $x ) => $x + 1 for example would be ambiguous if used in an array
> definition, but is otherwise the best in terms of readability.
> ... people wanted an easy way to grep for function declarations
A new and unique operator (like the |=> I have proposed) is a solution
that works because:
1. A lambda expression can be part of other expressions, like arrays.
Therefore, we cannot reuse =>, or ->.
2. Multiple lambda expressions can be chained. The operator must have
very low precedence and it be right associative.
3. Lambdas should be grep-able.
For those who would like to try other syntaxes that could work in PHP,
I suggest a simple and creative way to approach this. All we need is 3
operators:
OP_A args OP_B lexical_vars OP_C expr
Operator OP_C ought to have the above properties (unique, low
precedence, right associative). On the other hand there are no
restrictions about OP_A and OP_B and we can reuse existing ones as
long as they don't conflict and they look nice.
:-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
2011/8/4 Johannes Schlüter :
> On Thu, 2011-08-04 at 21:18 +1000, Ryan McCue wrote:
>> Lazare Inepologlou wrote:
>> > Thank you for your interest. This is just a proposal that I have tested and
>> > works. Of course, the final syntax can be different. Syntax is always a
>> > matter of taste :-)
>>
>> As much as I love the idea, I have to agree that using | doesn't really
>> make sense here and actually makes the readability worse, IMO. However,
>> I can't really think of a better operator. ( $x ) => $x + 1 for example
>> would be ambiguous if used in an array definition, but is otherwise the
>> best in terms of readability.
>
> If you go there you can also allow more complex statements and re-use
> symbols used to group statements, using a syntax like
>
> ( $x ) { $x + 1; }
>
> Oh wait - now we've reached a point which was mentioned in this thread
> already "allow to drop the function keyword".
>
> Back when I proposed to drop "function" a key argument was that people
> wanted an easy way to grep for function declarations. I accepted the
> validity of that concern and think this might be a case here, too. The
> difference of these few characters is not that much but the keyword
> gives a clear guidance what's going on, else you might end up with a
> long list of random characters next to each other ...
>
> johannes
>
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
Hello,
>> $add = | $x |=> | $y : $x |=> $x+$y;
> Not sure that it's really readable.
This is not the most trivial example. In my blog, there is a small
sub-section where I explain why this is more readable than an implementation
with the current syntax. See under "Readability" and "A more complicated
example".
http://linepogl.wordpress.com/2011/08/04/short-closures-for-php-an-implementation/
:-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
Le 4 août 2011 10:50, Frédéric Hardy a écrit
:
> Hello !
>
>> I've always thought that just supressing the "function" keyword could work
>> as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
>> similar to Ruby's lambda shorthand:
>> http://slideshow.rubyforge.org/ruby19.html#40
>>
>>
> Huge +1 for that.
> Code using closures will be more readable.
>
>> $add = | $x |=> | $y : $x |=> $x+$y;
>>>>
>>>>
>>> Not sure that it's really readable.
> Moreover, it's more Perl/Ruby way than PHP way.
>
> Best regards,
> Fred
>
> --
>
> Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
> CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf
> Blog : http://blog.mageekbox.net
> Twitter : http://twitter.com/mageekguy
>
>
>
Re: [PHP-DEV] An implementation of a short syntax for closures
Good morning Rasmus, Thank you for your interest. This is just a proposal that I have tested and works. Of course, the final syntax can be different. Syntax is always a matter of taste :-) > it is only useful in one limited type of trivial closure usage This trivial usage is actually the most common one. A single-return closure can be used for sorting, mapping, filtering, lifting, folding, comparing, validating, formatting, lazy-loading etc. which cover the majority of the tasks a PHP programmer does everyday. The popular LINQ library is just an example of the power of this kind of closures. The only case that these closures are not useful is asynchronous (event-driven) programming. However, PHP is single threaded and usually delegates the user interface to javascript, and therefore, two major needs for asynchronous programming are eliminated. > In PHP we try really hard not to invent new unfamiliar syntax. I have done some research before posting and it seems that the proposed syntax is not at all uncommon. For example, here is the same comparer written in a variety of languages: Proposed for PHP: | $x , $y |=> $x - $y C#: ( x , y )=> x - y Haskell: \ x y -> x - y Python: lambda x y: x - y OCaml, F#: fun x y -> x - y StandardML: fn x y => x - y There are many similarities here. In all of the above examples, there is no return and no curly brackets. In addition, all expressions begin with a token and separate the arguments from the returning expression with another token. Kind regards, Lazare INEPOLOGLOU Ingénieur Logiciel 2011/8/4 Rasmus Lerdorf > On 08/04/2011 12:08 AM, Lazare Inepologlou wrote: > > $add = | $x |=> | $y : $x |=> $x+$y; > > This does not seem to match the syntax of any language I know of so > people are going to have a hard time figuring out what this does. It's > not even clear that |=> is a new operator there due to the dangling |, > which as you say conflicts with the regular | operator. Plus it is only > useful in one limited type of trivial closure usage. > > In PHP we try really hard not to invent new unfamiliar syntax. We try to > stick with things that have some basis in either the existing syntax or > in other popular languages that the average PHP developer might be > exposed to. > > -Rasmus >
[PHP-DEV] An implementation of a short syntax for closures
Hello everyone.
I am new to the php-internals list. I have joined because I have
implemented a feature that I would like to be included in the php
language: a shorter syntax for lambdas. I am going to briefly present
it here. Apologies for the long (and yet incomplete) e-mail. I am
ready to write a more complete RFC in the wiki, however, I would
appreciate having some directions for that. Do I have to ask for
permission first? Is it open to anyone to submit an RFC?
1. NECESSITY:
This feature was briefly discussed in this list about a month ago:
http://marc.info/?t=13092691823&r=1&w=2.
It is also one of the asked (and upvoted) features in the open stack
overflow's discussion:
http://programmers.stackexchange.com/questions/27564/what-features-would-you-like-to-have-in-php.
Finally, I have written a small and probably incomplete article in my
blog about the necessity of a shorter syntax for lambdas:
http://linepogl.wordpress.com/2011/07/09/on-the-syntax-of-closures-in-php/
2. THE CURRENT SYNTAX
I give 3 examples with the current syntax:
// Mapping:
$a->select( function($x){ return $x->getName(); } );
// Filtering:
$a->where( function($x)use($y){ return $x==$y; } );
// Currying:
$add = function($x){ return function($y)use($x){ return $x+$y; }; };
In my opinion, the above code is not easily readable. Yet, those
examples are not very complicated. The first two are samples of
elegant LINQ-style code while the last one can be found in the first
pages of any functional programming tutorial.
3. PROPOSED SYNTAX
The syntax I propose and I have already implemented is this:
// Mapping:
$a->select( | $x |=> $x->getName() );
// Filtering:
$a->where( | $x : $y |=> $x==$y );
// Currying:
$add = | $x |=> | $y : $x |=> $x+$y;
4. ADVANTAGES
a. The code is more readable (see more in my blog if you are not
convinced about that).
b. The syntax is backwards compatible. The short lambda and the longer
equivalent are interchangeable.
c. Variable scoping works exactly like in the longer version. There is
nothing new but syntactic sugar.
d. Lambda expressions are searchable. The |=> operator is unique.
e. The |=> operator is similar to =>. That's good because they both
relate to mapping. In addition, the : operator is similar to :: and
that's also good because they both relate to scoping.
f. The implemented syntax supports type hinting, passing by reference
and return by reference. There is also an option to fall back to a
statement block if the single return statement is not enough.
Therefore is a complete alternative to the existing syntax.
5. DISADVANTAGES
a. The short syntax is clear and readable, but can become confusing
when used in the wrong places. Yet, isn’t this the case with every
feature?
b. A lambda without arguments conflicts with the logical or operator.
A way to avoid this is to insert whitespace between the two pipes, but
this breaks the invariant that whitespace is not important in PHP.
Although this use case is not ideal for short lambdas, it can be fixed
at the compiler level by introducing the rather long operator ||=>.
c. The newly introduced feature of static closures is not yet
supported. The short lambdas behave like dynamic closures for the time
being.
You can download the patch on the 5.4 branch from here:
https://bitbucket.org/linepogl/php_short_closures/downloads/short_closures_syntax_0.1_php54.diff
I have posted a more complete presentation here:
http://linepogl.wordpress.com/2011/08/04/short-closures-for-php-an-implementation/
I am ready to give more examples and to further defend my proposal.
However as I am new to your community, I would like to have some
directions on the way I should continue.
Kind regards,
Lazare INEPOLOGLOU
Ingénieur Logiciel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
