I will not
On 22 January 2018 at 22:11, Stanislav Malyshev wrote:
> Hi!
>
>> I want to see strict typing as an option, not a requirement.
>
> You seem to be under impression that this somehow makes things easier.
> It does not. To explain: let's say you design a strictly typed language,
> like Ja
Hi!
> I want to see strict typing as an option, not a requirement.
You seem to be under impression that this somehow makes things easier.
It does not. To explain: let's say you design a strictly typed language,
like Java. The compiler knows which variable is of which type at every
point, and if i
In my opinion The Strong Typing Syntax RFC will have less of a chance of
passing a vote than https://wiki.php.net/rfc/typed-properties.
Since the typed-properties RFC was confined to properties on a class (and
looking at the code it appears to me that it wasn't too difficult to
implement the type s
On 10/01/2018 18:39, Michael Morris wrote:
On Wed, Jan 10, 2018 at 9:04 AM, Rasmus Lerdorf wrote:
Describing the syntax/UI for a feature like this is nothing like the
architectural drawings for a skyscraper.
In terms of time and effort spent it is. It often takes years to complete
plans drawn
Whether we work with runtime type checks or compile-time static analysis:
The user-facing language design questions would still be the same, right?
E.g. we would still have to distinguish type-locked parameter values
vs dynamically typed parameter values.
On 10 January 2018 at 20:23, Andreas Henni
On 10 January 2018 at 19:59, Rasmus Lerdorf wrote:
>
> Now if the RFC was a plan for baking a compile-time static analysis engine
> into PHP itself, that would be interesting. But that is a *massive* project.
Even with my limited understanding of the engine, I can imagine this
to be a lot of work
On Wed, Jan 10, 2018 at 10:48 AM, Michael Morris wrote:
> On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf
> wrote:
>
> > If you stay away from trying to change a 25-year old loosely typed
> > language into a strictly typed one, then the RFC becomes much simpler.
> >
> > -Rasmus
> >
>
> I have
On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf wrote:
> If you stay away from trying to change a 25-year old loosely typed
> language into a strictly typed one, then the RFC becomes much simpler.
>
> -Rasmus
>
I have REPEATEDLY stated that is not the goal. I don't misrepresent what
you say, p
On Wed, Jan 10, 2018 at 9:04 AM, Rasmus Lerdorf wrote:
>
>
> On Wed, Jan 10, 2018 at 5:27 AM, Michael Morris
> wrote:
>>
>> Also, drawing the architectural drawings for a skyscraper is also like
>> only
>> 10% of the work, but it's a damn important 10%.
>>
>
> Wow, that's rather insulting to the
On Wed, Jan 10, 2018 at 10:11 AM, Ryan Jentzsch
wrote:
> I agree with Michael (to a large degree) and I think I see clearly
> Michael's point:
> Under the current system I will NEVER create an RFC (or find someone with
> the Zend engine coding chops to help me) because the RISK vs. REWARD with
>
I agree with Michael (to a large degree) and I think I see clearly
Michael's point:
Under the current system I will NEVER create an RFC (or find someone with
the Zend engine coding chops to help me) because the RISK vs. REWARD with
the current RFC system is too likely to be a colossal waste of ever
On Wed, Jan 10, 2018 at 12:01 PM, Sara Golemon wrote:
> On Thu, Jan 4, 2018 at 8:21 PM, Rasmus Lerdorf wrote:
>> I think you, and many others, commenting here, should start by looking
>> at the engine implementation. Any successful RFC needs to have a strong
>> implementation behind it, or at the
On Thu, Jan 4, 2018 at 8:21 PM, Rasmus Lerdorf wrote:
> I think you, and many others, commenting here, should start by looking
> at the engine implementation. Any successful RFC needs to have a strong
> implementation behind it, or at the very least a very detailed description of
> how the impleme
On 10.01.2018 at 17:22, Rowan Collins wrote:
> On 10 January 2018 at 15:54, Christoph M. Becker wrote:
>
>> On 10.01.2018 at 15:09, Rowan Collins wrote:
>>
>>> I'll also echo a previous request that you apply for a wiki account to
>> make your document more readable; or maybe just put it as a gi
On 10 January 2018 at 15:54, Christoph M. Becker wrote:
> On 10.01.2018 at 15:09, Rowan Collins wrote:
>
> > I'll also echo a previous request that you apply for a wiki account to
> make your document more readable; or maybe just put it as a github gist or
> on your own website, and treat it as m
On 10.01.2018 at 15:09, Rowan Collins wrote:
> I'll also echo a previous request that you apply for a wiki account to make
> your document more readable; or maybe just put it as a github gist or on your
> own website, and treat it as more of a wishlist and discussion piece than a
> spec that co
On Wed, Jan 10, 2018 at 8:10 AM, Sebastian Bergmann wrote:
> Am 10.01.2018 um 16:04 schrieb Rasmus Lerdorf:
>> Wow, that's rather insulting to the amazing work Dmitry, Nikita, Xinchen
>> and others are doing working on the core of PHP.
>
> I agree.
>
> IIRC, last time optional type declarations fo
Am 10.01.2018 um 16:04 schrieb Rasmus Lerdorf:
> Wow, that's rather insulting to the amazing work Dmitry, Nikita, Xinchen
> and others are doing working on the core of PHP.
I agree.
IIRC, last time optional type declarations for attributes were discussed
Dmitry optimized/refactored something in t
On Wed, Jan 10, 2018 at 5:27 AM, Michael Morris wrote:
>
> Also, drawing the architectural drawings for a skyscraper is also like only
> 10% of the work, but it's a damn important 10%.
>
Wow, that's rather insulting to the amazing work Dmitry, Nikita, Xinchen
and others are doing working on the c
On 9 January 2018 23:06:54 GMT+00:00, Michael Morris wrote:
>Before I begin, and without picking on anyone specific, I want to say that
>it is generally unhelpful to say that because I, or others, do not know how
>the engine is set up that it is impossible to make any meaningful
>contributions to
On Wed, Jan 10, 2018 at 12:53 AM, Rasmus Lerdorf wrote:
>
> The difference here is that the end syntax is something like 10% of the
> problem. 90% of it is fitting it into the engine in an efficient manner
> giving that it is affecting the very core of the engine. An RFC on this
> issue that does
On Tue, Jan 9, 2018 at 3:06 PM, Michael Morris wrote:
> Before I begin, and without picking on anyone specific, I want to say that
> it is generally unhelpful to say that because I, or others, do not know how
> the engine is set up that it is impossible to make any meaningful
> contributions to t
Before I begin, and without picking on anyone specific, I want to say that
it is generally unhelpful to say that because I, or others, do not know how
the engine is set up that it is impossible to make any meaningful
contributions to the list or on this issue specifically. My clients don't
underst
On 05/01/2018 09:50, Lester Caine wrote:
'Simply' adding a crude type check with it's overheads does not remove the
validation requirements which still need to be handled much of the time.
Yes, I'd love to be able to define custom types like "integer in the
range 0 to 100" or whatever.
But
On 03/01/2018 23:19, Michael Morris wrote:
I'm not familiar with the Zend Engine as I probably should be. I bring the
perspective of an end user. From what you've posted am I correct in stating
that PHP Type Hints / scalar Type Declarations are in truth syntactic sugar
for asserting the type chec
On 05.01.2018 at 15:33, Andreas Hennings wrote:
> On 5 January 2018 at 11:35, Dan Ackroyd wrote:>
>> The internals of the PHP engine is C, and zvals are structs not
>> classes, and so there is no interface. In userland classes are also
>> zvals.
>> http://www.phpinternalsbook.com/php7/internal_
On 5 January 2018 at 11:35, Dan Ackroyd wrote:
> On 5 January 2018 at 02:01, Michael Morris wrote:
>>
>> what if the underlying zval wasn’t a zval but a separate
>> class specific to the data type but implementing the same interface as
>> zval?
>
> I believe the only sensible answer to that is 'm
On 5 January 2018 at 02:01, Michael Morris wrote:
>
> what if the underlying zval wasn’t a zval but a separate
> class specific to the data type but implementing the same interface as
> zval?
I believe the only sensible answer to that is 'mu', as that question
is based on misunderstanding.
The i
On 05/01/18 01:21, Rasmus Lerdorf wrote:
> The reason we don’t have typed properties/variables is that it would require
> adding type checks on almost every access to the underlying zval. That is a
> huge perf hit compared to only doing it on method/function egress points as
> we do now.
I thin
On Thu, Jan 4, 2018 at 7:21 PM Rasmus Lerdorf wrote:
>
> > On Jan 4, 2018, at 13:09, Andreas Hennings wrote:
> >
> > A system where all variables are type-locked could in fact be faster
> > than a system with dynamically typed variables.
> > Depends on the implementation, of course. I imagine it
> On Jan 4, 2018, at 13:09, Andreas Hennings wrote:
>
> A system where all variables are type-locked could in fact be faster
> than a system with dynamically typed variables.
> Depends on the implementation, of course. I imagine it would be a lot
> of work to get there.
I think you, and many ot
On 3 January 2018 at 21:26, Rowan Collins wrote:
> Hi Michael,
>
> On 02/01/2018 10:35, Michael Morris wrote:
>>
>> I would like to propose a clean way to add some strong typing to PHP in a
>> manner that is almost fully backward compatible (there is a behavior
>> change
>> with PHP 7 type declara
2018-01-04 3:37 GMT+01:00 Michael Morris :
> Second Draft based on the feedback upstream.
>
> Target version: PHP 8.
>
> This is a proposal to strengthen the dynamic type checking of PHP during
> development.
>
> Note - this is not a proposal to change PHP to a statically typed language
> or to re
Second Draft based on the feedback upstream.
Target version: PHP 8.
This is a proposal to strengthen the dynamic type checking of PHP during
development.
Note - this is not a proposal to change PHP to a statically typed language
or to remove PHP's current loose typing rules. PHP is a weakly type
On Wed, Jan 3, 2018 at 3:26 PM, Rowan Collins
wrote:
> Hi Michael,
>
> On 02/01/2018 10:35, Michael Morris wrote:
>
>> I would like to propose a clean way to add some strong typing to PHP in a
>> manner that is almost fully backward compatible (there is a behavior
>> change
>> with PHP 7 type dec
Hi Michael,
On 02/01/2018 10:35, Michael Morris wrote:
I would like to propose a clean way to add some strong typing to PHP in a
manner that is almost fully backward compatible (there is a behavior change
with PHP 7 type declarations). As I don't have access to the add RFC's to
the wiki I'll pla
On Wed, Jan 3, 2018 at 12:21 PM, Andreas Hennings
wrote:
> Another idea I have when reading this proposal is "implicit" typing
> based on the initialization.
>
> E.g.
>
> $x = 5;
> $x = 'hello'; // -> Error: $x was initialized as integer, and cannot
> hold a string.
>
>
No, no no. I don't think
On Wed, Jan 3, 2018 at 12:10 PM, Andreas Hennings
wrote:
> This proposal contains some interesting ideas, which I see as separate:
> 1. A syntax to declare the type of local variables.
> 2. A syntax to declare the type of object properties.
> 3. Preventing local variables, object properties and p
Another idea I have when reading this proposal is "implicit" typing
based on the initialization.
E.g.
$x = 5;
$x = 'hello'; // -> Error: $x was initialized as integer, and cannot
hold a string.
or
$x = $a + $b;
$x = 'hello'; // -> Error: $x was initialized as number (int|float),
and cannot ho
This proposal contains some interesting ideas, which I see as separate:
1. A syntax to declare the type of local variables.
2. A syntax to declare the type of object properties.
3. Preventing local variables, object properties and parameters to
change their type after initialization/declaration.
F
On Wed, Jan 3, 2018 at 3:50 AM, Niklas Keller wrote:
> Hey Michael,
>
> I don't think the BC break is acceptable. You argue that scalar type
> declarations are relatively new, but in fact they're already years old now.
> They're used in most PHP 7+ packages. Even if changing types might be
> disc
Hey Michael,
I don't think the BC break is acceptable. You argue that scalar type
declarations are relatively new, but in fact they're already years old now.
They're used in most PHP 7+ packages. Even if changing types might be
discouraged, it still happens a lot.
Regards, Niklas
On Tue, Jan 2, 2018 at 7:08 AM, Hidde Boomsma wrote:
> Dear Michael,
>
> Are you aware of this RFC: https://wiki.php.net/rfc/typed-properties
>
>
I was not aware of it. What I propose has a much wider scope, but the fact
there was slowdown on the last implementation try is concerning.
43 matches
Mail list logo
