After reading a little of this back and forth of annotations,
validation and documentation (oh my). I thought, why not just abstract
the standard types (string, int, bool, etc...) to SPL classes.
This would allow for validation, documentation, casting, and related
functions ( length, substr, etc..
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
Hello,
Yes, this is not an RFC for annotations or to replicate the exact
functionality you wanted within doc comments.
However, there is support based on the annotations thread for "APIs to
parse doc blocks". I don't know what is meant by others (Zeev, Stas,
etc) when they say this. However, in w
On Thu, 16 Sep 2010 21:56:04 +0100, Chad Fulton
wrote:
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 e
hi,
That's nice a nice idea. The PHPDocumentator guys did something to
help the parsing via a pecl's extension
(http://pecl.php.net/docblock). Now, to implement the docbloc parsing
itself will require a parser usage (lemon or whatever else you want),
it will be freaking tricky, not necessary fast
Am 16.09.2010 22:56, schrieb Chad Fulton:
> 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
On Thu Sep 16 02:44 PM, Stas Malyshev wrote:
>
> WTF is "Annotations"? We didn't define it yet. Should PHP support
http://en.wikipedia.org/wiki/.NET_metadata
http://blogs.msdn.com/b/efdesign/archive/2010/03/30/data-annotations-in-the-entity-framework-and-code-first.aspx
.NET calls this attribut
Good reminder, thanks! Implementation would indeed require support
from PHP, say:
// magic-method __decorate implies that __construct would return
$this->__decorate(func_get_args(), $f); and enforce @ as
annotation-syntax
class Dec1 {
function __decorate($args, $f) {
return $f;
}
}
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 s
On 2010-09-16, Guilherme Blanco wrote:
> On Thu, Sep 16, 2010 at 5:07 PM, Stas Malyshev wrote:
> > > Again, you change the meanings of something I write.
> > > I do not want Java Annotations on PHP. But I want a clean way to
> > > include metadata mapping on my class/property/method/function.
> >
Olá!
On Thu, Sep 16, 2010 at 5:07 PM, Stas Malyshev wrote:
> Hi!
>
>> Again, you change the meanings of something I write.
>> I do not want Java Annotations on PHP. But I want a clean way to
>> include metadata mapping on my class/property/method/function.
>
> Everybody wants a clean way to inclu
I know this is drive-by/chiming in, but we've had this discussion with
the ZF community. While @expectedExcpetion is a feature of PHPUnit that
has been picked up and used by developers over the past few years, it
semantically makes no sense, and we have since outlawed its usage.
Why? B/c a "c
Hi!
Again, you change the meanings of something I write.
I do not want Java Annotations on PHP. But I want a clean way to
include metadata mapping on my class/property/method/function.
Everybody wants a clean way to include metadata. It's *what* this way is
where the difference is. So is the
Hi Stas,
On Thu, Sep 16, 2010 at 4:20 PM, Stas Malyshev wrote:
> Hi!
>
>> I mean that any code packer can degrade the the functionality of your
>> app. Example:
>
> Fix your "code packer" not to do that.
>
>> I didn't mean we should stop the discussion. I meant that like many
>> others over the y
Hi!
Overloading comment syntax to modify application functionality is the
worst idea I've seen suggested on this list. This beats goto by miles.
What you mean "suggested"? It's what happening right now in pretty much
any widely used framework.
"Why's my stuff broke? That stack trace leads
Hi!
I mean that any code packer can degrade the the functionality of your
app. Example:
Fix your "code packer" not to do that.
I didn't mean we should stop the discussion. I meant that like many
others over the years lead to nowhere if we don't take the correct
action: vote.
How it's the c
On 09/16/2010 11:44 AM, Stas Malyshev wrote:
> Hi!
>
>> Again, we should not consider docblock mainly because I think
>> adding/removing comments of your code should NEVER modify the overall
>> functionality of your application.
>
> It's a circular argument - "we can't use docblocks because docbl
Hi Stas,
On Thu, Sep 16, 2010 at 3:44 PM, Stas Malyshev wrote:
> Hi!
>
>> Again, we should not consider docblock mainly because I think
>> adding/removing comments of your code should NEVER modify the overall
>> functionality of your application.
>
> It's a circular argument - "we can't use docbl
Am 16.09.2010 18:02, schrieb Matthew Weier O'Phinney:
>
>> in my mind there is a big mistake when using annotations in PHPDoc comments.
> What is the mistake? You don't explain that anywhere in your reply -- you
> simply
> give code examples of how you feel they should work.
>
For me the mistake
Hi!
Again, we should not consider docblock mainly because I think
adding/removing comments of your code should NEVER modify the overall
functionality of your application.
It's a circular argument - "we can't use docblocks because docblocks
shouldn't be used". They are not "comments" if you do
John Coggeshall wrote:
Formality, in any of its forms, is about as far from PHP or this
project as you could possibly get.
SO we wait for features people have been anticipating for years ( unicode would
be nice ;) ) while a few people push through their own agendas simply because
there is no
Hi!
const foo = function () use ($globalVar) {
};
How would you call this thing? foo()? Then you have a problem - foo()
already has meaning, and it's "call function named foo", not "get
constant named foo and call function inside if it's there". Also, it
would work different from variables
On 16/Sep/10 8:49 PM, Stas Malyshev wrote:
No, we can't have python decorators because unlike Python PHP functions
and classes aren't first-class objects. In Python, this:
@dec2
@dec1
def func(arg1, arg2, ...):
pass
means this:
def func(arg1, arg2, ...):
pass
func = dec2(dec1(func))
However,
-1 for the proposed Annotations concept and associated syntax
+1 for adding APIs to parse doc blocks, minor note: should not be not called
"getAnnotations"
On Thu Sep 16 01:01 PM, Lars Schultz wrote:
> +1 for adding APIs to parse doc blocks
> -1 for introducing a new Annotations concept and assoc
On 2010-09-15, Christian Kaps wrote:
> Am 14.09.2010 22:12, schrieb Stas Malyshev:
> > I think we _already_ have metadata in PHP, albeit done through
> > phpdocs. So the question is kind of moot :) We should see if it's
> > enough for us or we want to add/change/extend it and if so, how.
>
> in m
Hi!
This thought is brought on mainly by watching the annotations
drama that is currently occupying internals, does anyone else
agree it might be a good idea to have a slightly more formal
procedure for requesting features and then recording votes pros,
cons, side effects, etc. against it. It mi
Hi!
Could PHP as a language be kept "pure" by first implementing python
decorators*, then implement annotations using a purpose-built
decorator?
No, we can't have python decorators because unlike Python PHP functions
and classes aren't first-class objects. In Python, this:
@dec2
@dec1
def f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16/09/10 18:00, Zeev Suraski wrote:
> At 16:34 16/09/2010, Guilherme Blanco wrote:
>> So the question to be answered is: Should PHP support Annotations?
>
> -1 for introducing a new Annotations concept and associated syntax
>
> +1 for adding APIs
+1 for adding APIs to parse doc blocks
-1 for introducing a new Annotations concept and associated syntax
Am 16.09.2010 18:36, schrieb Wim Godden:
I'm going to say exactly the same thing :
-1 for introducing a new Annotations concept and associated syntax
+1 for adding APIs to parse doc blocks
On 16 September 2010 22:34, Guilherme Blanco wrote:
> So the question to be answered is: Should PHP support Annotations?
-1 on annotations.
+0 on new docblock parsing APIs.
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-Original Message-
From: Zeev Suraski [mailto:z...@zend.com]
Sent: Thursday, September 16, 2010 9:01 AM
To: Guilherme Blanco
Cc: Gustavo Lopes; Derick Rethans; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PHP Annotations RFC + Patch
>+1 for adding APIs to parse doc blocks
>From use
I'm going to say exactly the same thing :
-1 for introducing a new Annotations concept and associated syntax
+1 for adding APIs to parse doc blocks
Zeev Suraski wrote:
At 16:34 16/09/2010, Guilherme Blanco wrote:
So the question to be answered is: Should PHP support Annotations?
-1 for int
+1 for Annotations
2010/9/16 Guilherme Blanco
> Hi Derick,
>
> Again, we should not consider docblock mainly because I think
> adding/removing comments of your code should NEVER modify the overall
> functionality of your application.
> That said, docblock is no option. Now PLEASE let's stop argu
+1 for annotations
-1/2 for parsing comments - it just doesn't seem right
-Original Message-
From: Zeev Suraski [mailto:z...@zend.com]
Sent: 16 September 2010 17:01
To: Guilherme Blanco
Cc: Gustavo Lopes; Derick Rethans; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PHP Annotations
On Thu, 16 Sep 2010 15:34:05 +0100, Guilherme Blanco
wrote:
Hi Derick,
Again, we should not consider docblock mainly because I think
adding/removing comments of your code should NEVER modify the overall
functionality of your application.
That said, docblock is no option. Now PLEASE let's sto
At 16:34 16/09/2010, Guilherme Blanco wrote:
So the question to be answered is: Should PHP support Annotations?
-1 for introducing a new Annotations concept and associated syntax
+1 for adding APIs to parse doc blocks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
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 16
>
> So the question to be answered is: Should PHP support Annotations?
>
> I'm +1.
>
+1
Greetings,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Derick,
Again, we should not consider docblock mainly because I think
adding/removing comments of your code should NEVER modify the overall
functionality of your application.
That said, docblock is no option. Now PLEASE let's stop arguing for
nothing and vote?
I'd recommend that since syntax is
On Thu, 16 Sep 2010 14:57:01 +0100, Derick Rethans wrote:
There should be overwhelmingly strong reasons to add a whole new branch
of syntax to PHP, I for one don't see the huge gain annotations bring
on top of PHPDoc.
The only thing I can think of is added the storing of docblock data for
On Mon, 13 Sep 2010, Zeev Suraski wrote:
> I'm not sure we've seen a good reason to add annotations instead of using
> PHPDoc. Sure, PHPDoc isn't a perfect fit for certain purposes, but I think it
> certainly falls in the good-enough fit for most purposes. It's also both
> machine and human read
On Wed, Sep 15, 2010 at 5:27 PM, Arvids Godjuks
wrote:
> Hi all.
>
> As a user land developer and active reader (and some times poster) for
> a few years now this is the first time I trully don't understand what
> the hell are you talking about and what are annotations at all and
> what will be th
Tangent:
Could PHP as a language be kept "pure" by first implementing python
decorators*, then implement annotations using a purpose-built
decorator?
@annotate(PHP-code-goes-here)
function framework_call(request) { ... }
* http://www.python.org/dev/peps/pep-0318/
--
PHP Internals - PHP Runtime
Sorry for the formatting, I'm not sure why the newlines got removed since I
formatted this much more nicely, any reason why it happened? I could repost it
in a more readble format
> From: jb_j...@hotmail.com
> To: internals@lists.php.net
> Date: Thu, 16 Sep 2010 09:56:59 +
> Subject: [PHP-D
Hey guys (and girls),
I have been reading this list for sometimebut this is the first time I'm
actually posting something.This might fit better in a C\C++ forum but I base my
question on the notion that I confidence in my C skills and that there is an
underlying cause for the choice of PHP deve
On 16 September 2010 16:40, Aleksei Sapunov wrote:
> Hi,
> Yes, you right. But [] are used in arrays definition. If take in to account
> that format with @ is more readable?
>
> Is it a problem to implement it using @ symbol?
If we're down to bickering about the finer points of the syntax, can
we
Hi,
Yes, you right. But [] are used in arrays definition. If take in to account
that format with @ is more readable?
Is it a problem to implement it using @ symbol?
2010/9/16 Christian Kaps
> Hi,
>
> it's reserved for the error control
> operator(http://www.php.net/manual/en/language.operators.
On Thu, 16 Sep 2010 10:10:21 +0200, Frederic Hardy
wrote:
> Hello !
>> This thought is brought on mainly by watching the annotations drama that is
>> currently occupying internals, does anyone else agree it might be a good
>> idea to have a slightly more formal procedure for requesting features
Hi,
it's reserved for the error control
operator(http://www.php.net/manual/en/language.operators.errorcontrol.php).
Greetings,
Christian
On Thu, 16 Sep 2010 11:26:51 +0300, Aleksei Sapunov
wrote:
> Hello all,
> Only today see that here is very intersting discussion.
> I have a question: why was
Hello all,
Only today see that here is very intersting discussion.
I have a question: why was choosed exactly this format (seems like c#-like,
not java-like)?
Simply [] is used for arrays. Why not use @ at annotation name?
2010/9/16 Pierre Joye
> On Wed, Sep 15, 2010 at 10:27 PM, Arvids Godjuks
On Wed, Sep 15, 2010 at 10:27 PM, Arvids Godjuks
wrote:
> P.S. Personally I would take the energy boiling in this thread and
> throw it at solving the windows biuld and PECL problem. Right now you
> can't install PHP 5.2 and apache on a Windows 7 - it just crashes
> totally.
Where are the bugs r
Hello !
This thought is brought on mainly by watching the annotations drama that is
currently occupying internals, does anyone else agree it might be a good idea
to have a slightly more formal procedure for requesting features and then
recording votes pros, cons, side effects, etc. against it.
On Thu, Sep 16, 2010 at 5:10 AM, John Coggeshall wrote:
> Formality, in any of its forms, is about as far from PHP or this
> project as you could possibly get.
Living in the past is never a good thing.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals -
On Wed, Sep 15, 2010 at 10:27 PM, Arvids Godjuks
wrote:
> Hi all.
>
> As a user land developer and active reader (and some times poster) for
> a few years now this is the first time I trully don't understand what
> the hell are you talking about and what are annotations at all and
> what will be t
54 matches
Mail list logo
