Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
E
ensembl
Manage
Activity
Members
Labels
Plan
Issues
0
Issue boards
Milestones
Iterations
Wiki
Requirements
Jira
Code
Merge requests
1
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Package Registry
Container Registry
Operate
Environments
Terraform modules
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Issue analytics
Insights
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
ensembl-gh-mirror
ensembl
Commits
4cf0697b
Commit
4cf0697b
authored
21 years ago
by
Arne Stabenau
Browse files
Options
Downloads
Patches
Plain Diff
get_tiling_path description added
parent
af8fa0a1
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
docs/ensembl_changes_spec.txt
+19
-9
19 additions, 9 deletions
docs/ensembl_changes_spec.txt
with
19 additions
and
9 deletions
docs/ensembl_changes_spec.txt
+
19
−
9
View file @
4cf0697b
...
...
@@ -223,16 +223,26 @@ Slice
The concept of an 'empty' slice will no longer exist.
Should we remove all of the get_all_FeatureTypeX methods from Slice? These
methods are not strictly needed and they are annoying because they result in
a duplication of coding effort. Everytime a new feature is added, a new
feature adaptor needs to be added AND a new method needs to be added to the
slice. Would it not make everything simpler if features could still be
fetched by slice from adaptors but not from slices as well? This also
results in slices being smaller objects and makes the code more distributed.
*probably can't get away with this change since much code depends on it,
and it is not a huge flaw in the design anyway
The get_tiling_path method will have to be implemented differently for the
new system. It will take a coord_system string as an argument and rather than
returning a list of Tile objects it will return a listref of triplets containing
a start int, and end int, and a 'to' slice object. The following is an example
of how this method would be used ($clone is a reference to a slice object in
the clone coordinate system):
my $clone_path = $slice->get_tiling_path('clone');
foreach my $tile (@$clone_path) {
my ($start, $end, $clone) = @$tile;
print $slice->frag_name, ':', $start, '-', $end , ' -> ',
$clone->frag_name, ':', $clone->start, '-', $clone->end,
$clone->strand, "\n";
}
Tile
----
The tile object will no longer be necessary.
SliceAdaptor
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment