btw: pretty cool you found time working on it again. I want that in 5.5 :)

@lstrojny I've added a bunch more tests for error conditions now. Let me know if you need anything more.

@ralphschindler Could you also add tests for where the compile-time resolution (for params for example) does work? I.e. for Foo::class and self::class :)

See @nikic’s comment. Other than that it looks good

@lstrojny @nikic done.

@ralphschindler Great. This looks ready for merge (after squashing the commits). Could you update your RFC to specify how the parent/static stuff was resolved?

@lstrojny Should this get a quick final review on internals or can we merge this directly as the vote was already done? (RFC: https://wiki.php.net/rfc/class_name_scalars)

@nikic I would drop a short message in IRC and merge than. @ralphschindler could you squash the commits so we can merge?

Very nice feature for 5.5. Thanks a lot for this patch!
I have a question about it. Does it support dynamic class names as scalars, which can be really useful in many places?

$obj = Factory::create(); // Creates specific instance of class
echo "Created {$obj::class} instance";

There is nothing about dynamic class names in RFC.

@lisachenko nope, that’s not supported.

@lstrojny: @lisachenko's question is very good. I'd also expect that to work, since $class::method() (or $class::CONSTANT) works fine. Would it be too difficult to implement it as runtime resolution?

@Majkl578 the problem is, it is ambigous. Does $var::class mean "give me the FQCN of the object" or "give me the FQCN of the class $var".

Good point.
For $instance::class, it should give the FCQN of that object (hence it'd generally be the same behavior as get_class($instance)). (And I think this was the case @lisachenko was speaking about.)
For non-object value, it doesn't make much sense - it should either be already FCQN or not a class name at all.

@lstrojny @Majkl578 yes, it's the use case that I want to be implemented. And it is not ambiguous, because $instance::class will be applied only to the class of object. And will return the same value as get_class($object) as previously mentioned by @Majkl578. We can discuss this more, if needed.
This logic will be consistent with the current behavior for accessing the constant value:

$value = static::const_name;
$value = self::const_name;
$value = $class::const_name;
$value = $this::const_name;

@lisachenko, @Majkl578 could be a good idea. We are going to merge this feature for 5.5 nevertheless. If you would like to see $obj::class in, please open a PR and write a (short) RFC in the wiki.

Squashed and RFC updated.

@lstrojny: Sorry, but I have neither C experimence to open PR nor wiki karma to write RFC, so IMO I'm not appropriate person for that. :) I'm not against merging this, it would be just a (possibly) nice addition to this.

Currently merging.

Comment on behalf of lstrojny at php.net:

• Added missing declaration to zend_compile.h
• Fixed some trailing whitespace issues in the patch
• Fixed some spacing issues in the tests

Otherwise: merged into PHP-5.5 and master. @ralphschindler thank you very much!

Thanks for merging, although I am curious why a patch could not merged that would retain authorship?

I don't know. Is there a way to edit a patch with GIT and retain authorship?

@lstrojny You can specify an author with git commit --author

Yeah, what we do in ZF is simply pull the branch down, then make edits (commit them), then merge that branch into master/develop. That way we don't alter the original commits in the patch/PR, and we make our changes over the top (so authorship is retained since we just accept their commits as part of the full branch PR, and our commits over the top retain our authorship).

So, I guess it depends on your workflow. If you are making diffs (which I'd argue you don't have to do at all), then you could use the git patch utilities which also create patches with authorship retained.

Either way, I think the best workflow is simply to create a new branch locally, merge in the PR, edit what you need, commit your changes, then move to the various target branches and merge in this local/working branch you've just created.

So, not a huge deal for me, but it would be nice to retain that work in source control with my name on it - (for blame, history, etc).

-ralph

On 01/20/2013 08:41 AM, Ralph Schindler wrote:

Yeah, what we do in ZF is simply pull the branch down, then make edits (commit them), then merge that branch into master/develop. That way we don't alter the original commits in the patch, and we make our changes over the top (so authorship is retained since we just accept their commits as part of the full branch PR, and our commits over the top retain our authorship).

So, I guess it depends on your workflow. If you are making diffs (which I'd argue you don't have to do at all), then you could use the git patch utilities which also create patches with authorship retained.

Either way, I think the best workflow is simply to create a new branch locally, merge in the PR, edit what you need, commit your changes, then move to the various target branches and merge in this local/working branch you've just created.

So, not a huge deal for me, but it would be nice to retain that work in source control with my name on it - (for blame, history, etc).

-ralph

---

Reply to this email directly or view it on GitHub:
#256 (comment)

Ralph,

Can you review https://wiki.php.net/vcs/gitworkflow and add a new workflow?

Thanks,

Chris

christopher.jones@oracle.com http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html