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();
}
class
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());
}
abstract
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
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 {
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
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.
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 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 readable --
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,
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,
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
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
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
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
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:
Hello
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!
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
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 some
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 eyes it
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
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
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 'use' or
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
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
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
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.
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: 0x869C48DA
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
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
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
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 intent
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,
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
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
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 this:
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:
38 matches
Mail list logo
