My email talked about properties not methods. Please re-read it :)
Andi
> -Original Message-
> From: Larry Garfield [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 20, 2008 10:51 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] RFC: Traits for PHP
>
> I am unclear on how t
I am unclear on how this:
trait ParseThingie {
protected function parseThingie($thingie) {...}
}
trait ProcessThingie {
protected function parseThingie($thingie) {...}
}
class Thingies {
use ParseThingie;
use ProcessThingie;
}
allows more opportunity for confusion and clashes than this:
Because then you get into similar problems as with multiple inheritance
when you have property clashes and other issues.
The reason why private is beneficial and different because it will allow
you to develop self contained functionality which can be attached to
random classes. This can be quite us
On Wednesday 20 February 2008, Andi Gutmans wrote:
> a)
> I think Traits should be able to act as a self-contained behavior which can
> always be expected to work. For example if I want a Counter behavior I
> would like that not to depend on the properties in the containing class.
> While I don't
Felipe Ribeiro wrote:
Hello,
I've been reading this list for a couple of months and I have a
question that might have already been discussed here before and I
haven't seen, so please apologize me.
My question is if there's any intent to have multi-threading support
to PHP in a future version, l
On Wed, Feb 20, 2008 at 10:36 PM, Felipe Ribeiro <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've been reading this list for a couple of months and I have a
> question that might have already been discussed here before and I
> haven't seen, so please apologize me.
>
> My question is if there's any
Hello,
I've been reading this list for a couple of months and I have a
question that might have already been discussed here before and I
haven't seen, so please apologize me.
My question is if there's any intent to have multi-threading support
to PHP in a future version, like PHP7.
I know multi-
Hi Stefan,
Thanks for writing such a good proposal.
In general I think traits is a very interesting idea. I can think of a few
cases in my life as a programmer where it could have helped me out.
I think some comments re: the syntax/naming are good ones but I prefer not to
get into naming in thi
John Campbell schreef:
On Tue, Feb 19, 2008 at 3:54 PM, Jochem Maas <[EMAIL PROTECTED]> wrote:
how about 'possesses' or 'exhibits' - both these words are closer to the
natural language usage of 'trait' with regard to a subject.
John exhibits a trait
Jack possesses a trait
a person co
Steph Fox wrote:
> Rob's download page is at http://ctindustries.net/libxml/ if anyone
> needs to update their libxml copy locally.
Another thing: make sure you update your libxml def file to CVS HEAD;
otherwise the xsl build will break.
--
Edward Z. YangGnuPG: 0x869C48D
hi,
why isn't it possible to assign class constants like this:
class test
{
const
DIR='dirname'.DIRECTORY_SEPARATOR.'anotherdirname'.DIRECTORY_SEPARATOR;
}
is there some performance issue?
anyone ever tried this or was there a discussion about it? i would find this
very useful.
On 20.02.2008, at 21:43, Stefan Marr wrote:
If we feel it gets necessary we probbaly
might want to support a syntax like:
'trait_method' => false
'trait_method' => 'new_name'
'trait_method' => array('new_name', 'trait_method'
I'm not comfortable with this notation, since it strengthens the
imp
On 20 Feb 2008, at 20:28, Lars Strojny wrote:
Am Mittwoch, den 20.02.2008, 20:14 + schrieb Geoffrey Sneddon:
[...]
Is there any reason why we cannot support multiple inheritance (which
some other languages already do)? The only thing that needs to be
clearly defined is sorting order. This
Marcus, Jochem,
Although I agree with the general idea, I feel strongly against
possesses, mainly because for a non-native english speaker it's a pita
to write and will (and I'm sure of this) *very* often be misspelled
(leading to general annoyances while debugging). I can't give any better
f
> If we feel it gets necessary we probbaly
> might want to support a syntax like:
> 'trait_method' => false
> 'trait_method' => 'new_name'
> 'trait_method' => array('new_name', 'trait_method'
I'm not comfortable with this notation, since it strengthens the
impression that it is renaming.
In my
Hi Geoffrey,
Am Mittwoch, den 20.02.2008, 20:14 + schrieb Geoffrey Sneddon:
[...]
> Is there any reason why we cannot support multiple inheritance (which
> some other languages already do)? The only thing that needs to be
> clearly defined is sorting order. This avoids trying to create som
Hi!
Is there any reason why we cannot support multiple inheritance (which
Yes, there is. Ambiguity.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubsc
On Tue, Feb 19, 2008 at 3:54 PM, Jochem Maas <[EMAIL PROTECTED]> wrote:
> how about 'possesses' or 'exhibits' - both these words are closer to the
> natural language usage of 'trait' with regard to a subject.
>
> John exhibits a trait
> Jack possesses a trait
>
> a person coming accross '
Hello Stefan,
the biggest issue here is that renaming is still possible. So meanwhile I
think that the best approach would be to only allow a method to be inherited
as private. So instead of hiding a method completely you get it as a private
one. Thus if it collides with an interface you get an
Hi!
if we go the route of allowing that, then we have to do some protocl
checks. Meaning if a renamed/aliased method will become an implementation of
an abstract method then of course it has to be compatible. The beigger
I'm kind of confused on a use case for that. Suppose you have trait TFo
Hi Marcus,
Am Mittwoch, den 20.02.2008, 20:59 +0100 schrieb Marcus Boerger:
[...]
> so at th eend of the day users will get renaming and will abuse it.
I disagree here. I think aliasing is fundamental to traits. If we think
of traits as buckets of functionality, the concrete structure of the
tr
On 20 Feb 2008, at 07:46, Sebastian Bergmann wrote:
Lars Strojny schrieb:
I think also for the sake of conceptual integrity separating
interfaces clearly from traits is a good idea
Interfaces are about (multiple) interface inheritance and traits are
about (multiple) implementation inheritan
Hello Stanislav,
if we go the route of allowing that, then we have to do some protocl
checks. Meaning if a renamed/aliased method will become an implementation of
an abstract method then of course it has to be compatible. The beigger
problem I assume you have in mind as well is that replace migh
Hello Jochem,
good arguments. And good ideas. I'd favor 'posesses' then.
marcus
Tuesday, February 19, 2008, 9:54:09 PM, you wrote:
> firstly, I'd like to reiterate the general sentiment
> that Stefans RFC is blinding! (that's a good thing in this context ;-)
> Marcus Boerger schreef:
>> Hell
Hello Stefan,
so at th eend of the day users will get renaming and will abuse it.
That said I am wondering if at the beginning we might want to do Traits
without aliasing and dropping. If we feel it gets necessary we probbaly
might want to support a syntax like:
'trait_method' => false
'trai
Hi,
I've updated the RFC on several sections to reflect the discussion on this list.
The following parts have been changed or added:
- introduced explicit description of abstract methods to be used as
requirements
specification for traits (useful to access state)
- moved part about inter
Hi Markus,
Am Mittwoch, den 20.02.2008, 12:13 +0100 schrieb Markus Fischer:
[...]
> generally asking, how would Reflection act on traits? Can this be
> detected or will the information be lost after a class has been
> assembled? E.g. detect if a certain method comes from a trait and which one?
Markus Fischer wrote:
generally asking, how would Reflection act on traits? Can this be
detected or will the information be lost after a class has been
assembled? E.g. detect if a certain method comes from a trait and which
one?
Dammit, sorry, I didn't intended to send it to all individuals.
Hi,
generally asking, how would Reflection act on traits? Can this be
detected or will the information be lost after a class has been
assembled? E.g. detect if a certain method comes from a trait and which one?
lG
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 19 February 2008 21:03, [EMAIL PROTECTED] advised:
> Hi Marcus,
> Hi Troels,
>
>> The biggest issue I see is finding a syntax everyone likes.
> Well, lets try some variations.
>
> [2a] ! is not readable --> except
> use Trait {
> except foo1, foo2;
> bar => foo1
> }
>
> [2b] ! is not rea
Hi Derick,
> 1. can traits be put in a file of their own (I assume so actually)
> 2. can traits be autoloaded?
yes, since traits are zend_class_entrys with ce_flags set to
ZEND_ACC_TRAIT in the current implementation, they will follow the
same rules for definition and autoloading like classes.
Ki
On Mon, 18 Feb 2008, [EMAIL PROTECTED] wrote:
> Thank you for your attention and I'm looking forward to hear your comments
And thank you for this very detailed proposal, I wish most other feature
proposals were like this. I like the concept, it seems to solve some
of the problems we had to hack
On Mon, 18 Feb 2008, Richard Lynch wrote:
> On Mon, February 18, 2008 1:27 pm, [EMAIL PROTECTED] wrote:
> > > trait ezcReflectionReturnInfo {
> >function getReturnType() { /*1*/ }
> >function getReturnDescription() { /*2*/ }
> > }
> >
> > class ezcReflectionMethod extends ReflectionMe
Hi Lukas,
Am Dienstag, den 19.02.2008, 20:09 +0100 schrieb Lukas Kahwe Smith:
[...]
> I really like what Stefan did here with his traits RFC. Very solid
> work, even if there are still some people not convinced if they want
> this feature in, I have seen little complaints about the way this
Hi Lukas,
Am Mittwoch, den 20.02.2008, 09:44 +0100 schrieb Lukas Kahwe Smith:
[...]
> Maybe its best to first leave out interfaces/abstract etc. Start
> simple, see how things get used, get more comfortable with the feature
> and then see about potentially expanding it.
I totally agree also I
On 20.02.2008, at 09:28, Stefan Marr wrote:
Hi Lars,
What about abstract methods in traits? I think this could be handy to
enforce the user class implement a data getter.
trait Foo {
public function doSomething()
{
return str_replace("foo", "bar", $this->_getString());
}
abstra
Hi Lars,
> What about abstract methods in traits? I think this could be handy to
> enforce the user class implement a data getter.
>
> trait Foo {
>public function doSomething()
>{
>return str_replace("foo", "bar", $this->_getString());
>}
>abstract protected _getString();
Lars Strojny schrieb:
What about abstract methods in traits?
I do not think that this would make sense. Traits are about reusing
code. Abstract methods do not hold concrete code.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09
Hi,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
> Thank you for your attention and I'm looking forward to hear your comments
> :)
What about abstract methods in traits? I think this could be handy to
enforce the user class implement a data getter.
trait Foo {
publ
39 matches
Mail list logo
