ould 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
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 P
ogrammer'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.
at this point?
>
> Can we / could we do "extends self", "extends static", or even "extends
> $someclassname" ?
>
>
+1
Lazare INEPOLOGLOU
Ingénieur Logiciel
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 ty
tatic" 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
e 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 $
ough 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
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
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 constr
this feature yet. It's just a weak RFC, so let's wait
for better approaches.
Lazare INEPOLOGLOU
Ingénieur Logiciel
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
m
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
sspelled 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
ntage: 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
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.
> >>
> >>
e. 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
y.
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.
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
>
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
>
ility 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
h 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
;new ReplectionMethod('foo','bar')". The added
value is that it can be statically checked.
Lazare INEPOLOGLOU
Ingénieur Logiciel
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
tinue" 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
t;
> 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
es?
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
t; > 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
t; >> 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
t;
> > 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
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?
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
> 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
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>
> >>
>
to 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
x27;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
> 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
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 ) { ... }
>>
>
e 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 Ch
> 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
omething 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,
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 hint
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:
> >
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 ab
> 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 Lo
d 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 ); /
separates the notions of the type
and that of the default value.
Lazare INEPOLOGLOU
Ingénieur Logiciel
y 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
er) { ... }
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
s 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 Lo
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
> sti
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,
licit 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 RFC
" 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
> >
>
> 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 e
d = (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 F
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 INEPOLOGLO
hp.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 Dra
int 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
$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
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, L
uto-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 reas
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:
blem. 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
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
"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-lo
:
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 ope
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 "t
e 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:
>&g
;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
rning 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 kn
ation/
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
72 matches
Mail list logo
