.
If you haven't already, I recommend you read the (incredibly long)
discussions from last summer on type-hinting. They convinced me that
sometimes a feature that sounds good is simply not a good fit for PHP
for reasons which many did not (still do not?) understand.
Chad Fulton
--
PHP Internals
On Mon, May 9, 2011 at 10:46 PM, Lester Caine les...@lsces.co.uk wrote:
*IS* it clear by now that the majority of users want this?
For what it's worth, I still oppose Annotations.
And the argument
that 'You don't have to use it' does not wash either since once it has been
pushed in, some of
On Tue, May 10, 2011 at 12:35 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi all,
Based on an extensive chat with Matthew, I think we reached some consensus.
I'll write another RFC related to Annotations in docblocks, then we
can chat until reach some standardization and
Hello!
While I personally like PHP's substr() an awful lot and doubt I would
use the str_slice() method, I thought I'd mention that I think what
you're proposing is much like the string.substring(from, to) method in
Javascript (and PHP's current substr() function is an awful lot like
Javascript's
Hello,
On Wed, Mar 9, 2011 at 10:02 AM, Jarrod Nettles jnett...@inccrra.org wrote:
Interesting question. My gut tells me not (as does three years of C#
experience). I’m sure that everyone will have a different opinion on this but
to me it seems taboo that a child class override the
Take this with a grain of salt, but:
On Thu, Jan 13, 2011 at 7:22 AM, Martin Scotta martinsco...@gmail.com wrote:
Hi all,
I don't know how the internal development process of PHP works.
First at all: was this feature approved?
From my experience, don't consider something approved until it's
On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe quickshif...@gmail.com wrote:
On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl m4r...@gmail.com wrote:
First i have to say that I am not a PHP internals developer, but as a user
I think it would maybe be better to just let the trait use the
On Fri, Dec 10, 2010 at 10:39 AM, Nathan Nobbe quickshif...@gmail.com wrote:
On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton chadful...@gmail.com wrote:
On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe quickshif...@gmail.com
wrote:
On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl m4r
On Fri, Dec 10, 2010 at 1:00 PM, Nathan Nobbe quickshif...@gmail.com wrote:
As a note, I'm not strongly opposed to this proposal, since I don't
think it would do any harm. It just seems to me like a kitchen sink
feature.
The issue for me is that traits, as I understand them, are there
Having thought a bit about this, there are a couple of initial
problems I see, and, more importantly, I'm not convinced that the
stated problem (encapsulation) requires the addition of a new language
construct (i.e. a property as distinct from a class member). In
fact, I think it is better
On Sun, Nov 28, 2010 at 11:48 PM, Christian Kaps
christian.k...@mohiva.com wrote:
...
/**
*
*/
public function set name(string $name) {
$this-name = htmlentities($name);
$this-name = strip_tags($this-name);
}
/**
*
*/
public function get name($name) {
return $this-name;
On Tue, Nov 16, 2010 at 6:03 AM, Lars Schultz lars.schu...@toolpark.com wrote:
Hi,
I certainly don't have PHP-Karma (Does meritocracy really refer to that?),
but simply I can't believe that you're talking about this, again.
I think Annotation-Supporters have made their point, but shouldn't
For me, the syntax, or at least the complexity, is important. I like
the idea of metadata, but what I found attractive about the docBlock
parsing was that it only allowed key/value pairs of meta-data.
-1 for annotations in which the engine instantiates arbitrary
annotation objects.
On Thu, Sep
Hello,
Based on comments from the annotations thread, I have created a
docBlock parser RFC at http://wiki.php.net/rfc/docblockparser
This RFC does not deal with annotations per se, but only with the idea
of adding a function to the Reflection extension which would parse
docBlocks according to a
way, I think this would be a nice thing to have.
Thanks,
Chad
On Thu, Sep 16, 2010 at 3:34 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Thu, 16 Sep 2010 21:56:04 +0100, Chad Fulton chadful...@gmail.com
wrote:
Based on comments from the annotations thread, I have created a
docBlock
Hello!
That is a good point, there would be no file-level doc block in the
RFC. Here is my reasoning for not including it in the RFC:
Since the motivation for this came from the desire for metadata for
PHP structures, it seemed inappropriate to include metadata at the
file level (since it's not a
Since the parsed version of the docblock would only be accessible
through a reflection method, you would have to specifically request it
for it to be parsed and given to you as an object or array. Also, it
would only be parsed, not executed; I don't think that this is
proposing executing comment
anyway .. for the love of god, could be please stop arguing in circles,
nothing .. really nothing that people brought forth pro/con any approach in
regards to type checking/hinting whatever hasn't been mentioned on this list
multiple times.
+1
please please please please .. read the
Hello!
As I mentioned, I think that we have to inform the caller about the problem
(be either a type or a conversion mismatch), so the only options to trigger
an error, or throw an exception.
I like the exception idea better, because it can be easily handled localy
(no need to register a
Hi!
Pretty much everywhere. Suppose you have form with, say, 2 fields and first
field does not validate. Maybe you want to check the second field too and
give the user both errors if they are both wrong?
In general, looking at strict typing as user input validation mechanism is a
very bad
You can take a look at the RFP if you like. It discusses the pros and cons
of various possible separators, and why they chose the backslash.
http://wiki.php.net/rfc/namespaceseparator
http://wiki.php.net/rfc/namespaceseparatorI've been using namespaces for a
few months now with the backslash
21 matches
Mail list logo
