Contents of /contributions/modules/versioncontrol/OOP_TODO

on code
-------

- remove fetch*() methods because with objects we can do that on demand whenever the API user needs the information.

"fetch_source_items(), fetch_successor_items(), get_common_directory_path() and get_item_paths() apply to a list of items, we might consider to have a VersionControlItemList instead of a single array, in order to have it perform lazy loading and stuff. The other possibility would be to keep items in memory as a static copy, but that needs further thought."
(review the following, got it grepping items| grep function| grep \&)
  - versioncontrol_table_operation_items_join(&$tables)
  - versioncontrol_fetch_source_items($repository, &$items)
  - versioncontrol_fetch_successor_items($repository, &$items)
  - VersioncontrolOperation::insert(&$operation_items)
  - VersioncontrolItem::fetchCommitOperations($repository, &$items)

"Example: VersionControlItem::fetchCommitOperations() (see above) can be reduced to VersionControlItem::commitOperations(), and the item object keeps track whether the commit operations have already been fetched or not (is_null($this->commitOperations))."

- update documentation
  - versioncontrol_fakevcs module
  - hook_versioncontrol.php
  - 73 chars to line break on comments

- review operation and item classes
  - search non-oop methods and convert them
  - move loaders to EntityCache classes, like repo and account classes(aka cache for getEntity methods)
- group classes in files with some criteria

on design
---------

- "Still not solved: how to represent accounts that do not have an exact uid/repository/username combination."
  - Start working on account stuff(now there are two classes: VersioncontrolVcsAccount and VersioncontrolAccount)
  - defered until all classes stuff is done(suggested by jpetso)

do not forget
------------- 
- we want to let other modules inherit from all of our classes
- camelcase at conceptual boundaries
- __USE__ gets, like php spl
- for now  do not use SplFileInfo as a parent class for VersioncontrolItem, but maybe in near future when it's considered a need(maybe performance)
- api class dropped, its methods would be on the module file (so. we've got backend objects. pretty easy to retrieve via discovery hook and subsequent instantiation, probably.)
- at the beginning we should have attributes as private as possible and in the process open it as it's needed, taking more time for it before a release
  - later discusion last week result in "use protected in all places" (but later I found exceptions like repository cache :p)
- The future of source items in the main API module (we want them as an optional bonus instead of a log-parse-time requirement)
1	on code
2	-------
3
4	- remove fetch*() methods because with objects we can do that on demand whenever the API user needs the information.
5
6	"fetch_source_items(), fetch_successor_items(), get_common_directory_path() and get_item_paths() apply to a list of items, we might consider to have a VersionControlItemList instead of a single array, in order to have it perform lazy loading and stuff. The other possibility would be to keep items in memory as a static copy, but that needs further thought."
7	(review the following, got it grepping items\| grep function\| grep \&)
8	- versioncontrol_table_operation_items_join(&$tables)
9	- versioncontrol_fetch_source_items($repository, &$items)
10	- versioncontrol_fetch_successor_items($repository, &$items)
11	- VersioncontrolOperation::insert(&$operation_items)
12	- VersioncontrolItem::fetchCommitOperations($repository, &$items)
13
14	"Example: VersionControlItem::fetchCommitOperations() (see above) can be reduced to VersionControlItem::commitOperations(), and the item object keeps track whether the commit operations have already been fetched or not (is_null($this->commitOperations))."
15
16	- update documentation
17	- versioncontrol_fakevcs module
18	- hook_versioncontrol.php
19	- 73 chars to line break on comments
20
21	- review operation and item classes
22	- search non-oop methods and convert them
23	- move loaders to EntityCache classes, like repo and account classes(aka cache for getEntity methods)
24	- group classes in files with some criteria
25
26	on design
27	---------
28
29	- "Still not solved: how to represent accounts that do not have an exact uid/repository/username combination."
30	- Start working on account stuff(now there are two classes: VersioncontrolVcsAccount and VersioncontrolAccount)
31	- defered until all classes stuff is done(suggested by jpetso)
32
33	do not forget
34	-------------
35	- we want to let other modules inherit from all of our classes
36	- camelcase at conceptual boundaries
37	- __USE__ gets, like php spl
38	- for now do not use SplFileInfo as a parent class for VersioncontrolItem, but maybe in near future when it's considered a need(maybe performance)
39	- api class dropped, its methods would be on the module file (so. we've got backend objects. pretty easy to retrieve via discovery hook and subsequent instantiation, probably.)
40	- at the beginning we should have attributes as private as possible and in the process open it as it's needed, taking more time for it before a release
41	- later discusion last week result in "use protected in all places" (but later I found exceptions like repository cache :p)
42	- The future of source items in the main API module (we want them as an optional bonus instead of a log-parse-time requirement)