subject:"Re\: \[PHP\-DEV\] property de\-referencing"


 ** **

 ** **

 ** **

 *Von:* Rasmus Schultz [mailto:ras...@mindplay.dk]
 *Gesendet:* Donnerstag, 2. Mai 2013 01:51
 *An:* Robert Stoll
 *Cc:* Etienne Kneuss; Rasmus Lerdorf; Stas Malyshev; PHP internals

 *Betreff:* Re: [PHP-DEV] property de-referencing

 ** **

 PhpStorm has the finest refactoring support you can achieve with the
 limited amount of static information in PHP source-code, plus hopefully a
 whole bunch of @var and @property annotations. With the amount of
 information inherent in PHP source-code, plus the volunteer information
 provided by annotations, it still has to do a lot of guess-work, and you
 still have to look over the proposed changes and manually correct what it
 gets wrong.

 ** **

 I really see annotations in doc-blocks as a symptom of the lack of static
 information in the language - the interpreter doesn't need information like
 property-types or argument-types, but as it turns out, people do, so we
 have to decorate the language with annotations to provide enough
 information for people to comprehend the code.

 ** **

 But that means the annotations can now be out of sync with reality -
 argument-types and property-types change. We discover, there was a useful
 need for this information after all: type checking. So we introduce static
 type-hints. The static information wasn't just useful to humans after all.
 

 ** **

 As for property-types and loads of other things, we annotate everything,
 in part because the annotations are useful to people, in part to facilitate
 proper IDE support and other forms of machine-analysis. Property type-hints
 may not be necessary to run the language, but they are necessary for people
 and external static analysis.

 ** **

 PHP is not a machine-friendly language - like most high-level languages,
 it was designed with people in mind, which is natural, because people are
 the ones who use programming languages. The machines would be satisfied
 with machine instructions, if you could memorize them all and keep track of
 that in your head.

 ** **

 To write a simple web-application, I'm betting you would need a
 QUADRILLION annotations to do that.

 ** **

 Better to take all that static information and make it available to the
 machine, so that we can not only have languages people can read, write and
 understand - but exploit that rich static information to check that your
 code actually does what you say it does.

 ** **

 Isn't that the reason languages evolved?

 ** **

 Why are we always so concerned about what the language is doing, and so
 careless with expressiveness and information that makes it meaningful to
 human beings?

 ** **

 Dynamically typed languages will always struggle with automatizing
 refactoring functionalities to a certain extend

 ** **

 PHP *was* a dynamically typed language - it is currently a mixed type
 language. You have optional static references to types in argument-lists -
 even if those are only checked dynamically by the interpreter, they are
 usually checked statically by every external tool.

 ** **

 Every well-written application, library, framework etc *treats* PHP as a
 mixed-typed language most of the time, decorating the language up, down and
 center with static type-information, everywhere, all the time.

 ** **

 Don't you think that's a symptom of something?

 ** **

 ** **

 On Wed, May 1, 2013 at 5:39 PM, Robert Stoll rst...@tutteli.ch wrote:***
 *

 I have to agree with Etienne. Your idea is good, but it is probably better
 to implement a better Refactoring support in the IDE rather than enable it
 through the language itself. Dynamically typed languages will always
 struggle with automatizing refactoring functionalities to a certain extend.

 -Ursprüngliche Nachricht-
 Von: ekne...@gmail.com [mailto:ekne...@gmail.com] Im Auftrag von Etienne
 Kneuss
 Gesendet: Mittwoch, 1. Mai 2013 22:12
 An: Rasmus Schultz
 Cc: Rasmus Lerdorf; Stas Malyshev; PHP internals
 Betreff: Re: [PHP-DEV] property de-referencing


 On Wed, May 1, 2013 at 7:13 PM, Rasmus Schultz ras...@mindplay.dk wrote:

  The only reason being that the syntax ^$user-name is more static
  than
  new PropertyReference($user, 'name'), and thus easier to refactor?
 
 
  Not more static, it is static - a string-based property-reference is
 not.
 

  Refactoring isn't the only benefit - of course most of the benefits
  are going to come from IDE support, but would include things like
  inline documentation, auto-complete and warnings/errors based on
  static analysis/inspections. I already covered that.
 


  PHP-based code-analysis tools would also be able to do a better job
  when checking views etc. - if you're using PHP-based static analysis
  tools to check for code-smells etc. there's a good chance you have it
  configured to skip your view-template folders...
 

 

 I am sorry, but I find very hard to believe that a ^ preceeding a
 property access is going to make things

Re: [PHP-DEV] property de-referencing


 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 value. There is
no property - hence nothing to reflect on.

Assuming you have accessors for those get() and set() methods, and assuming
$firstName is an object-property and not just a hashed string, why not
simply:

$p = ^$authors[0]-personalDetails-firstName;

Assuming you added static information about the type of $authors, what was
previously a string (for which you need a run-time parser and a  bunch of
code) is now IDE-friendly, with auto-completion as you type, inspections,
accurate refactoring, etc. (without writing framework-specific plug-ins for
every major IDE.)

If $authors is an array, this might translate roughly into:

$p = new PropertyReference($authors[0]-personalDetails, 'firstName');

Or perhaps with more lazy evaluation:

$p = new PropertyReference(
function () use ($authors) {
return $authors[0]-personalDetails;
}
,
'firstName'
);

It's still dynamic, but the source-code now contains more static
information - you're using PHP syntax instead of inventing custom syntax
and parsing it out of strings, for things the language can already do, but
doesn't do elegantly.

You now have the ability to reflect on the type of the $personalDetails
object and the $firstName property and establish defaults based on
annotation parsing (as as popular in Symfony) or conventions for labels
('firstName' = 'First Name') etc.

You can assert early on if this code is going to work. You can know if you
making a break change somewhere along that object graph. You don't need a
library to parse custom syntax for value paths at run-time anymore, you're
not inventing new syntax for something the language can already do, and
developers no longer need to learn that custom syntax. You can use
automated refactoring. Your IDE can provide auto-complete and inline
documentation as you type.

I don't like strings for references to source-code elements. It's ugly,
it's unsafe, it can't be analyzed or refactored, and it's bloody backwards
- to use a different example, look at this oddly popular approach to
configuration:

$config = array(
'foo' = 'bar',
'services' = array(
'db' = array(
'username' = '...',
'password' = '...',
),
'email' = array(
'host' = '',
),
),
);

Those are not objects and properties, they are arrays and strings, and they
are dead matter.

But they map 1:1 to objects and properties.

So for all intents and purposes, they are a dead form of objects and
properties that can only be revived at run-time - nothing can be known
about the existence of any of those objects or properties prior to actually
running the code. That means you can expect some ugly surprises down the
line, when one of these unchecked references turn out to be wrong, or some
change/refactoring breaks code that worked before. Or you can spend a lot
of time writing unit-tests for things that shouldn't be able to fail in the
first place.

There are ways around that, and it involves relying on the static qualities
of the language:

$config[] = function (PDO $db) {
$db-username = 'foo';
$db-password = 'bar';
};

Thanks to the type-hint - a popular static language feature - this code can
inspected and checked.

If you wanted the same for your nested arrays and strings, you would have
to write plug-ins for every major IDE - more code.

I like simple things. That's one of the key reasons I like PHP.

Dynamic is not automatically simpler. Especially not when you have to learn
and write and maintain oodles of static source-code annotations to bring
the code-quality up to a level that is accepted by the PHP community at
large.

If you think keeping the language simple makes life simpler, you're fooling
yourself.

It's good that people like Bernhard have the time and energy to come up
with solutions to problems like these - it's bad when we have to resort to
unchecked code and custom syntax and parsers and IDE plug-ins to solve
these problems and work comfortably with those solutions.

Exclusively static languages aren't the answer, but neither are dominantly
dynamic languages - the majority of PHP code is heavily embedded with
static information for a reason.

I would never want to see the dynamic features of the language crippled or
encumbered in favor of static features - but to ignore the need for more
static features in the language is to hold back a natural development that
is already happening whether you approve of it or not.

Maybe this particular feature is wrong for other reasons, I don't know,
that's why we're discussing it.

But don't reject the idea because it's static and doesn't fit with

Re: [PHP-DEV] property de-referencing

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 - it would instruct a static analyzer that the keys in
those arrays are actually references to properties, and you could then
autocomplete the strings and property-names, display inline documentation,
perform inspections, etc.

The same would work in form-helpers:

echo $form-textInput(/** @ref User */ 'email');


Auto-complete, auto-refactoring, all possible now.

It looks horrible of course, and pretty soon we'll be extending our
annotation-parsers to get access to the static information embedded in
doc-blocks that isn't part of the language.

It's not very elegant, because it addresses a problem, but ignores the
underlying root of the problem. It treats a symptom, not the cause. (the
staple of American over-priced inferior health care, or perhaps more
accurately, sick care.)

I really like to see programming languages addressing problems at the root.
We should look below every need and every problem to find the simplest
possible solution that best addresses the broadest possible set of problems.

Maybe this feature doesn't do that. But then let's ponder what does?

There has got to be ways in which the language can better facilitate things
like property indirection and other needs for more static features?

And I don't believe that will ruin the experience or bump the learning
curve for an otherwise very accessible language - seeing as how everyone
has to learn how to decorate their code with static information sooner or
later.

PHP is being used for much bigger things these days than just forums and
blogs - it's driving big applications and services.

You don't think it's possible to elevate the language to a level where it
can facilitate complex architecture as well as simple forums and blogs?

You've made strides these past few years, you really have. Please don't
quit or think you're all done? :-)


On Thu, May 2, 2013 at 10:33 AM, Rasmus Schultz ras...@mindplay.dk wrote:

 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 value. There is
 no property - hence nothing to reflect on.

 Assuming you have accessors for those get() and set() methods, and
 assuming $firstName is an object-property and not just a hashed string, why
 not simply:

 $p = ^$authors[0]-personalDetails-firstName;

 Assuming you added static information about the type of $authors, what was
 previously a string (for which you need a run-time parser and a  bunch of
 code) is now IDE-friendly, with auto-completion as you type, inspections,
 accurate refactoring, etc. (without writing framework-specific plug-ins for
 every major IDE.)

 If $authors is an array, this might translate roughly into:

 $p = new PropertyReference($authors[0]-personalDetails, 'firstName');

 Or perhaps with more lazy evaluation:

 $p = new PropertyReference(
 function () use ($authors) {
 return $authors[0]-personalDetails;
 }
 ,
 'firstName'
 );

 It's still dynamic, but the source-code now contains more static
 information - you're using PHP syntax instead of inventing custom syntax
 and parsing it out of strings, for things the language can already do, but
 doesn't do elegantly.

 You now have the ability to reflect on the type of the $personalDetails
 object and the $firstName property and establish defaults based on
 annotation parsing (as as popular in Symfony) or conventions for labels
 ('firstName' = 'First Name') etc.

 You can assert early on if this code is going to work. You can know if you
 making a break change somewhere along that object graph. You don't need a
 library to parse custom syntax for value paths at run-time anymore, you're
 not inventing new syntax for something the language can already do, and
 developers no longer need to learn that custom syntax. You can use
 automated refactoring. Your IDE can provide auto-complete and inline
 documentation as you type.

 I don't like strings for references to source-code elements. It's ugly,
 it's unsafe, it can't be analyzed or refactored, and it's bloody backwards
 - to use a different example, look at this oddly popular approach to
 configuration:

 $config = array(
 'foo' = 'bar',
 'services' = array(
 'db' = array(
 'username' = '...',
 'password' = '...',
 ),
 'email' = array(
 'host' = '',
 ),
 ),
 );

 Those are not objects and properties, they are arrays and strings, and
 they are dead matter.

 But they map 1:1 to

Re: [PHP-DEV] property de-referencing

 have to ask
 again, did I miss something of your new language feature or is it really
 just a shorthand for “new PropertyReference($user, 'name');”?

 Von: Rasmus Schultz [mailto:ras...@mindplay.dk]
 Gesendet: Donnerstag, 2. Mai 2013 14:14
 An: Robert Stoll
 Cc: Etienne Kneuss; Rasmus Lerdorf; Stas Malyshev; PHP internals
 Betreff: Re: [PHP-DEV] property de-referencing

 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 painful compared
 to other strictly typed programming languages, since it will always need
 the
 manual approval from the user.

 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 for
 any dynamic language, and I don't see how it could. IDEs are already
 struggling with real-time static analysis, even on fast computers, and with
 the amount of voluntary static information provided by developers.

 Let's strip all the static annotations from a large codebase like Symfony,
 Zend, WordPress, Drupal, etc. - and see how a developer who has never
 worked
 with one of those will fare? I'm betting you wouldn't get very far.

 Even if you could somehow analyze all possible execution paths in an entire
 codebase, I don't think you would get very far with static analysis.

 I think most of the PHP developers (not users) do not want to change it and
 want to keep the dynamic aspect of the language.

 How does adding more static features to a language that already has mixed
 typing interfere with the dynamic aspect of the language?

 I don't understand that mode of thinking.

 PHP for any serious purpose has to be so heavily decorated, it's already
 being used dominantly as a static language.

 Adding more static features does not have to influence the dynamic aspects,
 at all - use typing when you want it, and don't use it when you don't want
 it, same as any other language with mixed typing. There are other languages
 that pull that off successfully.

 I get the impression that most of the PHP developers do not want to change
 it, because the want the dynamic aspects of the language to remain
 dominant?

 Well, look at any modern PHP codebase out there - the source-code is
 dominantly statically typed, and has been for years. Dynamic features are
 reserved for the times when something dynamic really adds value and you can
 live with the trade-offs, but those cases are islands in an ocean of
 statically decorated code.

 that’s the reason why I came up with the project Type-Safe PHP

 Myself and others have come up with similar libraries over the years - so
 yes, the need is there, this is a symptom. Every codebase is full of static
 information - it's considered very bad practice by the community at large
 to
 not decorate your code with static information. That's a symptom.

 Why are static features seen as a threat to dynamic features? In languages
 with mixed typing, it's not a struggle between statics and dynamics - it's
 just a choice. They complement each other. They do not compete. It's not a
 contest.


 On Thu, May 2, 2013 at 8:02 AM, Robert Stoll rst...@tutteli.ch wrote:
 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 annotations.
 And even with the static information in addition, the IDEs still struggle
 and refactoring PHP code is quite painful compared to other strictly typed
 programming languages, since it will always need the manual approval from
 the user.

 In my opinion your idea is better than using strings (however, I do not
 like
 the ^ but that’s a detail) and I would also like that the language enforces
 static types etc. instead of using @var, @return etc. But I think most of
 the PHP developers (not users) do not want to change it and want to keep
 the
 dynamic aspect of the language. I think that’s perfectly reasonable. Btw
 that’s the reason why I came up with the project Type-Safe PHP
 (http://tsphp.tutteli.ch).

 I have the impression you will not go very far with your idea to introduce
 a
 new language feature. But that doesn’t mean that your idea was worthless. I
 think it is a next step to better refactoring support within IDEs and the
 IDEs developer should consider to improve their data flow analysis and
 extend their capabilities and support PropertyReference etc. If they can
 handle PropertyReference then it doesn’t matter if you use your

Re: [PHP-DEV] property de-referencing

2013-05-01 Thread Lazare Inepologlou

Hello,

2013/5/1 Stas Malyshev smalys...@sugarcrm.com

 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-05-01 Thread Jannik Zschiesche

Hi,

Lazare Inepologlou
Mittwoch, 1. Mai
2013 10:55
Hello,2013/5/1
Stas Malyshev smalys...@sugarcrm.comThe
result is the same with "new ReplectionMethod('foo','bar')". The addedvalue
is that it can be statically checked.

well... yes and no.

Take the Symfony2 example:
you want to reference ^$task-task with autocompletion in your IDE?

This won't work, because Task::$task is a protected property. Symfony2
does the magic for you and automagically accesses the getters and
setters.
This probably won't work with property references, since you can't get
the getters and setters for it (except relying on the name of the
property as string and manipulating it).

Soo... I guess, for this feature, to be useful, we need object accessors
first (which were recently rejected by vote)?

Cheers
Jannik

Lazare INEPOLOGLOUIngnieur Logiciel

Stas Malyshev
Mittwoch, 1. Mai
2013 01:12
Hi!PHP
has functions that can be result of __call or arbitrary code thatimplements
fcall handler in an extension. What would be returned then?

Lazare Inepologlou
Mittwoch, 1. Mai
2013 00:20
2013/4/30 Rasmus Lerdorf
ras...@lerdorf.comIn C#, they had the
intention to introduce the operator infoof(...) to getthe
reflection, not only of properties, but of virtually everything in thelanguage.
They abandoned the idea because it is really hard to do that foroverloaded
functions and they did not want to do all that work for a halfbaked
feature:http://blogs.msdn.com/b/ericlippert/archive/2009/05/21/in-foof-we-trust-a-dialogue.aspxHowever,
PHP does not have overloaded functions, which makes thingssignificantly
easier, so maybe it is worth examining the idea.Lazare
INEPOLOGLOUIngnieur Logiciel

Rasmus Lerdorf
Dienstag, 30.
April 2013 23:00
It is certainly
not worth overloading the XOR operator for.-Rasmus

Stas Malyshev
Dienstag, 30.
April 2013 22:58
Hi!You
probably have use case for that, and it should be pretty easy towrite
a class that does that, but why it should be in the language? Itcertainly
doesn't look like something sizeable portion of PHP devs woulddo
frequently.

Re: [PHP-DEV] property de-referencing


 This won't work, because Task::$task is a protected property


It will work for code that's properly documented with @property annotations.


On Wed, May 1, 2013 at 7:05 AM, Jannik Zschiesche he...@apfelbox.netwrote:

 Hi,

   Lazare Inepologlou linep...@gmail.com
  Mittwoch, 1. Mai 2013 10:55
 Hello,

 2013/5/1 Stas Malyshev smalys...@sugarcrm.com smalys...@sugarcrm.com



 The result is the same with new ReplectionMethod('foo','bar'). The added
 value is that it can be statically checked.

  well... yes and no.

 Take the Symfony2 example:
 you want to reference ^$task-task with autocompletion in your IDE?

 This won't work, because Task::$task is a protected property. Symfony2
 does the magic for you and automagically accesses the getters and setters.
 This probably won't work with property references, since you can't get the
 getters and setters for it (except relying on the name of the property as
 string and manipulating it).

 Soo... I guess, for this feature, to be useful, we need object accessors
 first (which were recently rejected by vote)?


 Cheers
 Jannik


 Lazare INEPOLOGLOU
 Ingénieur Logiciel

   Stas Malyshev smalys...@sugarcrm.com
  Mittwoch, 1. Mai 2013 01:12
 Hi!


 PHP has functions that can be result of __call or arbitrary code that
 implements fcall handler in an extension. What would be returned then?
   Lazare Inepologlou linep...@gmail.com
  Mittwoch, 1. Mai 2013 00:20
 2013/4/30 Rasmus Lerdorf ras...@lerdorf.com ras...@lerdorf.com

 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

   Rasmus Lerdorf ras...@lerdorf.com
  Dienstag, 30. April 2013 23:00

 It is certainly not worth overloading the XOR operator for.

 -Rasmus


   Stas Malyshev smalys...@sugarcrm.com
  Dienstag, 30. April 2013 22:58
 Hi!


 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.

Re: [PHP-DEV] property de-referencing


 This is a fringe feature, as evidenced by the fact that you
 are having a hard time convincing people that it is needed


As with anything that isn't already established and well-known, it's hard
to convince anyone they need anything they don't understand - I think the
barrier here is me having difficulty explaining a new idea/concept. That
doesn't make it a fringe feature - I have already demonstrated by example
how this would be useful in practically every mainstream framework.

Properties simply don't carry
 this information with them so a lot of things would have to change
 internally for this to ever work


I'm not sure what information you're referring to?

Let's say for the sake of argument, I'm going to use a pre-processor to
transform the following code:

$prop = ^$user-name;

var_dump($nameprop-getValue()); // = 'Rasmus'

$nameprop-setValue('Bob');

var_dump($nameprop-getValue()); // = 'Bob'

The pre-processor output might look like this:

$nameprop = new PropertyReference($user, 'name'); // $prop = ^$user-name;

var_dump($nameprop-getValue()); // = 'Rasmus'

$nameprop-setValue('Bob');

var_dump($nameprop-getValue()); // = 'Bob'

Only the first line changes - the rest behaves and runs like any normal PHP
code.

And the PropertyReference class could be implemented in plain PHP like this:

class PropertyReference
{
private $_object;

private $_propertyName;

public function __construct($object, $propertyName)
{
$this-_object = $object;
$this-_propertyName = $propertyName;
}

public function getObject()
{
return $this-_object;
}

public function getPropertyName()
{
return $this-_propertyName;
}

public function getValue()
{
return $this-_object-{$this-_propertyName};
}

public function setValue($value)
{
$this-_object-{$this-_propertyName} = $value;
}

// and maybe:

public function getReflection()
{
return new ReflectionObject($this-_object);
}
}


You can see the above example running in a sandbox here:

http://sandbox.onlinephpfunctions.com/code/87c57301e0f6babb51026192bd3db84ddaf84c83

Someone said they didn't think this would work for accessors, so I'm
including a running sample with a User model that uses accessors:

http://sandbox.onlinephpfunctions.com/code/f2922b3a5dc0e12bf1e6fcacd8e73ff80717f3cb

Note that the dynamic User::$name property in this example is properly
documented and will reflect in an IDE.


On Tue, Apr 30, 2013 at 8:43 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:

 On 04/30/2013 05:17 PM, Rasmus Schultz wrote:

  If the asterisk (or some other character) offers and easier
  implementation path, whatever.

 It doesn't. This is a fringe feature, as evidenced by the fact that you
 are having a hard time convincing people that it is needed, and thus
 shouldn't overload an existing operator. Visually it would be confusing
 to take any well-known operator and give it a different obscure meaning.
 But yes, syntax-wise ^ could be made to work, the implementation problem
 I referred to is lower-level than that. Properties simply don't carry
 this information with them so a lot of things would have to change
 internally for this to ever work and if a clean implementation could be
 found, like I said, adding it to the reflection functions is the proper
 place.

 -Rasmus

Re: [PHP-DEV] property de-referencing

2013-05-01 Thread Peter Lind

On 1 May 2013 14:35, Rasmus Schultz ras...@mindplay.dk wrote:

 
  This is a fringe feature, as evidenced by the fact that you
  are having a hard time convincing people that it is needed


 As with anything that isn't already established and well-known, it's hard
 to convince anyone they need anything they don't understand - I think the
 barrier here is me having difficulty explaining a new idea/concept. That
 doesn't make it a fringe feature - I have already demonstrated by example
 how this would be useful in practically every mainstream framework.


Then why are you not convincing them first to get them on board as support
for your proposal. Right now you're obviously fighting an uphill struggle.
Whether that's because your proposal is without merit or because you have a
hard time convincing people on this mailing list remains to be seen - so
how about taking a smarter approach and convincing your target audience
first, then come back here with more support and a better proposal?

Just a thought.

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] property de-referencing


 Then why are you not convincing them first to get them on board as support
 for your proposal.


It's not a proposal yet - I didn't want to write a lengthy RFC just to
learn that all I had was a brainfart, or that everyone was going to be
totally opposed. Having the discussion here surfaced a ton of questions
that (so far) indicate (to me) that this might be a good idea, and also
helps me address all of those questions if I do end up writing an RFC.

If you think gathering the information in an RFC is the next logical step,
I will try to find the time :-)


On Wed, May 1, 2013 at 8:41 AM, Peter Lind peter.e.l...@gmail.com wrote:


 On 1 May 2013 14:35, Rasmus Schultz ras...@mindplay.dk wrote:

 
  This is a fringe feature, as evidenced by the fact that you
  are having a hard time convincing people that it is needed


 As with anything that isn't already established and well-known, it's hard
 to convince anyone they need anything they don't understand - I think the
 barrier here is me having difficulty explaining a new idea/concept. That
 doesn't make it a fringe feature - I have already demonstrated by example
 how this would be useful in practically every mainstream framework.


 Then why are you not convincing them first to get them on board as support
 for your proposal. Right now you're obviously fighting an uphill struggle.
 Whether that's because your proposal is without merit or because you have a
 hard time convincing people on this mailing list remains to be seen - so
 how about taking a smarter approach and convincing your target audience
 first, then come back here with more support and a better proposal?

 Just a thought.

 --
 hype
 WWW: plphp.dk / plind.dk
 CV: careers.stackoverflow.com/peterlind
 LinkedIn: plind
 Twitter: kafe15
 /hype

Re: [PHP-DEV] property de-referencing

2013-05-01 Thread Peter Lind

On 1 May 2013 14:55, Rasmus Schultz ras...@mindplay.dk wrote:

 Then why are you not convincing them first to get them on board as support
 for your proposal.


 It's not a proposal yet - I didn't want to write a lengthy RFC just to
 learn that all I had was a brainfart, or that everyone was going to be
 totally opposed. Having the discussion here surfaced a ton of questions
 that (so far) indicate (to me) that this might be a good idea, and also
 helps me address all of those questions if I do end up writing an RFC.

 If you think gathering the information in an RFC is the next logical step,
 I will try to find the time :-)


I think that 1) you might as well start the work now, both to give people a
place to get an overview of the discussion and to gather up the questions
of which there are already a few, and that 2) if you don't start by
reaching out to your indicated main audience (frameworks) then you won't
get the support the idea needs. Also, 3) as your indicated audience is
frameworks they will presumably have a lot of feedback - including your
basic no we don't need this or this would be awesome.

Note that I don't think frameworks would necessarily be the sole audience
for this - I just think your time would be better spent taking the idea
there first.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

RE: [PHP-DEV] property de-referencing

2013-05-01 Thread Ford, Mike

I know I'm still somewhat of a beginner with OOP, and not at all into 
large-scale OOP frameworks (yet!), but I'm really struggling to understand why 
the existing  reference operator doesn't suffice for what you are after?

If you could explain in words of as few syllables as possible what you would 
want to add to:

   class User
   {
   public $name;
   }

   $user = new User;
   $user-name = 'Rasmus';

   $nameprop = $user-name;

   var_dump($nameprop); // = 'Rasmus'

   $nameprop = 'Bob';

   var_dump($nameprop); // = 'Bob'


I would be immensely grateful, as I might then stand a chance of deciding 
whether I'm with you or agin you...!


Cheers!

Mike

-- 
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,  
Portland PD507, City Campus, Leeds Metropolitan University,
Portland Way, LEEDS,  LS1 3HE,  United Kingdom 
E: m.f...@leedsmet.ac.uk T: +44 113 812 4730


 -Original Message-
 From: Rasmus Schultz [mailto:ras...@mindplay.dk]
 Sent: 01 May 2013 13:35
 To: Rasmus Lerdorf
 Cc: Stas Malyshev; PHP internals
 Subject: Re: [PHP-DEV] property de-referencing
 
 
  This is a fringe feature, as evidenced by the fact that you
  are having a hard time convincing people that it is needed
 
 
 As with anything that isn't already established and well-known, it's
 hard
 to convince anyone they need anything they don't understand - I
 think the
 barrier here is me having difficulty explaining a new idea/concept.
 That
 doesn't make it a fringe feature - I have already demonstrated by
 example
 how this would be useful in practically every mainstream framework.
 
 Properties simply don't carry
  this information with them so a lot of things would have to change
  internally for this to ever work
 
 
 I'm not sure what information you're referring to?
 
 Let's say for the sake of argument, I'm going to use a pre-processor
 to
 transform the following code:
 
 $prop = ^$user-name;
 
 var_dump($nameprop-getValue()); // = 'Rasmus'
 
 $nameprop-setValue('Bob');
 
 var_dump($nameprop-getValue()); // = 'Bob'
 
 The pre-processor output might look like this:
 
 $nameprop = new PropertyReference($user, 'name'); // $prop = ^$user-
 name;
 
 var_dump($nameprop-getValue()); // = 'Rasmus'
 
 $nameprop-setValue('Bob');
 
 var_dump($nameprop-getValue()); // = 'Bob'
 
 Only the first line changes - the rest behaves and runs like any
 normal PHP
 code.
 
 And the PropertyReference class could be implemented in plain PHP
 like this:
 
 class PropertyReference
 {
 private $_object;
 
 private $_propertyName;
 
 public function __construct($object, $propertyName)
 {
 $this-_object = $object;
 $this-_propertyName = $propertyName;
 }
 
 public function getObject()
 {
 return $this-_object;
 }
 
 public function getPropertyName()
 {
 return $this-_propertyName;
 }
 
 public function getValue()
 {
 return $this-_object-{$this-_propertyName};
 }
 
 public function setValue($value)
 {
 $this-_object-{$this-_propertyName} = $value;
 }
 
 // and maybe:
 
 public function getReflection()
 {
 return new ReflectionObject($this-_object);
 }
 }
 
 
 You can see the above example running in a sandbox here:
 
 http://sandbox.onlinephpfunctions.com/code/87c57301e0f6babb51026192b
 d3db84ddaf84c83
 
 Someone said they didn't think this would work for accessors, so I'm
 including a running sample with a User model that uses accessors:
 
 http://sandbox.onlinephpfunctions.com/code/f2922b3a5dc0e12bf1e6fcacd
 8e73ff80717f3cb
 
 Note that the dynamic User::$name property in this example is
 properly
 documented and will reflect in an IDE.
 
 
 On Tue, Apr 30, 2013 at 8:43 PM, Rasmus Lerdorf ras...@lerdorf.com
 wrote:
 
  On 04/30/2013 05:17 PM, Rasmus Schultz wrote:
 
   If the asterisk (or some other character) offers and easier
   implementation path, whatever.
 
  It doesn't. This is a fringe feature, as evidenced by the fact
 that you
  are having a hard time convincing people that it is needed, and
 thus
  shouldn't overload an existing operator. Visually it would be
 confusing
  to take any well-known operator and give it a different obscure
 meaning.
  But yes, syntax-wise ^ could be made to work, the implementation
 problem
  I referred to is lower-level than that. Properties simply don't
 carry
  this information with them so a lot of things would have to change
  internally for this to ever work and if a clean implementation
 could be
  found, like I said, adding it to the reflection functions is the
 proper
  place.
 
  -Rasmus
 


To view the terms under which this email is distributed, please go to 
http://disclaimer.leedsmet.ac.uk/email.htm

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] property de-referencing

2013-05-01 Thread Etienne Kneuss

On Wed, May 1, 2013 at 2:35 PM, Rasmus Schultz ras...@mindplay.dk wrote:

 
  This is a fringe feature, as evidenced by the fact that you
  are having a hard time convincing people that it is needed


 As with anything that isn't already established and well-known, it's hard
 to convince anyone they need anything they don't understand - I think the
 barrier here is me having difficulty explaining a new idea/concept. That
 doesn't make it a fringe feature - I have already demonstrated by example
 how this would be useful in practically every mainstream framework.

 Properties simply don't carry
  this information with them so a lot of things would have to change
  internally for this to ever work


 I'm not sure what information you're referring to?

 Let's say for the sake of argument, I'm going to use a pre-processor to
 transform the following code:

 $prop = ^$user-name;

 var_dump($nameprop-getValue()); // = 'Rasmus'

 $nameprop-setValue('Bob');

 var_dump($nameprop-getValue()); // = 'Bob'

 The pre-processor output might look like this:

 $nameprop = new PropertyReference($user, 'name'); // $prop = ^$user-name;



So basically you want to introduce syntactic sugar for:

new PropertyReference($user, 'name')

The only reason being that the syntax ^$user-name is more static than
new PropertyReference($user, 'name'), and thus easier to refactor? To me
they really look equivalent from a refactoring point of view.

In any case, as many already pointed out, this sounds like a lot of pain
for really little (if any) gain.



 var_dump($nameprop-getValue()); // = 'Rasmus'

 $nameprop-setValue('Bob');

 var_dump($nameprop-getValue()); // = 'Bob'

 Only the first line changes - the rest behaves and runs like any normal PHP
 code.

 And the PropertyReference class could be implemented in plain PHP like
 this:

 class PropertyReference
 {
 private $_object;

 private $_propertyName;

 public function __construct($object, $propertyName)
 {
 $this-_object = $object;
 $this-_propertyName = $propertyName;
 }

 public function getObject()
 {
 return $this-_object;
 }

 public function getPropertyName()
 {
 return $this-_propertyName;
 }

 public function getValue()
 {
 return $this-_object-{$this-_propertyName};
 }

 public function setValue($value)
 {
 $this-_object-{$this-_propertyName} = $value;
 }

 // and maybe:

 public function getReflection()
 {
 return new ReflectionObject($this-_object);
 }
 }


 You can see the above example running in a sandbox here:


 http://sandbox.onlinephpfunctions.com/code/87c57301e0f6babb51026192bd3db84ddaf84c83

 Someone said they didn't think this would work for accessors, so I'm
 including a running sample with a User model that uses accessors:


 http://sandbox.onlinephpfunctions.com/code/f2922b3a5dc0e12bf1e6fcacd8e73ff80717f3cb

 Note that the dynamic User::$name property in this example is properly
 documented and will reflect in an IDE.


 On Tue, Apr 30, 2013 at 8:43 PM, Rasmus Lerdorf ras...@lerdorf.com
 wrote:

  On 04/30/2013 05:17 PM, Rasmus Schultz wrote:
 
   If the asterisk (or some other character) offers and easier
   implementation path, whatever.
 
  It doesn't. This is a fringe feature, as evidenced by the fact that you
  are having a hard time convincing people that it is needed, and thus
  shouldn't overload an existing operator. Visually it would be confusing
  to take any well-known operator and give it a different obscure meaning.
  But yes, syntax-wise ^ could be made to work, the implementation problem
  I referred to is lower-level than that. Properties simply don't carry
  this information with them so a lot of things would have to change
  internally for this to ever work and if a clean implementation could be
  found, like I said, adding it to the reflection functions is the proper
  place.
 
  -Rasmus
 




-- 
Etienne Kneuss
http://www.colder.ch

Re: [PHP-DEV] property de-referencing

2013-05-01 Thread Sherif Ramadan

On May 1, 2013 8:35 AM, Rasmus Schultz ras...@mindplay.dk wrote:

 
  This is a fringe feature, as evidenced by the fact that you
  are having a hard time convincing people that it is needed


 As with anything that isn't already established and well-known, it's hard

This is like building something and then going out to find a problem that
it will hopefully solve.

 to convince anyone they need anything they don't understand - I think the

Perhaps the reason you're having trouble convincing anyone that they need
it is simply because they don't need it? Things I need that solve real
world problems for me are pretty obvious to me. I'm sure the solution
wasn't always obvious but the problem definitely was.

 barrier here is me having difficulty explaining a new idea/concept. That
 doesn't make it a fringe feature - I have already demonstrated by example
 how this would be useful in practically every mainstream framework.

 Properties simply don't carry
  this information with them so a lot of things would have to change
  internally for this to ever work


 I'm not sure what information you're referring to?

 Let's say for the sake of argument, I'm going to use a pre-processor to
 transform the following code:

 $prop = ^$user-name;

 var_dump($nameprop-getValue()); // = 'Rasmus'

 $nameprop-setValue('Bob');

 var_dump($nameprop-getValue()); // = 'Bob'

 The pre-processor output might look like this:

 $nameprop = new PropertyReference($user, 'name'); // $prop = ^$user-name;

 var_dump($nameprop-getValue()); // = 'Rasmus'

 $nameprop-setValue('Bob');

 var_dump($nameprop-getValue()); // = 'Bob'

 Only the first line changes - the rest behaves and runs like any normal
PHP
 code.

 And the PropertyReference class could be implemented in plain PHP like
this:

 class PropertyReference
 {
 private $_object;

 private $_propertyName;

 public function __construct($object, $propertyName)
 {
 $this-_object = $object;
 $this-_propertyName = $propertyName;
 }

 public function getObject()
 {
 return $this-_object;
 }

 public function getPropertyName()
 {
 return $this-_propertyName;
 }

 public function getValue()
 {
 return $this-_object-{$this-_propertyName};
 }

 public function setValue($value)
 {
 $this-_object-{$this-_propertyName} = $value;
 }

 // and maybe:

 public function getReflection()
 {
 return new ReflectionObject($this-_object);
 }
 }


 You can see the above example running in a sandbox here:


http://sandbox.onlinephpfunctions.com/code/87c57301e0f6babb51026192bd3db84ddaf84c83

 Someone said they didn't think this would work for accessors, so I'm
 including a running sample with a User model that uses accessors:


http://sandbox.onlinephpfunctions.com/code/f2922b3a5dc0e12bf1e6fcacd8e73ff80717f3cb

 Note that the dynamic User::$name property in this example is properly
 documented and will reflect in an IDE.


 On Tue, Apr 30, 2013 at 8:43 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:

  On 04/30/2013 05:17 PM, Rasmus Schultz wrote:
 
   If the asterisk (or some other character) offers and easier
   implementation path, whatever.
 
  It doesn't. This is a fringe feature, as evidenced by the fact that you
  are having a hard time convincing people that it is needed, and thus
  shouldn't overload an existing operator. Visually it would be confusing
  to take any well-known operator and give it a different obscure meaning.
  But yes, syntax-wise ^ could be made to work, the implementation problem
  I referred to is lower-level than that. Properties simply don't carry
  this information with them so a lot of things would have to change
  internally for this to ever work and if a clean implementation could be
  found, like I said, adding it to the reflection functions is the proper
  place.
 
  -Rasmus

Re: [PHP-DEV] property de-referencing


 The only reason being that the syntax ^$user-name is more static than
 new PropertyReference($user, 'name'), and thus easier to refactor?


Not more static, it is static - a string-based property-reference is not.

Refactoring isn't the only benefit - of course most of the benefits are
going to come from IDE support, but would include things like inline
documentation, auto-complete and warnings/errors based on static
analysis/inspections. I already covered that.

PHP-based code-analysis tools would also be able to do a better job when
checking views etc. - if you're using PHP-based static analysis tools to
check for code-smells etc. there's a good chance you have it configured to
skip your view-template folders...


 To me they really look equivalent from a refactoring point of view.


They are not.

Refactoring based on strings is guesswork - it's slow when working with a
large codebase, and it's error-prone, and therefore requires manual review
of every change before you apply, even for things that should be
quick/simple like renaming a property.

In any case, as many already pointed out, this sounds like a lot of pain
 for really little (if any) gain.


Going to take a wild guess and say your IDE or text-editor does not do
static analysis?

Yes, there is little immediate gain from the feature itself - but as
demonstrated, valuable long-term gain from being able to write simpler,
stronger abstractions that provide more comfort and safety in an IDE.

On Wed, May 1, 2013 at 10:24 AM, Etienne Kneuss col...@php.net wrote:




 On Wed, May 1, 2013 at 2:35 PM, Rasmus Schultz ras...@mindplay.dk wrote:

 
  This is a fringe feature, as evidenced by the fact that you
  are having a hard time convincing people that it is needed


 As with anything that isn't already established and well-known, it's hard
 to convince anyone they need anything they don't understand - I think the
 barrier here is me having difficulty explaining a new idea/concept. That
 doesn't make it a fringe feature - I have already demonstrated by example
 how this would be useful in practically every mainstream framework.

 Properties simply don't carry
  this information with them so a lot of things would have to change
  internally for this to ever work


 I'm not sure what information you're referring to?

 Let's say for the sake of argument, I'm going to use a pre-processor to
 transform the following code:

 $prop = ^$user-name;

 var_dump($nameprop-getValue()); // = 'Rasmus'

 $nameprop-setValue('Bob');

 var_dump($nameprop-getValue()); // = 'Bob'

 The pre-processor output might look like this:

 $nameprop = new PropertyReference($user, 'name'); // $prop = ^$user-name;



 So basically you want to introduce syntactic sugar for:

 new PropertyReference($user, 'name')

 The only reason being that the syntax ^$user-name is more static than
 new PropertyReference($user, 'name'), and thus easier to refactor? To me
 they really look equivalent from a refactoring point of view.

 In any case, as many already pointed out, this sounds like a lot of pain
 for really little (if any) gain.



 var_dump($nameprop-getValue()); // = 'Rasmus'

 $nameprop-setValue('Bob');

 var_dump($nameprop-getValue()); // = 'Bob'

 Only the first line changes - the rest behaves and runs like any normal
 PHP
 code.

 And the PropertyReference class could be implemented in plain PHP like
 this:

 class PropertyReference
 {
 private $_object;

 private $_propertyName;

 public function __construct($object, $propertyName)
 {
 $this-_object = $object;
 $this-_propertyName = $propertyName;
 }

 public function getObject()
 {
 return $this-_object;
 }

 public function getPropertyName()
 {
 return $this-_propertyName;
 }

 public function getValue()
 {
 return $this-_object-{$this-_propertyName};
 }

 public function setValue($value)
 {
 $this-_object-{$this-_propertyName} = $value;
 }

 // and maybe:

 public function getReflection()
 {
 return new ReflectionObject($this-_object);
 }
 }


 You can see the above example running in a sandbox here:


 http://sandbox.onlinephpfunctions.com/code/87c57301e0f6babb51026192bd3db84ddaf84c83

 Someone said they didn't think this would work for accessors, so I'm
 including a running sample with a User model that uses accessors:


 http://sandbox.onlinephpfunctions.com/code/f2922b3a5dc0e12bf1e6fcacd8e73ff80717f3cb

 Note that the dynamic User::$name property in this example is properly
 documented and will reflect in an IDE.


 On Tue, Apr 30, 2013 at 8:43 PM, Rasmus Lerdorf ras...@lerdorf.com
 wrote:

  On 04/30/2013 05:17 PM, Rasmus Schultz wrote:
 
   If the asterisk (or some other character) offers and easier
   implementation path, whatever.
 
  It doesn't. This is a fringe feature, as evidenced by the fact that you
  are having a hard time convincing people that it is needed, and thus

RE: [PHP-DEV] property de-referencing

Hi Mike,

Missed your e-mail because it went to the list only.

What you're demonstrating here is functionally equivalent to the simple
example I provided. (The example was intended to show how this feature
works, not necessarily how you would use it in practice.)

The key difference, is that a native reference carries no contextual
information with it - a form-helper for instance can't determine which
object the referenced property belongs to, the name of the property, or
even the fact that the variable is referencing an object-property in the
first place.

You also can't use the  operator to create a reference to a virtual
(__get/__set) property, because you would be creating a reference to the
value that is returned by the __get() method, rather than to a (virtual)
property of an object.

That's why form-helpers currently store references to objects, and
reference properties using strings - rather than using native
variable-references as in your example.

---

From: Ford, Mike m.f...@leedsmet.ac.uk
To: PHP internals internals@lists.php.net
Cc:
Date: Wed, 1 May 2013 13:20:32 +
Subject: RE: [PHP-DEV] property de-referencing
I know I'm still somewhat of a beginner with OOP, and not at all into
large-scale OOP frameworks (yet!), but I'm really struggling to understand
why the existing  reference operator doesn't suffice for what you are
after?

If you could explain in words of as few syllables as possible what you
would want to add to:

   class User
   {
   public $name;
   }

   $user = new User;
   $user-name = 'Rasmus';

   $nameprop = $user-name;

   var_dump($nameprop); // = 'Rasmus'

   $nameprop = 'Bob';

   var_dump($nameprop); // = 'Bob'


I would be immensely grateful, as I might then stand a chance of deciding
whether I'm with you or agin you...!


Cheers!

Mike

Re: [PHP-DEV] property de-referencing

2013-05-01 Thread Etienne Kneuss

On Wed, May 1, 2013 at 7:13 PM, Rasmus Schultz ras...@mindplay.dk wrote:

 The only reason being that the syntax ^$user-name is more static than
 new PropertyReference($user, 'name'), and thus easier to refactor?


 Not more static, it is static - a string-based property-reference is not.


 Refactoring isn't the only benefit - of course most of the benefits are
 going to come from IDE support, but would include things like inline
 documentation, auto-complete and warnings/errors based on static
 analysis/inspections. I already covered that.



 PHP-based code-analysis tools would also be able to do a better job when
 checking views etc. - if you're using PHP-based static analysis tools to
 check for code-smells etc. there's a good chance you have it configured to
 skip your view-template folders...




I am sorry, but I find very hard to believe that a ^ preceeding a
property access is going to make things easier for any static analysis, and
I have done my share of them.

If you look even at the syntax tree, it is not any harder to track new
ReflectionProperty($obj, property) than it is to track ^$obj-property,
and that is a fact. You basically have a string literal instead of a
T_STRING.
You might argue that the property name does not need to be a string
literal, but then what about ^$foo-$bar or ^$foo-{'asd'}? would that be
forbidden?

To me they really look equivalent from a refactoring point of view.


 They are not.


 Refactoring based on strings is guesswork - it's slow when working with a
 large codebase, and it's error-prone, and therefore requires manual review
 of every change before you apply, even for things that should be
 quick/simple like renaming a property.


Refactoring in PHP will always be guesswork, error-prone, and will require
manual inspection, whether you have a fancy syntax to create
ReflectionProperies or not. Types are hard to track statically and that
won't change with this. And really, the strict translation of ^$obj-foo is
just as easy (and fast) to track by analyses.


 In any case, as many already pointed out, this sounds like a lot of pain
 for really little (if any) gain.


 Going to take a wild guess and say your IDE or text-editor does not do
 static analysis?


 Yes, there is little immediate gain from the feature itself - but as
 demonstrated, valuable long-term gain from being able to write simpler,
 stronger abstractions that provide more comfort and safety in an IDE.


I believe you have difficulties explaining these benefits because you first
need to argue why you want reflected properties all over the place. And
once that is established (assuming it is), why you would need dedicated
syntax for it.

If reflected properties is a big thing, I'm sure IDE support is as easy
to implement with or without this new syntax.

Introducing new syntax must be done with extreme care, and so far this case
looks quite far from convincing.



 On Wed, May 1, 2013 at 10:24 AM, Etienne Kneuss col...@php.net wrote:




 On Wed, May 1, 2013 at 2:35 PM, Rasmus Schultz ras...@mindplay.dkwrote:

 
  This is a fringe feature, as evidenced by the fact that you
  are having a hard time convincing people that it is needed


 As with anything that isn't already established and well-known, it's hard
 to convince anyone they need anything they don't understand - I think the
 barrier here is me having difficulty explaining a new idea/concept. That
 doesn't make it a fringe feature - I have already demonstrated by example
 how this would be useful in practically every mainstream framework.

 Properties simply don't carry
  this information with them so a lot of things would have to change
  internally for this to ever work


 I'm not sure what information you're referring to?

 Let's say for the sake of argument, I'm going to use a pre-processor to
 transform the following code:

 $prop = ^$user-name;

 var_dump($nameprop-getValue()); // = 'Rasmus'

 $nameprop-setValue('Bob');

 var_dump($nameprop-getValue()); // = 'Bob'

 The pre-processor output might look like this:

 $nameprop = new PropertyReference($user, 'name'); // $prop =
 ^$user-name;



 So basically you want to introduce syntactic sugar for:

 new PropertyReference($user, 'name')

 The only reason being that the syntax ^$user-name is more static
 than new PropertyReference($user, 'name'), and thus easier to refactor? To
 me they really look equivalent from a refactoring point of view.

 In any case, as many already pointed out, this sounds like a lot of pain
 for really little (if any) gain.



 var_dump($nameprop-getValue()); // = 'Rasmus'

 $nameprop-setValue('Bob');

 var_dump($nameprop-getValue()); // = 'Bob'

 Only the first line changes - the rest behaves and runs like any normal
 PHP
 code.

 And the PropertyReference class could be implemented in plain PHP like
 this:

 class PropertyReference
 {
 private $_object;

 private $_propertyName;

 public function __construct($object, $propertyName)
 {

Re: [PHP-DEV] property de-referencing

 I believe you have difficulties explaining these benefits because you
first need to argue why you want reflected properties all over the place.
And once that is established (assuming it is), why you would need dedicated
syntax for it.

I thought that's what I had been doing? Apparently I've just been writing
up long e-mails about nothing.

I don't understand your line of argumentation at all - strings are fine and
literal references to properties refactor just as well?

Okay.

Let's go ahead and quit using the new-statement then, because we don't
really need literal references to class-names - we can just do this instead:

function create($class_name)
{
return new $class_name;
}

$user = create('User');

$user-name = 'xyz';

See how far you'll get with static analysis when you don't even know the
class of an object anymore. Solong to any kind of static analysis whatsover.

Let's get rid of the instanceof-operator while we're at it, this works just
as well:

if (get_class($user) === 'User') {
   // yay!
}

You are correct, we don't technically need literal references to anything.

Forget the whole thing.

I'm going to build every app in Drupal from now on, where everything is a
string or an array or a stdClass - at least then there's consistently no
checkable literals or IDE support for anything.

Awesome.


On Wed, May 1, 2013 at 5:12 PM, Etienne Kneuss col...@php.net wrote:




 On Wed, May 1, 2013 at 7:13 PM, Rasmus Schultz ras...@mindplay.dk wrote:

 The only reason being that the syntax ^$user-name is more static
 than new PropertyReference($user, 'name'), and thus easier to refactor?


 Not more static, it is static - a string-based property-reference is
 not.


 Refactoring isn't the only benefit - of course most of the benefits are
 going to come from IDE support, but would include things like inline
 documentation, auto-complete and warnings/errors based on static
 analysis/inspections. I already covered that.



 PHP-based code-analysis tools would also be able to do a better job when
 checking views etc. - if you're using PHP-based static analysis tools to
 check for code-smells etc. there's a good chance you have it configured to
 skip your view-template folders...




 I am sorry, but I find very hard to believe that a ^ preceeding a
 property access is going to make things easier for any static analysis, and
 I have done my share of them.

 If you look even at the syntax tree, it is not any harder to track new
 ReflectionProperty($obj, property) than it is to track ^$obj-property,
 and that is a fact. You basically have a string literal instead of a
 T_STRING.
 You might argue that the property name does not need to be a string
 literal, but then what about ^$foo-$bar or ^$foo-{'asd'}? would that be
 forbidden?

 To me they really look equivalent from a refactoring point of view.


 They are not.


 Refactoring based on strings is guesswork - it's slow when working with a
 large codebase, and it's error-prone, and therefore requires manual review
 of every change before you apply, even for things that should be
 quick/simple like renaming a property.


 Refactoring in PHP will always be guesswork, error-prone, and will require
 manual inspection, whether you have a fancy syntax to create
 ReflectionProperies or not. Types are hard to track statically and that
 won't change with this. And really, the strict translation of ^$obj-foo is
 just as easy (and fast) to track by analyses.


 In any case, as many already pointed out, this sounds like a lot of pain
 for really little (if any) gain.


 Going to take a wild guess and say your IDE or text-editor does not do
 static analysis?


 Yes, there is little immediate gain from the feature itself - but as
 demonstrated, valuable long-term gain from being able to write simpler,
 stronger abstractions that provide more comfort and safety in an IDE.


 I believe you have difficulties explaining these benefits because you
 first need to argue why you want reflected properties all over the place.
 And once that is established (assuming it is), why you would need dedicated
 syntax for it.

 If reflected properties is a big thing, I'm sure IDE support is as easy
 to implement with or without this new syntax.

 Introducing new syntax must be done with extreme care, and so far this
 case looks quite far from convincing.



  On Wed, May 1, 2013 at 10:24 AM, Etienne Kneuss col...@php.net wrote:




 On Wed, May 1, 2013 at 2:35 PM, Rasmus Schultz ras...@mindplay.dkwrote:

 
  This is a fringe feature, as evidenced by the fact that you
  are having a hard time convincing people that it is needed


 As with anything that isn't already established and well-known, it's
 hard
 to convince anyone they need anything they don't understand - I think
 the
 barrier here is me having difficulty explaining a new idea/concept. That
 doesn't make it a fringe feature - I have already demonstrated by
 example
 how this would be useful

Re: [PHP-DEV] property de-referencing

PhpStorm has the finest refactoring support you can achieve with the
limited amount of static information in PHP source-code, plus hopefully a
whole bunch of @var and @property annotations. With the amount of
information inherent in PHP source-code, plus the volunteer information
provided by annotations, it still has to do a lot of guess-work, and you
still have to look over the proposed changes and manually correct what it
gets wrong.

I really see annotations in doc-blocks as a symptom of the lack of static
information in the language - the interpreter doesn't need information like
property-types or argument-types, but as it turns out, people do, so we
have to decorate the language with annotations to provide enough
information for people to comprehend the code.

But that means the annotations can now be out of sync with reality -
argument-types and property-types change. We discover, there was a useful
need for this information after all: type checking. So we introduce static
type-hints. The static information wasn't just useful to humans after all.

As for property-types and loads of other things, we annotate everything, in
part because the annotations are useful to people, in part to facilitate
proper IDE support and other forms of machine-analysis. Property type-hints
may not be necessary to run the language, but they are necessary for people
and external static analysis.

PHP is not a machine-friendly language - like most high-level languages, it
was designed with people in mind, which is natural, because people are the
ones who use programming languages. The machines would be satisfied with
machine instructions, if you could memorize them all and keep track of that
in your head.

To write a simple web-application, I'm betting you would need a QUADRILLION
annotations to do that.

Better to take all that static information and make it available to the
machine, so that we can not only have languages people can read, write and
understand - but exploit that rich static information to check that your
code actually does what you say it does.

Isn't that the reason languages evolved?

Why are we always so concerned about what the language is doing, and so
careless with expressiveness and information that makes it meaningful to
human beings?

Dynamically typed languages will always struggle with automatizing
 refactoring functionalities to a certain extend


PHP *was* a dynamically typed language - it is currently a mixed type
language. You have optional static references to types in argument-lists -
even if those are only checked dynamically by the interpreter, they are
usually checked statically by every external tool.

Every well-written application, library, framework etc *treats* PHP as a
mixed-typed language most of the time, decorating the language up, down and
center with static type-information, everywhere, all the time.

Don't you think that's a symptom of something?


On Wed, May 1, 2013 at 5:39 PM, Robert Stoll rst...@tutteli.ch wrote:

 I have to agree with Etienne. Your idea is good, but it is probably better
 to implement a better Refactoring support in the IDE rather than enable it
 through the language itself. Dynamically typed languages will always
 struggle with automatizing refactoring functionalities to a certain extend.

 -Ursprüngliche Nachricht-
 Von: ekne...@gmail.com [mailto:ekne...@gmail.com] Im Auftrag von Etienne
 Kneuss
 Gesendet: Mittwoch, 1. Mai 2013 22:12
 An: Rasmus Schultz
 Cc: Rasmus Lerdorf; Stas Malyshev; PHP internals
 Betreff: Re: [PHP-DEV] property de-referencing

 On Wed, May 1, 2013 at 7:13 PM, Rasmus Schultz ras...@mindplay.dk wrote:

  The only reason being that the syntax ^$user-name is more static
  than
  new PropertyReference($user, 'name'), and thus easier to refactor?
 
 
  Not more static, it is static - a string-based property-reference is
 not.
 

  Refactoring isn't the only benefit - of course most of the benefits
  are going to come from IDE support, but would include things like
  inline documentation, auto-complete and warnings/errors based on
  static analysis/inspections. I already covered that.
 


  PHP-based code-analysis tools would also be able to do a better job
  when checking views etc. - if you're using PHP-based static analysis
  tools to check for code-smells etc. there's a good chance you have it
  configured to skip your view-template folders...
 

 

 I am sorry, but I find very hard to believe that a ^ preceeding a
 property access is going to make things easier for any static analysis, and
 I have done my share of them.

 If you look even at the syntax tree, it is not any harder to track new
 ReflectionProperty($obj, property) than it is to track ^$obj-property,
 and that is a fact. You basically have a string literal instead of a
 T_STRING.
 You might argue that the property name does not need to be a string
 literal, but then what about ^$foo-$bar or ^$foo-{'asd'}? would that be
 forbidden?

 To me they really look

Re: [PHP-DEV] property de-referencing

2013-05-01 Thread Etienne Kneuss

On Thu, May 2, 2013 at 2:07 AM, Rasmus Schultz ras...@mindplay.dk wrote:

  I believe you have difficulties explaining these benefits because you
 first need to argue why you want reflected properties all over the place.
 And once that is established (assuming it is), why you would need dedicated
 syntax for it.

 I thought that's what I had been doing? Apparently I've just been writing
 up long e-mails about nothing.

 I don't understand your line of argumentation at all - strings are fine
 and literal references to properties refactor just as well?

 Okay.

 Let's go ahead and quit using the new-statement then, because we don't
 really need literal references to class-names - we can just do this instead:

 function create($class_name)
 {
 return new $class_name;
 }

 $user = create('User');

 $user-name = 'xyz';

 See how far you'll get with static analysis when you don't even know the
 class of an object anymore. Solong to any kind of static analysis whatsover.


If this was an idiom in PHP, I'm sure static analyses would be built with
enough interprocedural reasoning to handle that case just fine.



 Let's get rid of the instanceof-operator while we're at it, this works
 just as well:

 if (get_class($user) === 'User') {
// yay!
 }

 You are correct, we don't technically need literal references to anything.


 Forget the whole thing.

 I'm going to build every app in Drupal from now on, where everything is a
 string or an array or a stdClass - at least then there's consistently no
 checkable literals or IDE support for anything.


We have User::class now instead of 'User'. You should use it, it makes it
easy to refactor and stuff.

More seriously:

I'm just saying you are arguing for a *new* syntax that would allow
something rarely used (IMO) to be, as I see it: easier to analyze or
refactor; that doesn't qualify(IMO, again) as important enough to warrant a
syntax change.


 Awesome.


 On Wed, May 1, 2013 at 5:12 PM, Etienne Kneuss col...@php.net wrote:




 On Wed, May 1, 2013 at 7:13 PM, Rasmus Schultz ras...@mindplay.dkwrote:

 The only reason being that the syntax ^$user-name is more static
 than new PropertyReference($user, 'name'), and thus easier to refactor?


 Not more static, it is static - a string-based property-reference is
 not.


 Refactoring isn't the only benefit - of course most of the benefits are
 going to come from IDE support, but would include things like inline
 documentation, auto-complete and warnings/errors based on static
 analysis/inspections. I already covered that.



 PHP-based code-analysis tools would also be able to do a better job when
 checking views etc. - if you're using PHP-based static analysis tools to
 check for code-smells etc. there's a good chance you have it configured to
 skip your view-template folders...




 I am sorry, but I find very hard to believe that a ^ preceeding a
 property access is going to make things easier for any static analysis, and
 I have done my share of them.

 If you look even at the syntax tree, it is not any harder to track new
 ReflectionProperty($obj, property) than it is to track ^$obj-property,
 and that is a fact. You basically have a string literal instead of a
 T_STRING.
 You might argue that the property name does not need to be a string
 literal, but then what about ^$foo-$bar or ^$foo-{'asd'}? would that be
 forbidden?

 To me they really look equivalent from a refactoring point of view.


 They are not.


 Refactoring based on strings is guesswork - it's slow when working with
 a large codebase, and it's error-prone, and therefore requires manual
 review of every change before you apply, even for things that should be
 quick/simple like renaming a property.


 Refactoring in PHP will always be guesswork, error-prone, and will
 require manual inspection, whether you have a fancy syntax to create
 ReflectionProperies or not. Types are hard to track statically and that
 won't change with this. And really, the strict translation of ^$obj-foo is
 just as easy (and fast) to track by analyses.


 In any case, as many already pointed out, this sounds like a lot of pain
 for really little (if any) gain.


 Going to take a wild guess and say your IDE or text-editor does not do
 static analysis?


 Yes, there is little immediate gain from the feature itself - but as
 demonstrated, valuable long-term gain from being able to write simpler,
 stronger abstractions that provide more comfort and safety in an IDE.


 I believe you have difficulties explaining these benefits because you
 first need to argue why you want reflected properties all over the place.
 And once that is established (assuming it is), why you would need dedicated
 syntax for it.

 If reflected properties is a big thing, I'm sure IDE support is as easy
 to implement with or without this new syntax.

 Introducing new syntax must be done with extreme care, and so far this
 case looks quite far from convincing.



  On

Re: [PHP-DEV] property de-referencing

2013-04-30 Thread Michael Wallner

On 30 April 2013 01:45, Rasmus Schultz ras...@mindplay.dk wrote:

 The characters was an arbitrary choice, just for the sake of argument.

 I'm not a C programmer, so I don't have a patch - there is also no RFC, but
 there is general interest, I'd be happy to write one.

 On Mon, Apr 29, 2013 at 5:22 AM, Lars Strojny l...@strojny.net wrote:

  Hi Rasmus,
 
  Am 25.04.2013 um 14:47 schrieb Rasmus Schultz ras...@mindplay.dk:
  [...]
  
   What do you think?
 
 
  I'm not sure about the operator character but the general idea is a good
  one. Do you have a patch as a POC?


Do you mean something yucky like http://pecl.php.net/propro?
It's actually been meant to be used by extensions for internal properties,
but it might do the evil you're looking for.


-- 
Regards,
Mike

Re: [PHP-DEV] property de-referencing


 Do you mean something yucky like http://pecl.php.net/propro?


I don't know what that is, and there is no description on that page.


 It's actually been meant to be used by extensions for internal properties,
 but it might do the evil you're looking for.


Would you care to elaborate? What is evil about the thing I've described?


On Tue, Apr 30, 2013 at 3:58 AM, Michael Wallner m...@php.net wrote:

 On 30 April 2013 01:45, Rasmus Schultz ras...@mindplay.dk wrote:

 The characters was an arbitrary choice, just for the sake of argument.

 I'm not a C programmer, so I don't have a patch - there is also no RFC,
 but
 there is general interest, I'd be happy to write one.

 On Mon, Apr 29, 2013 at 5:22 AM, Lars Strojny l...@strojny.net wrote:

  Hi Rasmus,
 
  Am 25.04.2013 um 14:47 schrieb Rasmus Schultz ras...@mindplay.dk:
  [...]
  
   What do you think?
 
 
  I'm not sure about the operator character but the general idea is a good
  one. Do you have a patch as a POC?


 Do you mean something yucky like http://pecl.php.net/propro?
 It's actually been meant to be used by extensions for internal properties,
 but it might do the evil you're looking for.


 --
 Regards,
 Mike

Re: [PHP-DEV] property de-referencing

2013-04-30 Thread Ferenc Kovacs

2013.04.30. 14:00, Rasmus Schultz ras...@mindplay.dk ezt írta:

 
  Do you mean something yucky like http://pecl.php.net/propro?
 
 
 I don't know what that is, and there is no description on that page.

you can grasp the concept from the testcase:
http://git.php.net/?p=pecl/php/propro.git;a=blob_plain;f=tests/001.phpt;hb=HEAD

Re: [PHP-DEV] property de-referencing

That looks more pointless than evil to me - and no, I'm not suggesting
anything of that sort.

I'm proposing we need a way to statically reference an object property -
the object property itself, not it's value:

var_dump($user-name); // = 'Rasmus'

var_dump(^$user-name); // = PropertyReference(class: 'User',
propertyName: 'name', object:User(...))

$foo = ^$user-name;

var_dump($foo-getValue()); // = 'Rasmus'

$foo-setValue('Bob');

var_dump($user-name); // = 'Bob'

Is that easier to understand?

- Rasmus Schultz


On Tue, Apr 30, 2013 at 1:01 PM, Ferenc Kovacs tyr...@gmail.com wrote:


 2013.04.30. 14:00, Rasmus Schultz ras...@mindplay.dk ezt írta:

 
  
   Do you mean something yucky like http://pecl.php.net/propro?
  
  
  I don't know what that is, and there is no description on that page.

 you can grasp the concept from the testcase:

 http://git.php.net/?p=pecl/php/propro.git;a=blob_plain;f=tests/001.phpt;hb=HEAD

[PHP-DEV] Re: [lists.php] Re: [PHP-DEV] property de-referencing

2013-04-30 Thread ALeX

Just an idea: why not also use ^ (or another operator) to access the
value? (maybe as an additional way to get/setValue)

$foo = ^$user-name;

echo 'Hello '.^$foo;
^$foo = 'Bob';

(using the same operator will conflict when you are accessing a
property of an object which is a PropertyReference)

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [lists.php] Re: [PHP-DEV] property de-referencing

I don't think that's necessary - the point of being able to do this, is to
apply meta-programming techniques, so in most situations, what matters is
the ability to quickly create object/property-references... using them will
usually happen inside some service component, e.g. a form-helper or
object/relational-mapper. Having a short syntax for that is much less
relevant - what matters if easy (and of course static) creation of
references to those objects/properties.

On Tue, Apr 30, 2013 at 4:36 PM, ALeX lists@tx0.eu wrote:

 Just an idea: why not also use ^ (or another operator) to access the
 value? (maybe as an additional way to get/setValue)

 $foo = ^$user-name;

 echo 'Hello '.^$foo;
 ^$foo = 'Bob';

 (using the same operator will conflict when you are accessing a
 property of an object which is a PropertyReference)

Re: [PHP-DEV] property de-referencing

2013-04-30 Thread Stas Malyshev

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.

-- 
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] property de-referencing

2013-04-30 Thread 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


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] property de-referencing

2013-04-30 Thread Lazare Inepologlou

2013/4/30 Rasmus Lerdorf ras...@lerdorf.com

 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] property de-referencing

Any PHP dev who works with a mainstream framework does this daily, but the
frameworks rely on strings for property-names.

Take this example from the Symfony manual, for example:


class Task
{
protected $task;

protected $dueDate;

public function getTask()
{
return $this-task;
}
public function setTask($task)
{
$this-task = $task;
}

public function getDueDate()
{
return $this-dueDate;
}
public function setDueDate(\DateTime $dueDate = null)
{
$this-dueDate = $dueDate;
}
}

$form = $this-createFormBuilder($task)
-add('task', 'text')
-add('dueDate', 'date')
-getForm();

In this example, 'task' and 'dueDate' are property-references - except of
course that, no, they're not - they're obviously just strings... rewriting
this example to use a (fictive) form builder API with static
property-references:

$form = $this-createFormBuilder()
-add(^$task-task, 'text')
-add(^$task-dueDate, 'date')
-getForm();

We now have static property-references, which means the codebase can be
proofed using static analysis, which also means better IDE support with
property auto-completion, inline documentation, and automatic refactoring
for operations like renaming properties, etc.

Note that $task need not be passed to createFormBuilder() anymore -
instead, we can now use PropertyReference::getObject() inside the
form-builder to obtain the instance.

For that matter, we can now scrap the form-builder entirely and introduce a
simple form-helper in the view instead:

Task name: ?= $form-textInput(^$task-task) ?
Due Date: ?= $form-dateInput(^$task-dueDate) ?

This is even better, because we now have the same level of IDE support and
static analysis for textInput() and dateInput() which were previously
unchecked strings.

Or even simpler:

Task name: ?= $form-input(^$task-task) ?
Due Date: ?= $form-input(^$task-dueDate) ?

Using PropertyReference::getObject() and reflection inside the
form-helper's input() method, we can now use property-annotations to
specify the input-type. This is a matter of preference of course, but use
of annotations in Symfony is pretty popular.

This is just one example - most PHP devs (at least those who do PHP for a
living) use form abstractions and object/relational-mappers of some sort,
so this has practical applications for practically everyone, everywhere.

Rasmus Lerdorf wrote:

It is certainly not worth overloading the XOR operator for


Are we really going to quibble about syntax? This adds nothing to this
discussion. And as I explained earlier, the ^ operator is used for the sake
of discussion only - if it's more practical to use another character for
this operator, I don't care what it looks like.


On Tue, Apr 30, 2013 at 4:58 PM, Stas Malyshev smalys...@sugarcrm.comwrote:

 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.

 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

Re: [PHP-DEV] property de-referencing

2013-04-30 Thread 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?
-- 
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] property de-referencing

I suggested something similar earlier:

http://marc.info/?t=13632784962r=1w=2

However, I withdrew that idea, because I came to the realization that, for
practical applications, you usually need the object-context coupled with
the member-reference to do anything really useful.

A form-input abstraction, for example, needs the object-context to reflect
on the class, the property-reference to reflect on annotations (maybe) and
of course the property-value, plus the ability to apply a posted value back
onto to the object-property.

The proposed feature facilitates all of that.

At the risk of starting a separate discussion, the recently added
ClassName::class constant provides a way to statically reference a class,
which frankly has very few practical applications in comparison - the need
to reference properties is usually much more prevalent and repetitive than
the need to reference a class; assuming your classes have more than one
property each, heh. The feature as such is also somewhat crippled, since
what comes out of it is a string and not a class-reference.

It solves the problems of static class-references of course, so that's
positive - but where's the much more critical property-reference
counterpart? Because this feature overloads class-constant syntax, there is
no obvious counterpart for properties. It seems pretty short-sighted. If
referencing a class statically is necessary and important enough to make it
into the language, why are property-references considered less important or
valuable?

Try to think of these features in terms of completing or complementing the
fairly limited static side of an otherwise mostly dynamic language, rather
than as features intended to solve a specific programming problem as such.

I think there is still a pretty strong case for static property-references,
but since any new language-feature is generally a pretty hard sell around
here, I'm letting this one go for now.

The immediate impact and benefits of static object-property references
ought to be a much easier sell - it has pretty broad applications, and can
probably replace a lot of simple inline function-closures, and eliminate a
lot of double-arguments (object and property-name) from many
popular/mainstream libraries.

If you disagree, please explain by example. I've already put a lot of time
into thinking about this and explaining it pretty carefully. If you're
opposed for more than personal reasons, surely you can offer more than a
flippant one-line backlash? :-)


On Tue, Apr 30, 2013 at 6:20 PM, Lazare Inepologlou linep...@gmail.comwrote:



 2013/4/30 Rasmus Lerdorf ras...@lerdorf.com

 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] property de-referencing

2013-04-30 Thread Stas Malyshev

Hi!

 Any PHP dev who works with a mainstream framework does this daily, but
 the frameworks rely on strings for property-names.

What's wrong with strings? Just because it doesn't have three levels of
objects on it, doesn't mean it's not OK to use it.

 We now have static property-references, which means the codebase can be

If you know the property, you can just access it, you don't need to
invent weird indirection for it.

 Are we really going to quibble about syntax? This adds nothing to this

We're going to quibble about again trying to bring very small scope and
exotic feature into the core of the language.
-- 
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] property de-referencing

2013-04-30 Thread Adam Harvey

On 30 April 2013 16:15, Rasmus Schultz ras...@mindplay.dk wrote:
 At the risk of starting a separate discussion, the recently added
 ClassName::class constant provides a way to statically reference a class,
 which frankly has very few practical applications in comparison - the need
 to reference properties is usually much more prevalent and repetitive than
 the need to reference a class; assuming your classes have more than one
 property each, heh. The feature as such is also somewhat crippled, since
 what comes out of it is a string and not a class-reference.

I would caution against generalising use cases. Personally, ::class is
something I can use multiple times a day. This I'm not so sure about.

Your use case is not my use case, and vice versa. :)

 I think there is still a pretty strong case for static property-references,
 but since any new language-feature is generally a pretty hard sell around
 here, I'm letting this one go for now.

Why does this have to be a language feature? It obviously already
works in userland, as your own Symfony 2 examples show. 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.

Adam

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] property de-referencing

I've already demonstrated and explained what's wrong with strings.

Weird indirection is what we have in every mainstream framework right
now, where properties can be referenced only as strings - I gave a
real-world example of this, and demonstrated with a practical example how
the proposed feature can help improve on this issue.

I've demonstrated by example that this has more than limited scope.

The fact that mainstream frameworks have to resort to strings for
property-references is a symptom of the fact that this feature is absent:

- Mainstream frameworks already do what I propose (using strings)
demonstrating that it is a necessary task.

- People use these frameworks - proving that developers want these features
from the frameworks they use.

Please, contribute something material to this discussion - your snappy
responses have to make me think you're taking this very personally?

I promise I'm not trying to ruin your day. Can't we just have a friendly
discussion like grown-ups?

On Tue, Apr 30, 2013 at 7:16 PM, Stas Malyshev smalys...@sugarcrm.comwrote:

 Hi!

  Any PHP dev who works with a mainstream framework does this daily, but
  the frameworks rely on strings for property-names.

 What's wrong with strings? Just because it doesn't have three levels of
 objects on it, doesn't mean it's not OK to use it.

  We now have static property-references, which means the codebase can be

 If you know the property, you can just access it, you don't need to
 invent weird indirection for it.

  Are we really going to quibble about syntax? This adds nothing to this

 We're going to quibble about again trying to bring very small scope and
 exotic feature into the core of the language.
 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

Re: [PHP-DEV] property de-referencing

2013-04-30 Thread Sebastian Krebs

2013/5/1 Rasmus Schultz ras...@mindplay.dk

 Any PHP dev who works with a mainstream framework does this daily, but the
 frameworks rely on strings for property-names.

 Take this example from the Symfony manual, for example:


 class Task
 {
 protected $task;

 protected $dueDate;

 public function getTask()
 {
 return $this-task;
 }
 public function setTask($task)
 {
 $this-task = $task;
 }

 public function getDueDate()
 {
 return $this-dueDate;
 }
 public function setDueDate(\DateTime $dueDate = null)
 {
 $this-dueDate = $dueDate;
 }
 }

 $form = $this-createFormBuilder($task)
 -add('task', 'text')
 -add('dueDate', 'date')
 -getForm();

 In this example, 'task' and 'dueDate' are property-references - except of
 course that, no, they're not - they're obviously just strings... rewriting
 this example to use a (fictive) form builder API with static
 property-references:

 $form = $this-createFormBuilder()
 -add(^$task-task, 'text')
 -add(^$task-dueDate, 'date')
 -getForm();


One problem I have with this example is, that you usually (or at least
often) don't have a $task object here.




 We now have static property-references, which means the codebase can be
 proofed using static analysis, which also means better IDE support with
 property auto-completion, inline documentation, and automatic refactoring
 for operations like renaming properties, etc.

 Note that $task need not be passed to createFormBuilder() anymore -
 instead, we can now use PropertyReference::getObject() inside the
 form-builder to obtain the instance.

 For that matter, we can now scrap the form-builder entirely and introduce a
 simple form-helper in the view instead:

 Task name: ?= $form-textInput(^$task-task) ?
 Due Date: ?= $form-dateInput(^$task-dueDate) ?

 This is even better, because we now have the same level of IDE support and
 static analysis for textInput() and dateInput() which were previously
 unchecked strings.

 Or even simpler:

 Task name: ?= $form-input(^$task-task) ?
 Due Date: ?= $form-input(^$task-dueDate) ?

 Using PropertyReference::getObject() and reflection inside the
 form-helper's input() method, we can now use property-annotations to
 specify the input-type. This is a matter of preference of course, but use
 of annotations in Symfony is pretty popular.

 This is just one example - most PHP devs (at least those who do PHP for a
 living) use form abstractions and object/relational-mappers of some sort,
 so this has practical applications for practically everyone, everywhere.

 Rasmus Lerdorf wrote:

 It is certainly not worth overloading the XOR operator for


 Are we really going to quibble about syntax? This adds nothing to this
 discussion. And as I explained earlier, the ^ operator is used for the sake
 of discussion only - if it's more practical to use another character for
 this operator, I don't care what it looks like.


 On Tue, Apr 30, 2013 at 4:58 PM, Stas Malyshev smalys...@sugarcrm.com
 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.
 
  --
  Stanislav Malyshev, Software Architect
  SugarCRM: http://www.sugarcrm.com/
  (408)454-6900 ext. 227
 




-- 
github.com/KingCrunch

Re: [PHP-DEV] property de-referencing

2013-04-30 Thread Rasmus Lerdorf

On 04/30/2013 03:24 PM, Rasmus Schultz wrote:
 Are we really going to quibble about syntax? This adds nothing to this
 discussion. And as I explained earlier, the ^ operator is used for the sake
 of discussion only - if it's more practical to use another character for
 this operator, I don't care what it looks like.

The point is that there is no operator that fits and the reason you
didn't come up with one that didn't clash with something else. If this
can even be implemented, which doesn't seem all that certain without a
lot of messy changes, it should just be a reflection call.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] property de-referencing

On Tue, Apr 30, 2013 at 7:34 PM, Adam Harvey ahar...@php.net wrote:

 I would caution against generalising use cases. Personally, ::class is
 something I can use multiple times a day. This I'm not so sure about.

 Your use case is not my use case, and vice versa. :)


What is your use-case then? DI perhaps?


 Why does this have to be a language feature?


I already covered that.


 It obviously already works in userland, as your own Symfony 2 examples
 show.


As explained, this is not intended to solve a problem that can't currently
by solved by other means, but to strengthen the static aspects of the
language.


 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.

Yes, you can already create property-references at run-time - for that
matter, you could already use new ReflectionProperty($obj, 'prop') to do
what you demonstrated above.

But the property-name, in the source-code, is a string - it has no literal
relationship to YourClass::$prop where as ^$obj-prop does.

No mainstream framework provides a PropertyReference class, because it
wouldn't accomplish anything - the property-name is still a string, it's
still unchecked, and still can't (reliably) be used in static analysis.

Re: [PHP-DEV] property de-referencing


 one problem I have with this example is, that you usually (or at least
 often) don't have a $task object here.


I get what you're saying, but you do have a $task object if you want to use
the form-builder, because it relies on the object for state.

The same is true for most frameworks, and not generally a problem, since
you can just create a transient (throw-away) object - this generally works
fine, and has the added benefit of being able to initialize object
properties with defaults. (such as today's date on a calendar entry form)

On Tue, Apr 30, 2013 at 7:50 PM, Sebastian Krebs krebs@gmail.comwrote:




 2013/5/1 Rasmus Schultz ras...@mindplay.dk

 Any PHP dev who works with a mainstream framework does this daily, but the
 frameworks rely on strings for property-names.

 Take this example from the Symfony manual, for example:


 class Task
 {
 protected $task;

 protected $dueDate;

 public function getTask()
 {
 return $this-task;
 }
 public function setTask($task)
 {
 $this-task = $task;
 }

 public function getDueDate()
 {
 return $this-dueDate;
 }
 public function setDueDate(\DateTime $dueDate = null)
 {
 $this-dueDate = $dueDate;
 }
 }

 $form = $this-createFormBuilder($task)
 -add('task', 'text')
 -add('dueDate', 'date')
 -getForm();

 In this example, 'task' and 'dueDate' are property-references - except of
 course that, no, they're not - they're obviously just strings... rewriting
 this example to use a (fictive) form builder API with static
 property-references:

 $form = $this-createFormBuilder()
 -add(^$task-task, 'text')
 -add(^$task-dueDate, 'date')
 -getForm();


 One problem I have with this example is, that you usually (or at least
 often) don't have a $task object here.




 We now have static property-references, which means the codebase can be
 proofed using static analysis, which also means better IDE support with
 property auto-completion, inline documentation, and automatic refactoring
 for operations like renaming properties, etc.

 Note that $task need not be passed to createFormBuilder() anymore -
 instead, we can now use PropertyReference::getObject() inside the
 form-builder to obtain the instance.

 For that matter, we can now scrap the form-builder entirely and introduce
 a
 simple form-helper in the view instead:

 Task name: ?= $form-textInput(^$task-task) ?
 Due Date: ?= $form-dateInput(^$task-dueDate) ?

 This is even better, because we now have the same level of IDE support and
 static analysis for textInput() and dateInput() which were previously
 unchecked strings.

 Or even simpler:

 Task name: ?= $form-input(^$task-task) ?
 Due Date: ?= $form-input(^$task-dueDate) ?

 Using PropertyReference::getObject() and reflection inside the
 form-helper's input() method, we can now use property-annotations to
 specify the input-type. This is a matter of preference of course, but use
 of annotations in Symfony is pretty popular.

 This is just one example - most PHP devs (at least those who do PHP for a
 living) use form abstractions and object/relational-mappers of some sort,
 so this has practical applications for practically everyone, everywhere.

 Rasmus Lerdorf wrote:

 It is certainly not worth overloading the XOR operator for


 Are we really going to quibble about syntax? This adds nothing to this
 discussion. And as I explained earlier, the ^ operator is used for the
 sake
 of discussion only - if it's more practical to use another character for
 this operator, I don't care what it looks like.


 On Tue, Apr 30, 2013 at 4:58 PM, Stas Malyshev smalys...@sugarcrm.com
 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.
 
  --
  Stanislav Malyshev, Software Architect
  SugarCRM: http://www.sugarcrm.com/
  (408)454-6900 ext. 227
 




 --
 github.com/KingCrunch

Re: [PHP-DEV] property de-referencing