Re: [PHP-DEV] PHP7 and types
+1 It will be useful for autocomplete in IDE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
Am 11.07.2015 um 19:53 schrieb S.A.N: > It will be useful for autocomplete in IDE That argument is bogus since proper IDEs (PhpStorm, fex.) leverage docblock annotations for that already. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
On Sat, Jul 11, 2015 at 12:41 PM, Sebastian Bergmann
wrote:
> Am 11.07.2015 um 19:53 schrieb S.A.N:
> > It will be useful for autocomplete in IDE
>
> That argument is bogus since proper IDEs (PhpStorm, fex.) leverage
> docblock annotations for that already.
>
> Agreed. I don't know any IDE meant for PHP that doesn't respect docblock
declarations.
I think the benefit comes more in being able to make a property public, and
still have control over its type. Currently the only way to do it is to
have your property be private and use public get/set method(s) instead. IE:
class foo {
public int $bar;
}
-- vs. --
class foo {
private $bar = 0;
public function getBar() : int {
return $this->bar;
}
public function setBar(int $val) {
$this->bar = $val;
}
}
Granted its still far less verbose for scalar types than in the current 5.x
world where you have to have your own type checks as well.
--
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] PHP7 and types
Hi, 2015-07-11 15:41 GMT-03:00 Sebastian Bergmann : > Am 11.07.2015 um 19:53 schrieb S.A.N: >> It will be useful for autocomplete in IDE > > That argument is bogus since proper IDEs (PhpStorm, fex.) leverage > docblock annotations for that already. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Not completely bogus. At least with typed properties you won't need to actually write the docblocks to have the IDE "hints". It's a minor win for IDE users too. Marcio -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
Hi! > Not completely bogus. At least with typed properties you won't need to > actually write the docblocks to have the IDE "hints". It's a minor win > for IDE users too. I don't see "not needing to write docblocks" as a win, quite the contrary. In fact, in a number of projects I worked with, code without proper documentation (including docblocks) simply wasn't accepted into the repository. While I don't think this needs to be mandatory, I also don't see major difference - so you have to write type instead of docblock, you still have to write something. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
On 12/07/15 09:10, Stanislav Malyshev wrote: >> Not completely bogus. At least with typed properties you won't need to >> > actually write the docblocks to have the IDE "hints". It's a minor win >> > for IDE users too. > I don't see "not needing to write docblocks" as a win, quite the > contrary. In fact, in a number of projects I worked with, code without > proper documentation (including docblocks) simply wasn't accepted into > the repository. > > While I don't think this needs to be mandatory, I also don't see major > difference - so you have to write type instead of docblock, you still > have to write something. In addition, the docblock contains a lot more material than just a few types, so one still needs to have one. The main problem with adding types is they become part of the code, while a docblock can simple be stripped. As a 'minor win for IDE users' it is also questionable since the every IDE will need to be re-written to support both methods of working. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
Stas, 2015-07-12 5:10 GMT-03:00 Stanislav Malyshev : > Hi! > >> Not completely bogus. At least with typed properties you won't need to >> actually write the docblocks to have the IDE "hints". It's a minor win >> for IDE users too. > > I don't see "not needing to write docblocks" as a win, quite the > contrary. Of course it's a win. Or do you like to write docblocks for every single class property or method (even when the member is obvious) just to have a "@var" so your IDE can work? Not to mention you won't get any runtime/compile time check or optimization from docblock tags, that's the main point of having typed properties. > In fact, in a number of projects I worked with, code without > proper documentation (including docblocks) simply wasn't accepted into > the repository. > If you are using the term "proper documentation" to justify docblocks everywhere even if they contain just a "/** @var string */", it's a sign we've been using comments against us all this time (even if we called it "doc comments"). But thankfully we are moving PHP to another direction. Do you remember the "return types" voting results? https://wiki.php.net/rfc/return_types#vote. That's because "function() : type" is self documented and much more maintainable than than a possibly sloppy "/** @return type */" on top of every method on a codebase. > While I don't think this needs to be mandatory, I also don't see major > difference - so you have to write type instead of docblock, you still > have to write something. > But with the benefits already cited above. Docblocks should not be a place for type information anymore, this was a workaround and we've been slowly replacing it with a better solution (opt in types). Property types seems to be the next logical step after adding return types and scalar types. > -- > Stas Malyshev > smalys...@gmail.com Is there any technical reason for you to be against typed properties? IMMO, just arguing against opt in type declarations (evolving the php type system) in favor of docblocks (stagnation) seems to be utterly unproductive as we already know the tendencies from previous votings. Marcio -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
Lester, 2015-07-12 5:27 GMT-03:00 Lester Caine : > On 12/07/15 09:10, Stanislav Malyshev wrote: >>> Not completely bogus. At least with typed properties you won't need to >>> > actually write the docblocks to have the IDE "hints". It's a minor win >>> > for IDE users too. >> I don't see "not needing to write docblocks" as a win, quite the >> contrary. In fact, in a number of projects I worked with, code without >> proper documentation (including docblocks) simply wasn't accepted into >> the repository. >> >> While I don't think this needs to be mandatory, I also don't see major >> difference - so you have to write type instead of docblock, you still >> have to write something. > > In addition, the docblock contains a lot more material than just a few > types, so one still needs to have one. The main problem with adding > types is they become part of the code, while a docblock can simple be > stripped. > Please refer to reply given to Stas. > As a 'minor win for IDE users' it is also questionable since the every > IDE will need to be re-written to support both methods of working. > You meant "updated" not "re-written". IDEs that want to stay relevant to the community will always be updated, and hæck, it's much easier to analyze real language syntax as opposed to uncertain user space DSLs inside comments. IDE maintainers won't complain about that, for sure. > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Marcio -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
Of course the main target - check types, but not all use the check types, but almost everyone uses Ide, so I said, it is actual and useful. I do not see contradictions, everyone who wants to write PHP 5 code, need use DocBlock @var. I hope that in the PHP 7.x, DocBlock is only for documentation of code, all declared types be in the language and not in the comments I would like it to be implemented, not beginning of unnecessary disputes. Thank. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
On 07/12/2015 11:16 AM, Marcio Almada wrote:
Stas,
2015-07-12 5:10 GMT-03:00 Stanislav Malyshev :
Hi!
Not completely bogus. At least with typed properties you won't need to
actually write the docblocks to have the IDE "hints". It's a minor win
for IDE users too.
I don't see "not needing to write docblocks" as a win, quite the
contrary.
Of course it's a win. Or do you like to write docblocks for every
single class property or method (even when the member is obvious) just
to have a "@var" so your IDE can work?
Not to mention you won't get any runtime/compile time check or
optimization from docblock tags, that's the main point of having typed
properties.
In fact, in a number of projects I worked with, code without
proper documentation (including docblocks) simply wasn't accepted into
the repository.
If you are using the term "proper documentation" to justify docblocks
everywhere even if they contain just a "/** @var string */", it's a
sign we've been using comments against us all this time (even if we
called it "doc comments").
But thankfully we are moving PHP to another direction. Do you remember
the "return types" voting results?
https://wiki.php.net/rfc/return_types#vote. That's because "function()
: type" is self documented and much more maintainable than than a
possibly sloppy "/** @return type */" on top of every method on a
codebase.
While I don't think this needs to be mandatory, I also don't see major
difference - so you have to write type instead of docblock, you still
have to write something.
But with the benefits already cited above. Docblocks should not be a
place for type information anymore, this was a workaround and we've
been slowly replacing it with a better solution (opt in types).
Property types seems to be the next logical step after adding return
types and scalar types.
I don't know why we're even talking about IDEs here. IDE
auto-completion isn't the point, anymore than it was the point for
scalar type hints or return type hints. It's about the language doing
type checking for you and static analysis, so that the language can find
bugs for you. Eg:
class Foo {
public Bar $bar;
}
$f = new Foo();
$f->bar = new Baz(); // This line is clearly wrong and the compiler can
check it for you.
That's what the benefit would be. Easier IDE auto-completion is a nice
extra, but not the main goal.
+1 from me in 7.1.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
What about arrays? How do I declare Foo[] ?
http://ocramius.github.io/extremely-defensive-php/#/69
2015-07-12 16:37 GMT-03:00 Larry Garfield :
> On 07/12/2015 11:16 AM, Marcio Almada wrote:
>
>> Stas,
>>
>> 2015-07-12 5:10 GMT-03:00 Stanislav Malyshev :
>>
>>> Hi!
>>>
>>> Not completely bogus. At least with typed properties you won't need to
actually write the docblocks to have the IDE "hints". It's a minor win
for IDE users too.
>>> I don't see "not needing to write docblocks" as a win, quite the
>>> contrary.
>>>
>> Of course it's a win. Or do you like to write docblocks for every
>> single class property or method (even when the member is obvious) just
>> to have a "@var" so your IDE can work?
>>
>> Not to mention you won't get any runtime/compile time check or
>> optimization from docblock tags, that's the main point of having typed
>> properties.
>>
>> In fact, in a number of projects I worked with, code without
>>> proper documentation (including docblocks) simply wasn't accepted into
>>> the repository.
>>>
>>> If you are using the term "proper documentation" to justify docblocks
>> everywhere even if they contain just a "/** @var string */", it's a
>> sign we've been using comments against us all this time (even if we
>> called it "doc comments").
>>
>> But thankfully we are moving PHP to another direction. Do you remember
>> the "return types" voting results?
>> https://wiki.php.net/rfc/return_types#vote. That's because "function()
>> : type" is self documented and much more maintainable than than a
>> possibly sloppy "/** @return type */" on top of every method on a
>> codebase.
>>
>> While I don't think this needs to be mandatory, I also don't see major
>>> difference - so you have to write type instead of docblock, you still
>>> have to write something.
>>>
>>> But with the benefits already cited above. Docblocks should not be a
>> place for type information anymore, this was a workaround and we've
>> been slowly replacing it with a better solution (opt in types).
>> Property types seems to be the next logical step after adding return
>> types and scalar types.
>>
>
> I don't know why we're even talking about IDEs here. IDE auto-completion
> isn't the point, anymore than it was the point for scalar type hints or
> return type hints. It's about the language doing type checking for you and
> static analysis, so that the language can find bugs for you. Eg:
>
> class Foo {
> public Bar $bar;
> }
>
> $f = new Foo();
> $f->bar = new Baz(); // This line is clearly wrong and the compiler can
> check it for you.
>
> That's what the benefit would be. Easier IDE auto-completion is a nice
> extra, but not the main goal.
>
> +1 from me in 7.1.
>
> --Larry Garfield
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] PHP7 and types
On Sun, Jul 12, 2015 at 4:51 PM, Alan Willms wrote:
> What about arrays? How do I declare Foo[] ?
>
> http://ocramius.github.io/extremely-defensive-php/#/69
>
> 2015-07-12 16:37 GMT-03:00 Larry Garfield :
>
> > On 07/12/2015 11:16 AM, Marcio Almada wrote:
> >
> >> Stas,
> >>
> >> 2015-07-12 5:10 GMT-03:00 Stanislav Malyshev :
> >>
> >>> Hi!
> >>>
> >>> Not completely bogus. At least with typed properties you won't need to
> actually write the docblocks to have the IDE "hints". It's a minor win
> for IDE users too.
>
> >>> I don't see "not needing to write docblocks" as a win, quite the
> >>> contrary.
> >>>
> >> Of course it's a win. Or do you like to write docblocks for every
> >> single class property or method (even when the member is obvious) just
> >> to have a "@var" so your IDE can work?
> >>
> >> Not to mention you won't get any runtime/compile time check or
> >> optimization from docblock tags, that's the main point of having typed
> >> properties.
> >>
> >> In fact, in a number of projects I worked with, code without
> >>> proper documentation (including docblocks) simply wasn't accepted into
> >>> the repository.
> >>>
> >>> If you are using the term "proper documentation" to justify docblocks
> >> everywhere even if they contain just a "/** @var string */", it's a
> >> sign we've been using comments against us all this time (even if we
> >> called it "doc comments").
> >>
> >> But thankfully we are moving PHP to another direction. Do you remember
> >> the "return types" voting results?
> >> https://wiki.php.net/rfc/return_types#vote. That's because "function()
> >> : type" is self documented and much more maintainable than than a
> >> possibly sloppy "/** @return type */" on top of every method on a
> >> codebase.
> >>
> >> While I don't think this needs to be mandatory, I also don't see major
> >>> difference - so you have to write type instead of docblock, you still
> >>> have to write something.
> >>>
> >>> But with the benefits already cited above. Docblocks should not be a
> >> place for type information anymore, this was a workaround and we've
> >> been slowly replacing it with a better solution (opt in types).
> >> Property types seems to be the next logical step after adding return
> >> types and scalar types.
> >>
> >
> > I don't know why we're even talking about IDEs here. IDE auto-completion
> > isn't the point, anymore than it was the point for scalar type hints or
> > return type hints. It's about the language doing type checking for you
> and
> > static analysis, so that the language can find bugs for you. Eg:
> >
> > class Foo {
> > public Bar $bar;
> > }
> >
> > $f = new Foo();
> > $f->bar = new Baz(); // This line is clearly wrong and the compiler can
> > check it for you.
> >
> > That's what the benefit would be. Easier IDE auto-completion is a nice
> > extra, but not the main goal.
> >
> > +1 from me in 7.1.
> >
> > --Larry Garfield
> >
> >
>
> Since there is not typed arrays in PHP I would say you declare it as an
array. Though in this case I would suggest a collection class that
implements iterator and countable and type hint for this collection and
make its job be to be a container of a specific type.
class WagonCollection implements Iterator, Countable {
private array $wagons = [];
private int $index = 0;
public function addWagon(Wagon $w) {
$this->wagons[] = $w;
}
// implementations for Iterator and Countable
}
However, I could see an argument being made for typed arrays, but that is
not the point of my suggested RFC and a separate RFC would need to be
created for that.
PS. Please bottom post instead of top posting. mailing list rules
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
Re: [PHP-DEV] PHP7 and types
On 07/12/2015 12:37 PM, Larry Garfield wrote:
> I don't know why we're even talking about IDEs here. IDE
> auto-completion isn't the point, anymore than it was the point for
> scalar type hints or return type hints. It's about the language doing
> type checking for you and static analysis, so that the language can find
> bugs for you. Eg:
>
> class Foo {
> public Bar $bar;
> }
>
> $f = new Foo();
> $f->bar = new Baz(); // This line is clearly wrong and the compiler can
> check it for you.
>
> That's what the benefit would be. Easier IDE auto-completion is a nice
> extra, but not the main goal.
>
> +1 from me in 7.1.
I am not sure static analysis is a great argument for it either. A
static analyzer can read the docblock really easily too since it is part
of the AST node for the property. In fact I just wrote one. Feeding it
your code example:
% cat -n test.php
1 bar = new Baz();
% ./phan test.php
Files scanned: 1
Time: 0.11s
Classes:2
Methods:0
Functions: 0
Closures: 0
Traits: 0
Conditionals: 0
Issues found: 1
test.php:9 TypeError property is declared to be bar but was assigned Baz
Plus, without union types, doc-comment typing is much more convenient
when it comes to running a static analyzer on real-world code since
limiting everything to a single type is often impractical. If you grep
through existing code in the wirld, you will find a ton of Bar|bool,
Bar|Baz|bool|null, etc.
I'm not against the idea, but it is quite different from the existing
type checking since this is a type check that would need to be done on
every assignment for it to make any sense at all and not just at call
boundaries like the existing ones. It may not be feasible to do in an
efficient manner. A static analyzer can get away with catching 95%. A
core language feature can't. Having to do these the type check on
assignment will likely require some significant changes to the engine.
-Rasmus
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] PHP7 and types
On 07/12/2015 05:12 PM, Rasmus Lerdorf wrote:
> On 07/12/2015 12:37 PM, Larry Garfield wrote:
>> I don't know why we're even talking about IDEs here. IDE
>> auto-completion isn't the point, anymore than it was the point for
>> scalar type hints or return type hints. It's about the language doing
>> type checking for you and static analysis, so that the language can find
>> bugs for you. Eg:
>>
>> class Foo {
>> public Bar $bar;
>> }
>>
>> $f = new Foo();
>> $f->bar = new Baz(); // This line is clearly wrong and the compiler can
>> check it for you
By the way, I forgot to add that you can't possibly say that this line
is clearly wrong without knowing what Baz is and you didn't define Baz.
So the only thing clearly wrong with that line is that the Baz class
doesn't exist which has nothing to do with the property type.
If you have:
class Bar { }
class Baz extends Bar { }
Then that line is perfectly valid since Baz is an instance of Bar which
would meet the type criteria provided. And this also shows that the
compiler can't actually check that necessarily. We don't know whether
Baz is an instance of Bar at compile-time.
-Rasmus
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] PHP7 and types
I am in favor of typed properties but it's actually a fairly low priority for me. There are also several questions that need answering, such as what happens when you type a property with type `Foo` but don't assign it a value in the constructor. Also, is the check bypassed with inheritance when you don't call parent constructor? Given that it's non-trivial (but not necessarily *very* complex) and only a low priority I haven't taken the time to make a proposal. I am instead focusing on union, sum and enum types. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
Hi! > Of course it's a win. Or do you like to write docblocks for every > single class property or method (even when the member is obvious) just Yes. What is obvious to you today may not be at all obvious to your coworker two years later. > to have a "@var" so your IDE can work? No, not "just" my IDE can work. IDE is just the side effect. Proper documentation does much more than that. > Not to mention you won't get any runtime/compile time check or > optimization from docblock tags, that's the main point of having typed > properties. I don't see how "compile time check" is even possible, given that PHP has no "compile time". As for runtime check, it'd be mostly useless for me - I very rarely have seen bugs that would be caught by such checks. > If you are using the term "proper documentation" to justify docblocks > everywhere even if they contain just a "/** @var string */", it's a > sign we've been using comments against us all this time (even if we > called it "doc comments"). I'm not sure what "using comments against us" even means. I also do not share a superstition that comments are somehow evil or that making comments machine-readable and benefiting from it is somehow wrong. > But thankfully we are moving PHP to another direction. Do you remember If you refer to inserting static typing into random places in service of a cargo cult notion that "more type definitions is always better, because types fix bugs" - no, I do not think it is a correct direction. > https://wiki.php.net/rfc/return_types#vote. That's because "function() > : type" is self documented and much more maintainable than than a > possibly sloppy "/** @return type */" on top of every method on a > codebase. It's not more maintainable and it is much less flexible or useful. PHP has very nice and flexible capabilities that allow write very nice code which can return different values in different circumstances. By trying to shove it into a single type you are ignoring these capabilities - again because of a superstition that somehow there are myriads of bugs caused by accidentally returning values of wrong types that are being fixed by that. > But with the benefits already cited above. Docblocks should not be a > place for type information anymore, this was a workaround and we've Why? There's no reason why they can't be except for a unsupported statement "it is bad because it is bad". -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
On Jul 13, 2015 2:08 PM, "Stanislav Malyshev" wrote: > > Hi! > > > Of course it's a win. Or do you like to write docblocks for every > > single class property or method (even when the member is obvious) just > > Yes. What is obvious to you today may not be at all obvious to your > coworker two years later. > > > to have a "@var" so your IDE can work? > > No, not "just" my IDE can work. IDE is just the side effect. Proper > documentation does much more than that. It seems to go off topic. Docblocks are only slightly related to this thread. The same could be said about annotation (which are widely used too). I do like the idea to be allowed to do such thing. It is indeed not a high priority but still nice to have. Cheers, Pierre
RE: [PHP-DEV] PHP7 and types
> De : Ryan Pallas [mailto:derokor...@gmail.com]
>
> With all the new typing and strict mode in PHP7, I'm wondering if there is
> any planned support for typing of properties in a future version. IE
> something like:
>
> class Foo {}
> class Bar {
>public Foo $foo;
>
>public function __construct(Foo $foo) {
>$this->foo = $foo;
>}
> }
>
> This seems really useful to me. If its not something that was considered
> before I can try to write up an RFC for this, however I'm not sure if this
> was already considered and denied. Any feedback would be greatly
> appreciated.
Hi,
I proposed this as an addition to scalar type hinting when we were discussing
the STH RFC some months ago. Zeev and Dmitry, like Rasmus today, thought it was
probably not possible to implement it without huge changes to the engine. After
thinking more about it, I think they're absolutely right. What you want to
implement is not an additional compile-time check, it's attaching type hints to
object properties. That's a runtime check *and* a possible conversion *each*
time a property is assigned. The problem is that the current engine makes it
impossible to trap every zval assignments, let alone the question of
performance. If you look at parameter type hints, argument types are checked
only once, when they are received by the function. Then, in the function body,
you can assign any value/type to every received argument, that's impossible to
check.
Rewriting your example to show the feature has nothing to do with compile-time
checks :
public function __construct(Foo $foo) {
manage($foo);
$this->foo=$foo; /* Compile-time OK, Runtime error */
}
/* In another file, somewhere... */
public function manage(&$obj)
{
...
$obj='bar';
}
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
Maybe implement getter/setter as ECMAScript 6?
class Person
{
get name ():string { return $this._name }
set name (string $value) { $this._name = $value }
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
2015-07-14 11:05 GMT+02:00 S.A.N :
> Maybe implement getter/setter as ECMAScript 6?
>
> class Person
> {
> get name ():string { return $this._name }
> set name (string $value) { $this._name = $value }
> }
Which was rejected some time ago. (34 vs 22 in favor):
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
Maybe it's time to reevaluate the proposal and see if a new
implementation could gather
more support.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
Yes, I think the compiler could compile the expression
class Bar
{
public Foo $foo; // That is shorthand getter/setter...
}
to
class Bar
{
get foo():Foo {return $this->_foo};
set foo(Foo $obj) {$this->_foo = $obj};
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types
On Tue, Jul 14, 2015 at 3:51 AM, Sebastian B.-Hagensen
wrote:
> 2015-07-14 11:05 GMT+02:00 S.A.N :
>> Maybe implement getter/setter as ECMAScript 6?
>>
>> class Person
>> {
>> get name ():string { return $this._name }
>> set name (string $value) { $this._name = $value }
>> }
>
> Which was rejected some time ago. (34 vs 22 in favor):
> https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
>
> Maybe it's time to reevaluate the proposal and see if a new
> implementation could gather
> more support.
I personally voted no on that proposal because of the proposed syntax
and semantics. However I do like the idea of getters and setters and
definitely prefer a Dart-like syntax (which is where ECMAScript
basically got its syntax).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types - and alternatives to annotation
On 13/07/15 08:49, Pierre Joye wrote: >> No, not "just" my IDE can work. IDE is just the side effect. Proper >> > documentation does much more than that. > It seems to go off topic. Docblocks are only slightly related to this > thread. The same could be said about annotation (which are widely used too). Coming from a background of 'traditional' php design, all of my code and the libraries I use are documented via phpdoc style annotation which the IDE picks up, and phpdocumentor1 produced a good API description. This was also a GOOD basis to tidy up the various changes through PHP5.x Today much of the infrastructure to make that work is broken and http://lsces.org.uk/wiki/bitweaver+documentation is a starting point at getting the material all up to date. The original documentation had a few errors on the log file, but http://lsces.org.uk/bwdocs2/index.html is the version I've been working on and is listing 3300 errors in the documentation! The next step is to work out how to address those errors, but once again that is unproductive work so perhaps fixing the problems with the older V1 documenter may be a better use of time? The rules phpdocumenter2 follow seem far adrift from the original 'standard'. So it WOULD be nice if there was an approved standard rather than these seeming to be subject to different interpretation all the time. This before addressing the problems of PHP7 migration ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types - and alternatives to annotation
Hi Lester, On 13 July 2015 at 11:36, Lester Caine wrote: > On 13/07/15 08:49, Pierre Joye wrote: > >> No, not "just" my IDE can work. IDE is just the side effect. Proper > >> > documentation does much more than that. > > It seems to go off topic. Docblocks are only slightly related to this > > thread. The same could be said about annotation (which are widely used > too). > > Coming from a background of 'traditional' php design, all of my code and > the libraries I use are documented via phpdoc style annotation which the > IDE picks up, and phpdocumentor1 produced a good API description. This > was also a GOOD basis to tidy up the various changes through PHP5.x > > Today much of the infrastructure to make that work is broken and > http://lsces.org.uk/wiki/bitweaver+documentation is a starting point at > getting the material all up to date. The original documentation had a > few errors on the log file, but http://lsces.org.uk/bwdocs2/index.html > is the version I've been working on and is listing 3300 errors in the > documentation! The next step is to work out how to address those errors, > but once again that is unproductive work so perhaps fixing the problems > with the older V1 documenter may be a better use of time? The rules > phpdocumenter2 follow seem far adrift from the original 'standard'. So > it WOULD be nice if there was an approved standard rather than these > seeming to be subject to different interpretation all the time. > > This before addressing the problems of PHP7 migration ... > > Please refer to https://github.com/php-fig/fig-standards/pull/169 Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] PHP7 and types - and alternatives to annotation
On 13/07/15 11:51, Marco Pivetta wrote: > Please refer to https://github.com/php-fig/fig-standards/pull/169 This just adds another level of complication. FIG is not part of the core PHP standards, and some of their choices simply don't fit with legacy code. I suspect that some of the problems I'm currently hitting are because the coding standards I follow do not match FIG ... and I have no intentions of adding that to that todo list ... but I've paid work to get on with currently before I can get back to documentation. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types - and alternatives to annotation
On 13 July 2015 at 12:20, Lester Caine wrote: > On 13/07/15 11:51, Marco Pivetta wrote: > > Please refer to https://github.com/php-fig/fig-standards/pull/169 > > This just adds another level of complication. FIG is not part of the > core PHP standards, and some of their choices simply don't fit with > legacy code. I suspect that some of the problems I'm currently hitting > are because the coding standards I follow do not match FIG ... and I > have no intentions of adding that to that todo list ... but I've paid > work to get on with currently before I can get back to documentation. > > So put a strict no-upgrade-if-without-budget policy on whatever you're working on then? phpdocumentor is also not an "official" tool: it's built by volunteers and outside the boundaries of php-src. It's actually the PhpDocumentor folks (and Mike van Riel in first place) pushing forward PSR-5: there's nothing more "official" than that right now. That's the current standardization path. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] PHP7 and types - and alternatives to annotation
On 7/13/2015 4:36 AM, Lester Caine wrote: Coming from a background of 'traditional' php design, all of my code and the libraries I use are documented via phpdoc style annotation which the IDE picks up, and phpdocumentor1 produced a good API description. This was also a GOOD basis to tidy up the various changes through PHP5.x Today much of the infrastructure to make that work is broken and http://lsces.org.uk/wiki/bitweaver+documentation is a starting point at getting the material all up to date. The original documentation had a few errors on the log file, buthttp://lsces.org.uk/bwdocs2/index.html is the version I've been working on and is listing 3300 errors in the documentation! The next step is to work out how to address those errors, Phpdocumentor2? I don't remember the details, but a single patch cleaned up a ton of errors for me. I googled the error message and found a github? pull request or bug report. The best answer is at the bottom of the discussion. As of the last time I loaded it, about 3 months ago, I still had to apply the patch. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types - and alternatives to annotation
On 13/07/15 13:12, Marco Pivetta wrote: > It's actually the PhpDocumentor folks (and Mike van Riel in first place) > pushing forward PSR-5: there's nothing more "official" than that right now. > That's the current standardization path. docblock annotation has been the subject of RFC's as alternatives to other annotation/typing options, and that is the correct platform to carry out that debate rather than on third party tools/standards such as fig and phpdocumentor. It is not only phdocumentor that uses docblock material, the IDE's I use have no problem with the current docblock material and so there has been no need until now to look at why only phpdocumentor2 has a problem with them ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 and types - and alternatives to annotation
On 13 July 2015 at 13:23, Lester Caine wrote: > On 13/07/15 13:12, Marco Pivetta wrote: > > It's actually the PhpDocumentor folks (and Mike van Riel in first place) > > pushing forward PSR-5: there's nothing more "official" than that right > now. > > That's the current standardization path. > > docblock annotation has been the subject of RFC's as alternatives to > other annotation/typing options, and that is the correct platform to > carry out that debate rather than on third party tools/standards such as > fig and phpdocumentor. Yeap, and these RFCs were rejected due to the fact that for the purposes of php-src it's just comments that can be read as strings via Reflection API. > It is not only phdocumentor that uses docblock > material, the IDE's I use have no problem with the current docblock > material and so there has been no need until now to look at why only > phpdocumentor2 has a problem with them ... Most (all?) of those APIs/IDEs/tools are basing their implementation on PHPDocumentor's documentation at http://www.phpdoc.org/docs/latest/index.html, if not directly on PHPDocumentor's components. Not everything in PHP is specified by php-src, nor should be. Actually, pretty much nothing in PHP userland is specified by php-src, and it's probably for the best, since this way you get a choice. In this case you have a simple choice: - not upgrading a stable tool - accepting that there are BC breaks due to the evolution of the ecosystem in the past 10 years, and adapting an old codebase to 10 years of changes Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
