Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52189
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type:content-transfer-encoding;
        b=lAzK0Q+T5pxxkvnHVe34g15IWhQlgtVom3LPg0mj/LaH19O6i5IfKIHN/Q3mYbNiq/
         eD70xrjNhNC32JYoKM1K724Kc4Xoghzo8Ib5q/iud+atXPgorZIT0YNPqTYrx1Dg4tHW
         ibjps5bLfyEHxOWKU1Hl0tHyRa4yKNXqahIYo=
MIME-Version: 1.0
In-Reply-To: <4DC88602.30400@lsces.co.uk>
References: <BANLkTinO0h7020fs+PLjM0fUmMjQXoTsyw@mail.gmail.com>
 <BANLkTim8p7A5+svvjZw6rc_KE+tBMnOsjw@mail.gmail.com> <4DC826B1.4090806@lerdorf.com>
 <BANLkTikpLY+AntSrNi91rzGNZi4FkPrSwA@mail.gmail.com> <4DC82A36.8090604@lerdorf.com>
 <BANLkTi=aLVw8KqOV_jb9dBm=XqX6TqTVwA@mail.gmail.com> <4DC85FBE.2060005@lsces.co.uk>
 <BANLkTikH4H140xh8YLL_J+3dUS6UQAozhw@mail.gmail.com> <4DC88602.30400@lsces.co.uk>
Date: Mon, 9 May 2011 21:35:49 -0300
Message-ID: <BANLkTikbCWS7q0MzzyML=XkGPpzK1ya7fg@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Please let's not bitch about lazy users not learning C
 to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

Hi Lester,

What you don't see is that you're against having it because you
already had the effort to built this support.
So answering your question related to use cases, you own codebase is a
good example.

You had to create a parser for docblock because PHP doesn't have
support. And now you're asking me why is it needed because you already
implemented it. It's like chicken and eggs.
You wouldn't need to implement a docblock parser IF PHP already supported i=
t.

Also, you own comments answer you own question. You "compile" your
code for production removing the docblocks (or adding a cache, or
generating a file, etc, whatever you want). What does it prohibit you
from doing the same with native support?


Regards,

On Mon, May 9, 2011 at 9:25 PM, Lester Caine <lester@lsces.co.uk> wrote:
> guilhermeblanco@gmail.com wrote:
>>
>> Hi Lester,
>>
>> I updated the RFC. I may have missed one thing or two, but overall
>> idea and how code behave is there.
>> This question is answered on wiki RFC. =3D)
>>
>> Here is the direct link: https://wiki.php.net/rfc/annotations
>
> But there is nothing there that explains why this is any use where we are
> not compiling code ... and are all things we are already doing with comme=
nt
> blocks ... which CAN be stripped to speed up operation once in a producti=
on
> environment. A compiler simply strips the unnecessary stuff when building
> the running code, how do you propose PHP does that ? If I want compiled c=
ode
> then I can use any number of other languages, PHP simply runs what I have=
 in
> the file.
>
>> Regards,
>>
>> On Mon, May 9, 2011 at 6:42 PM, Lester Caine<lester@lsces.co.uk> =C2=A0w=
rote:
>>>
>>> guilhermeblanco@gmail.com wrote:
>>>>
>>>> What I thought it could be changed is:
>>>> - Allow PHP to support it natively and also take advantage of opcode
>>>> cache
>>>> - Make API cleaner
>>>
>>> Guilherme you still also have to explain WHY we need this. I have a
>>> perfectly functional documentation and hinting setup working from
>>> docblock
>>> entries in several years worth of code. Rewriting all of that would hav=
e
>>> to
>>> have some reason, and working with two systems in parallel does not mak=
e
>>> sense. My current method of working is well supported in phpeclipse whi=
le
>>> your new offering will require some major work in phpeclipse and other
>>> tools
>>> simply to access it? More work for other open source developers who aga=
in
>>> probably don't need it. So as far as I am concerned I need to be
>>> persuaded
>>> why this code needs to be IN the core code when I for one can't see any
>>> reason to use it. Just because COMPILED languages have it is not a reas=
on
>>> to
>>> load an interpreted language with it. Adding it as a removable extensio=
n
>>> might make more sense to me, just as much of the less used code can be
>>> disabled if we want. And I was coding in C/C++ long before I switched T=
O
>>> PHP
>>> to get away from the problems of using compiled languages for dynamic w=
eb
>>> based systems.
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=3Dcontact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--=20
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
S=C3=A3o Paulo - SP/Brazil