librelist archives

« back to archive

Road Map

Road Map

From:
Devon Weller
Date:
2013-04-24 @ 13:05
Here is a beginning road map of the project:

https://github.com/deweller/PHPCodeIntel/wiki/Road-Map


- Devon

Road Map

From:
Stefano F. Rausch
Date:
2013-04-24 @ 14:27
Hi Devon,

I had a look at your Road Map and have the following suggestions:

v0.1 – scan project command : I would like to avoid for the user to have 
to ( actively ) scan the project files. Even, if an initial ( manual ) 
setup is more time consuming, directories to include / exclude in the 
automatic background scanning service ( make it as simple as possible for 
users to work with the plugin ) should be declared in the user package 
preferences settings – see v0.4. IMHO this point should not be delayed, 
but be first priority.

Reason being : even if this first version will be a proof of concept 
"only", it should be usable from day 1. The earlier the plugin can be used
the higher the chances of adoption and the more feedback we will receive 
to be able to improve the code base on a frequent basis. Release often 
should be obligatory.

v0.2 – completion support : should include protected variables to. Think 
of inheritance.

v0.3 – lookups : should be done in Python to minimise the roundtrip time 
for the plugin to execute.

Furthermore, we should agree on using the .editorconfig plugin to 
standardise the formatting rules. In this context : shall we start with 
the Coding Guidelines first and then / in parallel discuss the design ( 
patterns to use )?

Again, good start!

Cheers

--

Stefano F. Rausch

Re: [phpcodeintel] Road Map

From:
Devon Weller
Date:
2013-04-24 @ 14:58
Stefano,

Good thoughts.


I totally agree that manually triggered scans is not how we want this to 
work.  But I think at least one initial manual scan may necessary for each
project.  After that, perhaps we can update each individual file based on 
a save event.  

A scanning service would be super nice.  But I expect that will add 
additional challenges.  I see that as coming later in the roadmap.


Agreed about protected variables and methods for inherited classes.


I know very little about Python, especially in Sublime.  Does it come with
SQLite built in by chance?  Can we read an SQLite file with python?  The 
other option is to run a daemon that loads the index file into memory and 
then responds with autocomplete suggestions.  That should be very fast.


As for coding, let's just use PSR-2 since it is a standard that is easy to
define.  There is even a sublime plugin for it:

https://github.com/benmatselby/sublime-phpcs

I'm not an .editorconfig user, but I think PSR-2 covers all the formatting rules.


- Devon


On Apr 24, 2013, at 9:27 AM, Stefano F. Rausch <stefano@rausch-e.net> wrote:

> Hi Devon,
> 
> I had a look at your Road Map and have the following suggestions:
> 
> v0.1 – scan project command : I would like to avoid for the user to have
to ( actively ) scan the project files. Even, if an initial ( manual ) 
setup is more time consuming, directories to include / exclude in the 
automatic background scanning service ( make it as simple as possible for 
users to work with the plugin ) should be declared in the user package 
preferences settings – see v0.4. IMHO this point should not be delayed, 
but be first priority.
> 
> Reason being : even if this first version will be a proof of concept 
"only", it should be usable from day 1. The earlier the plugin can be used
the higher the chances of adoption and the mor e feedback we will receive 
to be able to improve the code base on a frequent basis. Release often 
should be obligatory.
> 
> v0.2 – completion support : should include protected variables to. Think
of inheritance.
> 
> v0.3 – lookups : should be done in Python to minimise the roundtrip time
for the plugin to execute.
> 
> Furthermore, we should agree on using the .editorconfig plugin to 
standardise the formatting rules. In this context : shall we start with 
the Coding Guidelines first and then / in parallel discuss the design ( 
patterns to use )?
> 
> Again, good start!
> 
> Cheers
> 
> --
> 
> Stefano F. Rausch
> 

Re: [phpcodeintel] Road Map

From:
Stefano F. Rausch
Date:
2013-04-24 @ 18:59
Well,

One can skip the manual scan : if the plugin realises that a project has 
not been scanned, i.e. it just has been added to the user package 
preferences settings ( PPS ), it should initiate a scanning process 
accordingly. To be more specific, PCI ( PHPCodeIntel ) should check the 
PPS before running the scanning process timer-wise. Furthermore, the 
plugin should watch the PPS for any changes and act accordingly.

It should not be very difficult to implement a respective "service". See 
above. Multi-Threading / Sub-Processing do spring in mind.

I'm not aware of ST having SQLite built in … However, 
http://docs.python.org/2/library/sqlite3.html and 
http://www.blog.pythonlibrary.org/2012/07/18/python-a-simple-step-by-step-sqlite-tutorial/
should be a good start ;)

PSR-2 is fine with me. .editorconfig just supports some of the mandatory 
styles and it does not hurt to add it to the project. It's up to the 
members to use the EditorConfig plugin … I will.

--

Stefano


On 24 Apr 2013, at 16:58, Devon Weller <dweller@devonweller.com> wrote:

Stefano,

Good thoughts.


I totally agree that manually triggered scans is not how we want this to 
work.  But I think at least one initial manual scan may necessary for each
project.  After that, perhaps we can update each individual file based on 
a save event.  

A scanning service would be super nice.  But I expect that will add 
additional challenges.  I see that as coming later in the roadmap.


Agreed about protected variables and methods for inherited classes.


I know very little about Python, especially in Sublime.  Does it come with
SQLite built in by chance?  Can we read an SQLit e file with python?  The 
other option is to run a daemon that loads the index file into memory and 
then responds with autocomplete suggestions.  That should be very fast.


As for coding, let's just use PSR-2 since it is a standard that is easy to
define.  There is even a sublime plugin for it:

https://github.com/benmatselby/sublime-phpcs

I'm not an .editorconfig user, but I think PSR-2 covers all the formatting rules.


- Devon


On Apr 24, 2013, at 9:27 AM, Stefano F. Rausch <stefano@rausch-e.net> wrote:

> Hi Devon,
> 
> I had a look at your Road Map and have the following suggestions:
> 
> v0.1 – scan project command : I would like to avoid for the user to have
to ( actively ) scan the project files. Even, if an initial ( manual ) 
setup is more time consuming, directories to include / exclude in the 
automatic background scanning service ( make it as simple as possible for 
users to work with the plugin ) should be declared in the user package 
preferences settings – see v0.4. IMHO this point should not be delayed, 
but be first priority.
> 
> Reason being : even if this first version will be a proof of concept 
"only", it should be usable from day 1. The earlier the plugin can be used
the higher the chances of adoption and the mor e feedback we will receive 
to be able to improve the code base on a frequent basis. Release often 
should be obligatory.
> 
> v0.2 – completion support : should include protected variables to. Think
of inheritance.
> 
> v0.3 – lookups : should be done in Python to minimise the roundtrip time
for the plugin to execute.
> 
> Furthermore, we should agree on using the .editorconfig plugin to 
standardise the formatting rules. In this context : shall we start with 
the Coding Guidelines first and then / in parallel discuss the design ( 
patterns to use )?
> 
> Again, good start!
> 
> Cheers
> 
> --
> 
> Stefano F. Rausch
> 

Re: [phpcodeintel] Road Map

From:
Stefano F. Rausch
Date:
2013-04-24 @ 19:37
Here is my .editorconfig file I am currently using across all my projects:

# Project's standard editor configuration file.
# @version 0.1.0+build.20130313105605

root = true # Stop searching for an EditorConfig.org file to apply.

[*] # Settings for all files.

charset = utf-8

indent_style = space
indent_size = 4

trim_trailing_whitespace = true

## Unix-style newlines and file ending.

end_of_line = lf
insert_final_newline = true

--

Stefano


On 24 Apr 2013, at 20:59, Stefano F. Rausch <stefano@rausch-e.net> wrote:

Well,

One can skip the manual scan : if the plugin realises that a project has 
not been scanned, i.e. it just has been added to the user package 
preferences settings ( PPS ), it should initiate a scanning process 
accordingly. To be more specific, PCI ( PHPCodeIntel ) should check the 
PPS before running the scanning process timer-wise. Furthermore, the 
plugin should watch the PPS for any changes and act accordingly.

It should not be very difficult to implement a respective "service". See 
above. Multi-Threading / Sub-Processing do spring in mind.

I'm not aware of ST having SQLite built in … However, 
http://docs.python.org/2/library/sqlite3.html and 
http://www.blog.pythonlibrary.org/2012/07/18/python-a-simple-step-by-step-sqlite-tutorial/
should be a good start ;)

PSR-2 is fine with me. .editorconfig just supports some of the mandatory 
styles and it does not hurt to add it to the project. It's up to the 
members to use the EditorConfig plugin … I will.

--

Stefano


On 24 Apr 2013, at 16:58, Devon Weller <dweller@devonweller.com> wrote:

Stefano,

Good thoughts.


I totally agree that m anually triggered scans is not how we want this to 
work.  But I think at least one initial manual scan may necessary for each
project.  After that, perhaps we can update each individual file based on 
a save event.  

A scanning service would be super nice.  But I expect that will add 
additional challenges.  I see that as coming later in the roadmap.


Agreed about protected variables and methods for inherited classes.


I know very little about Python, especially in Sublime.  Does it come with
SQLite built in by chance?  Can we read an SQLit e file with python?  The 
other option is to run a daemon that loads the index file into memory and 
then responds with autocomplete suggestions.  That should be very fast.


As for coding, let's just use PSR-2 since it is a standard that is easy to
define.  There is even a sublime plugin for it:

https://github.com/benmatselby/sublime-phpcs

I'm not an .editorconfig user, but I think PSR-2 covers all the formatting rules.


- Devon


On Apr 24, 2013, at 9:27 AM, Stefano F. Rausch <stefano@rausch-e.net> wrote:

> Hi Devon,
> 
> I had a look at your Road Map and have the following suggestions:
> 
> v0.1 – scan project command : I would like to avoid for the user to have
to ( actively ) scan the project files. Even, if an initial ( manual ) 
setup is more time consuming, directories to include / exclude in the 
automatic background scanning service ( make it as simple as possible for 
users to work with the plugin ) should be declared in the user package 
preferences settings – see v0.4. IMHO this point should not be delayed, 
but be first priority.
> 
> Reason being : even if this first version will be a proof of concept 
"only", it should be usable from day 1. The earlier the plugin can be used
the higher the chances of adoption and the mor e feedback we will receive 
to be able to improve the code base on a frequent basis. Release often 
should be obligatory.
> 
> v0.2 – completion support : should include protected variables to. Think
of inheritance.
> 
> v0.3 – lookups : should be done in Python to minimise the roundtrip time
for the plugin to execute.
> 
> Furthermore, we should agree on using the .editorconfig plugin to 
standardise the formatting rules. In this context : shall we start with 
the Coding Guidelines first and then / in parallel discuss the design ( 
patterns to use )?
> 
> Again, good start!
> 
> Cheers
> 
> --
> 
> Stefano F. Rausch
>