On Fri, May 3, 2013 at 2:08 AM, Sherif Ramadan wrote:
> It's already possible to do so now without any modifications to the core:
It was already possible to declare arrays, but the new, shorter array
syntax still brings a smile to my face :) Few new language features
actually add things that were
On Fri, May 3, 2013 at 1:25 AM, Adam Jon Richardson wrote:
>
>
> Currently, sure. Limiting this functionality to the return statement
> seems doable.
>
It's already possible to do so now without any modifications to the core:
function myFunc() {
$result = array(null, null);
if ($failureCa
On Thu, May 2, 2013 at 11:44 PM, Sherif Ramadan wrote:
>
> Just to clarify, PHP doesn't offer two separate approaches of handling
> errors. We need to first distinguish between what is meant by a the terms
> "Errors" and "Exceptions" so that we don't throw around ambigous claims
> here. PHP has an
On Thu, May 2, 2013 at 6:00 PM, Adam Jon Richardson wrote:
> PHP currently has two separate approaches to handling errors:
> - Errors
> - Exceptions
>
> Both have their issues.
>
>
Just to clarify, PHP doesn't offer two separate approaches of handling
errors. We need to first distinguish between w
On Thu, May 2, 2013 at 6:46 PM, Stuart Langley wrote:
> So is the feature you're describing is tuples and a use case of that feature
> is an easier way to do error handling?
No.
Tuples are an implementation detail specific to how Python allows one
to conveniently return multiple values. I merely
>
> did I miss something of your new language feature or is it really
>
> just a shorthand for “new PropertyReference($user, 'name');”?
>
>
It is and it isn't.
Yes, that is effectively what it does, but that's not really the point.
The idea is to have a literal way to refer to an object property
Your solution is flawed, it would not allow autoloading a function that has the
same
(namespaced) name as a builtin.
Example:
// autoloadable function
namespace foo {
// make arg order consistent
function array_filter($callback, $input) {
return \array_filter(
So is the feature you're describing is tuples and a use case of that
feature is an easier way to do error handling?
On Fri, May 3, 2013 at 8:00 AM, Adam Jon Richardson wrote:
> PHP currently has two separate approaches to handling errors:
> - Errors
> - Exceptions
>
> Both have their issues.
>
>
2013/5/2 Igor Wiedler
> No, I want to keep autoloading out of this proposal. It is way beyond the
> scope of the namespacing issue and also incredibly complex.
>
> That said, this RFC may be useful for implementing autoloading in the
> future, as it addresses one of the things that makes function
PHP currently has two separate approaches to handling errors:
- Errors
- Exceptions
Both have their issues.
Using and responding to errors requires that the returned value (if
there is one) perform double duty as both a potential valid response
AND, in the case of error, a flag that something wen
No, I want to keep autoloading out of this proposal. It is way beyond the scope
of the namespacing issue and also incredibly complex.
That said, this RFC may be useful for implementing autoloading in the future,
as it addresses one of the things that makes function autoloading hard, which
is be
Hi,
Are you going to cover autoloading of functions too?
Regards,
Sebastian
2013/5/2 Igor Wiedler
> Hi internals,
>
> Since there's been no major objection to this proposed RFC, I will go
> ahead and create it on the wiki. I will amend it to address some of the
> points that were discussed so
> That's what I've been trying to say - some people seem to think we can
just use strings for everything and static analysis will somehow walk
execution paths and use intelligent algorithms (or dark sorcery) to
determine which strings are what... That's not happening, not even in
leading IDEs, not
Hi internals,
Since there's been no major objection to this proposed RFC, I will go ahead and
create it on the wiki. I will amend it to address some of the points that were
discussed so far.
Thanks,
Igor
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.
Oh, here's a thought: let's just throw more annotations at it?
$config = /** @ref AppConfiguration */ array(
'services' => /** @ref ServiceContainer */ array(
/** @ref PDO */ array(
'username' => 'foo',
'password' => 'bar',
)
),
);
This would work
>
> "authors[0].personalDetails[firstName]"
>
>
>> which translates to
>
>
>> ->getAuthors()[0]->getPersonalDetails()['firstName']
>
>
It's indirection via strings.
This particular example isn't great for what I'm proposing, because you're
not accessing a property - using an array-index, you get a
>
> As you described, IDEs struggle when it comes to Refactoring support for
> PHP code and they always will without additional static information like
> @var and @property annotations. And even with the static information in
> addition, the IDEs still struggle and refactoring PHP code is quite pai
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
Hi Rasmus
I agree, a high level language should facilitate the development and it
should do as much as possible for the user. As you described, IDEs struggle
when it comes to Refactoring support for PHP code and they always will
without additional static information like @var and @property anno
19 matches
Mail list logo
