Re: [PHP-DEV] SVN Account Request: dominis
On Sat, Jan 8, 2011 at 22:11, Nandor Sivok domi...@haxor.hu wrote: Maintaining the documentation Maintaining an official, bundled PHP extension Which one? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: dominis
hi, Please provide patches first, via the internals mailing and the bugs tracker. After some time (and some patches), this request can be (re) considered. Cheers, On Sun, Jan 9, 2011 at 10:40 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sat, Jan 8, 2011 at 22:11, Nandor Sivok domi...@haxor.hu wrote: Maintaining the documentation Maintaining an official, bundled PHP extension Which one? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: about class names as values
I think adding a magic constant or method for getting the class name would
be usefull in many scenarios, when referencing a specific class (e.g.
factories, configurations). It would also work well with namespaces and
refactoring tools e.g.:
$mock = $this-getMock('\\My\\Custom\\Namespace\\MyClass');
vs.
use My\Custom\Namespace\MyClass;
$mock = $this-getMock(MyClass::CLASS);
On 8 January 2011 11:21, Ben Schmidt mail_ben_schm...@yahoo.com.au wrote:
I think doing something like this is a good idea for classes and
interfaces.
Ben.
On 7/01/11 1:16 AM, Martin Scotta wrote:
Yes, my intention was to only add a magic constant with the class, similar
to this
namespace Bar {
class Foo {
const KLASS = __CLASS__;
}
}
namespace Buzz {
use \Bar\Foo as BazFoo;
class Bar extends BazFoo {
const KLASS = __CLASS__;
}
$bar = new Bar;
$baz = new BazFoo;
var_dump( get_class($baz), BazFoo::KLASS);
var_dump( get_class($bar), Bar::KLASS );
}
This is 100% valid PHP 5.3.3 code, but that includes a lot of effort from
the developer. Someone miss to include the KLASS constant on a class and
the
result is undefined.
If that PHP could add a magic constant --named CLASS or whatever you
like--
to each class it will reduce the amount of class names hardcoded onto
strings, probably to zero.
The only issue that I found today is related to interfaces. I'm not sure
if
they should include this sort of magic constant, but I would rather
include
them just for consistency but, as I previously said, I'm not sure about
this
one.
Martin Scotta
2011/1/5 John LeSueurjohn.lesu...@gmail.com
2011/1/5 Johannes Schlüterjohan...@php.net
On Wed, 2011-01-05 at 21:53 -0300, Martin Scotta wrote:
$obj = newInstance( MyClass ); // notice. undefined constant MyClass
This describes the major change with your idea.
What happens if a constant MyClass exists?
Another question is something like this:
?php
function factory($class) {
return new $class();
}
factory( SomeClass );
?
To proper support this we'd have to make classes first class elements.
For making this consistent it would make sense to make functions first
class elements. And best drop the $ in front of variables and create a
new language. Everything else becomes a mess.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I think he's actually proposing creating for each class the magic class
constant CLASS, so your example becomes:
?php
function factory($class) {
return new $class();
}
factory( SomeClass::CLASS );
?
This is actually doable without a magic class constant, but requires a
function or class constant to be declared in each class.
?php
class SomeClass {
const CLASS = __NAMESPACE__ . '\' . __CLASS__;
static function getNameWithNSPath()
{
return __NAMESPACE__ . '\' . __CLASS__;
}
}
factory( SomeClass::getNameWithNSPath() );
?
Perhaps this could be simplified with traits, if __NAMESPACE__ and
__CLASS__ work in traits that way. In fact, that's an interesting
question,
what is __NAMESPACE__ in a trait defined in one namespace, then used in a
class in a different namespace?
I think the point is that the factory function could exist without any
knowledge of the namespaces of the classes it would work on. Then,
somewhere
else where the class has been aliased or is otherwise accessible without
the
full namespace path, the developer wouldn't need to specify the full
namespace path to the factory, but could ask the class itself what it's
full
namespace path was. I don't know that I agree with the idea, but I don't
think it requires making classes first class elements.
John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Mvh
Martin Vium
Senior System Arkitekt
Sitevision
Re: [PHP-DEV] Traits and Properties
On 06 Jan 2011, at 15:33, Johannes Schlüter wrote:
On Thu, 2011-01-06 at 14:38 +0100, Stefan Marr wrote:
On of those things is that you actually use ReflectionClass to reflect
on a trait.
That is really an implementation detail, and should be changed to not
confuse anyone on a conceptional level. We should not expose that kind
of engine/implementation detail.
This is the same with interfaces. What does class_exists('some_trait')
do? - I assume that returns true too.
It does return false for interfaces, that should be consistent and return false
for traits, too.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Extensions to traits
On Sat Jan 8 06:33 AM, Ben Schmidt wrote: Creating a patch will help getting feedback about what you're proposing http://ca3.php.net/reST/php-src/README.MAILINGLIST_RULES I hope I haven't broken any of the mailing list rules, but my apologies if I have, and please point out specifically where I've gone wrong. No rules broken in my opinion but in general consider: http://www.faqs.org/rfcs/rfc1855.html Over 100 lines is considered long The proposal (473 lines of plain text) would be easier to read on the web with some markup. As far as a patch goes, I don't think that is appropriate at this stage. I don't want to spend a lot of time creating a patch only to have it rejected if this could be avoided by a little discussion. My time is too valuable to me to waste like that, and with something as controversial as this, there's a real danger of that happening. Np, since you mentioned hacking the source I thought you had done some tinkering. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
Hi:
On 09 Jan 2011, at 17:23, Stefan Marr wrote:
This is the same with interfaces. What does class_exists('some_trait')
do? - I assume that returns true too.
It does return false for interfaces, that should be consistent and return
false for traits, too.
Ok, that is fixed and I added a trait_exists() to match the other functions.
Will add a note to the RFC.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
