Re: [pdt-dev] code assist development

[Philip Olson]

On Thu, Oct 22, 2009 at 8:34 PM, Sjaak Eenhuis  
 wrote:
Currently, pdt doesn't indicate if a certain function parameter is  
required or optional. As I understand from http://doc.php.net/php/dochowto/chapter-skeletons.php 
 you provide this information allready.


So visually indicating what is required and what not is something  
which can be accomplished already by the pdt developers.


However, as far as I can see the docbook sources don't contain the  
actual default value of such an optional parameter. This would come  
in handy, in cases like


string htmlspecialchars ( string $string [, int $quote_style =  
ENT_COMPAT [, string $charset [, bool $double_encode = true ]]] )


If I want to use htmlspecialchars with ENT_NOQUOTES I want to see  
whether I need to override the default of $quote_style.
I've encoutered this type of issues more than once and this info is  
imho useful enough to have it.


I am curious about your opinions.


On Oct 22, 2009, at 11:41 AM, Michael Spector wrote:
The generated PHP language model does contain an indication about  
optional parameters in PHPDoc and using parameter initializer (if  
you open standard.php you'll see it). The problem is that Code  
Assist doesn't really use this information to present it in a fancy  
style that you mentioned. We can fix it in the future.


I'm not sure what percentage of PHP documentation with optional  
parameters utilizes the  markup, but somewhere between  
80-98%. Your suggestion provides the idea that we should check this  
and ensure proper values (and consistency) throughout the PHP manual,  
and I'll hack something up to check this soon.


I can't speak of PDT specifics but do want to provide IDE developers  
with the most information possible, and this includes default values  
for optional parameters. Maybe one day there will be a universal  
format for this type information that most/all IDEs will share and  
use, with the only difference being how it's presented. Dare to  
dream? :)


Regards,
Philip

___
pdt-dev mailing list
pdt-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/pdt-dev

Re: [pdt-dev] code assist development

[Michael Spector]

The generated PHP language model does contain an indication about optional
parameters in PHPDoc and using parameter initializer (if you open
standard.php you'll see it). The problem is that Code Assist doesn't really
use this information to present it in a fancy style that you mentioned. We
can fix it in the future.


On Thu, Oct 22, 2009 at 8:34 PM, Sjaak Eenhuis wrote:

>  Currently, pdt doesn't indicate if a certain function parameter is
> required or optional. As I understand from
> http://doc.php.net/php/dochowto/chapter-skeletons.php you provide this
> information allready.
>
> So visually indicating what is required and what not is something which can
> be accomplished already by the pdt developers.
>
> However, as far as I can see the docbook sources don't contain the actual
> default value of such an optional parameter. This would come in handy, in
> cases like
>
> string *htmlspecialchars* ( string $string [, int $quote_style =
> ENT_COMPAT [, string $charset [, bool $double_encode = true ]]] )
>
>
> If I want to use htmlspecialchars with* ENT_NOQUOTES* I want to see
> whether I need to override the default of $quote_style.
> I've encoutered this type of issues more than once and this info is imho
> useful enough to have it.
>
> I am curious about your opinions.
>
>
>
> > From: phi...@roshambo.org
> > Date: Mon, 19 Oct 2009 08:38:58 -0700
> > To: pdt-dev@eclipse.org
> > CC: moa...@php.net
> > Subject: [pdt-dev] code assist development
> >
> > Hello,
> >
> > The PHP manual is interested in making the data more friendly to PDT.
> > Please describe exactly how PDT gathers data for 'code assist' so that
> > we can test and help make the process a little easier. Like, do you
> > parse the XML sources? How? What problems do you run into?
> >
> > Regards,
> > Philip
> >
> > ___
> > pdt-dev mailing list
> > pdt-dev@eclipse.org
> > https://dev.eclipse.org/mailman/listinfo/pdt-dev
>
> --
> De nieuwe Windows 7: vind de juiste pc voor jou. Meer 
> informatie.<http://windows.microsoft.com/shop>
>
> ___
> pdt-dev mailing list
> pdt-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/pdt-dev
>
>
___
pdt-dev mailing list
pdt-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/pdt-dev

RE: [pdt-dev] code assist development

[Sjaak Eenhuis]

Currently, pdt doesn't indicate if a certain function parameter is required or 
optional. As I understand from 
http://doc.php.net/php/dochowto/chapter-skeletons.php you provide this 
information allready.

So visually indicating what is required and what not is something which can be 
accomplished already by the pdt developers.

However, as far as I can see the docbook sources don't contain the actual 
default value of such an optional parameter. This would come in handy, in cases 
like

string htmlspecialchars
( string $string
   [, int $quote_style = ENT_COMPAT
   [, string $charset
   [, bool $double_encode = true
  ]]] )

If I want to use htmlspecialchars
with ENT_NOQUOTES I want to see whether I need to override the default of 
$quote_style.
I've encoutered this type of issues more than once and this info is imho useful 
enough to have it.

I am curious about your opinions.



> From: phi...@roshambo.org
> Date: Mon, 19 Oct 2009 08:38:58 -0700
> To: pdt-dev@eclipse.org
> CC: moa...@php.net
> Subject: [pdt-dev] code assist development
> 
> Hello,
> 
> The PHP manual is interested in making the data more friendly to PDT.  
> Please describe exactly how PDT gathers data for 'code assist' so that  
> we can test and help make the process a little easier. Like, do you  
> parse the XML sources? How? What problems do you run into?
> 
> Regards,
> Philip
> 
> ___
> pdt-dev mailing list
> pdt-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/pdt-dev
  
_
De  nieuwe Windows 7: vind de juiste pc voor jou. Meer informatie.
http://windows.microsoft.com/shop___
pdt-dev mailing list
pdt-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/pdt-dev

RE: [pdt-dev] code assist development

[Roy Ganor]

One small thing that comes to my mind is that it should be re-used by others so 
everyone can re-run it later on when further releases of PHP are released.

Thanks for helping out,
Roy
-Original Message-
From: pdt-dev-boun...@eclipse.org [mailto:pdt-dev-boun...@eclipse.org] On 
Behalf Of Philip Olson
Sent: Wednesday, October 21, 2009 5:21 PM
To: PDT Developers
Cc: Moacir de Oliveira Miranda Júnior
Subject: Re: [pdt-dev] code assist development


On Oct 19, 2009, at 9:04 AM, Michael Spector wrote:

> Hi Philip,
>
> We do a real black magic, when generating stubs for all native PHP  
> elements.
> First of all, we use reflection mechanism for building a multi-array  
> of all existing elements. Then we refer to the PHPDoc for the  
> documentation on elements that were found. The problems that we run  
> into are usually:
>
> 1. Reflection doesn't contain needed information (class properties,  
> namespaces, etc...)
> 2. PHPDoc XML is not standard in many cases (constant values, etc...)
> 3. Missing PHPDoc :)
>
> You can look at this script for better understanding of what's  
> happening: 
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.pdt/plugins/org.eclipse.php.core/Resources/language/generate.php?root=Tools_Project&view=markup

Greetings Michael,

We're looking now, and hope to offer tools to make this easier fairly  
soon. There are a few headaches like dealing with functions that are  
both OOP and procedural, and a few others, but overall I think we can  
provide a cleaner solution that parses generated XML as to not worry  
about entity replacements. Moacir has been working on an IDE package  
for PhD. Our build system is named PhD, the system that turns DocBook  
into magic.

What is your policy regarding which extensions get included? It  
appears to be "all that we can possibly find" which is understandable  
but maybe an official policy exists.

And while running generate.php I stumbled upon a bug in PHP. The  
get_defined_constants(true) internal constants are labeled as 'Core'  
instead of 'internal' in PHP 5.3.0. And while some feel 'Core' is  
better (more consistent, like with Reflection), it appears it'll be  
changed back to 'internal' so anyway that's that.

Regards,
Philip


___
pdt-dev mailing list
pdt-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/pdt-dev
___
pdt-dev mailing list
pdt-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/pdt-dev

Re: [pdt-dev] code assist development

[Michael Spector]

Hi Philip,

We don't have any policy regarding which extensions get included - all the
extensions enabled at the generation time are included.

Best regards,
Michael

2009/10/22 Philip Olson 

>
> On Oct 19, 2009, at 9:04 AM, Michael Spector wrote:
>
>  Hi Philip,
>>
>> We do a real black magic, when generating stubs for all native PHP
>> elements.
>> First of all, we use reflection mechanism for building a multi-array of
>> all existing elements. Then we refer to the PHPDoc for the documentation on
>> elements that were found. The problems that we run into are usually:
>>
>> 1. Reflection doesn't contain needed information (class properties,
>> namespaces, etc...)
>> 2. PHPDoc XML is not standard in many cases (constant values, etc...)
>> 3. Missing PHPDoc :)
>>
>> You can look at this script for better understanding of what's happening:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.pdt/plugins/org.eclipse.php.core/Resources/language/generate.php?root=Tools_Project&view=markup
>>
>
> Greetings Michael,
>
> We're looking now, and hope to offer tools to make this easier fairly soon.
> There are a few headaches like dealing with functions that are both OOP and
> procedural, and a few others, but overall I think we can provide a cleaner
> solution that parses generated XML as to not worry about entity
> replacements. Moacir has been working on an IDE package for PhD. Our build
> system is named PhD, the system that turns DocBook into magic.
>
> What is your policy regarding which extensions get included? It appears to
> be "all that we can possibly find" which is understandable but maybe an
> official policy exists.
>
> And while running generate.php I stumbled upon a bug in PHP. The
> get_defined_constants(true) internal constants are labeled as 'Core' instead
> of 'internal' in PHP 5.3.0. And while some feel 'Core' is better (more
> consistent, like with Reflection), it appears it'll be changed back to
> 'internal' so anyway that's that.
>
> Regards,
> Philip
>
>
> ___
> pdt-dev mailing list
> pdt-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/pdt-dev
>
___
pdt-dev mailing list
pdt-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/pdt-dev

Re: [pdt-dev] code assist development

[Philip Olson]

On Oct 19, 2009, at 9:04 AM, Michael Spector wrote:


Hi Philip,

We do a real black magic, when generating stubs for all native PHP  
elements.
First of all, we use reflection mechanism for building a multi-array  
of all existing elements. Then we refer to the PHPDoc for the  
documentation on elements that were found. The problems that we run  
into are usually:


1. Reflection doesn't contain needed information (class properties,  
namespaces, etc...)

2. PHPDoc XML is not standard in many cases (constant values, etc...)
3. Missing PHPDoc :)

You can look at this script for better understanding of what's  
happening: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.pdt/plugins/org.eclipse.php.core/Resources/language/generate.php?root=Tools_Project&view=markup


Greetings Michael,

We're looking now, and hope to offer tools to make this easier fairly  
soon. There are a few headaches like dealing with functions that are  
both OOP and procedural, and a few others, but overall I think we can  
provide a cleaner solution that parses generated XML as to not worry  
about entity replacements. Moacir has been working on an IDE package  
for PhD. Our build system is named PhD, the system that turns DocBook  
into magic.


What is your policy regarding which extensions get included? It  
appears to be "all that we can possibly find" which is understandable  
but maybe an official policy exists.


And while running generate.php I stumbled upon a bug in PHP. The  
get_defined_constants(true) internal constants are labeled as 'Core'  
instead of 'internal' in PHP 5.3.0. And while some feel 'Core' is  
better (more consistent, like with Reflection), it appears it'll be  
changed back to 'internal' so anyway that's that.


Regards,
Philip


___
pdt-dev mailing list
pdt-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/pdt-dev

Re: [pdt-dev] code assist development

[Michael Spector]

Hi Philip,
We do a real black magic, when generating stubs for all native PHP elements.
First of all, we use reflection mechanism for building a multi-array of all
existing elements. Then we refer to the PHPDoc for the documentation on
elements that were found. The problems that we run into are usually:

1. Reflection doesn't contain needed information (class properties,
namespaces, etc...)
2. PHPDoc XML is not standard in many cases (constant values, etc...)
3. Missing PHPDoc :)

You can look at this script for better understanding of what's happening:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.pdt/plugins/org.eclipse.php.core/Resources/language/generate.php?root=Tools_Project&view=markup

Thanks
for the interest!
Michael

2009/10/19 Philip Olson 

> Hello,
>
> The PHP manual is interested in making the data more friendly to PDT.
> Please describe exactly how PDT gathers data for 'code assist' so that we
> can test and help make the process a little easier. Like, do you parse the
> XML sources? How? What problems do you run into?
>
> Regards,
> Philip
>
> ___
> pdt-dev mailing list
> pdt-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/pdt-dev
>
___
pdt-dev mailing list
pdt-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/pdt-dev

[pdt-dev] code assist development

[Philip Olson]

Hello,

The PHP manual is interested in making the data more friendly to PDT.  
Please describe exactly how PDT gathers data for 'code assist' so that  
we can test and help make the process a little easier. Like, do you  
parse the XML sources? How? What problems do you run into?


Regards,
Philip

___
pdt-dev mailing list
pdt-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/pdt-dev