Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Module vs. Namespace #6

Open
L33T opened this issue Jul 14, 2020 · 0 comments
Open

Module vs. Namespace #6

L33T opened this issue Jul 14, 2020 · 0 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested

Comments

@L33T
Copy link
Collaborator

L33T commented Jul 14, 2020

Currently, the Python project defines modules based on the core sub-projects (arch, common, compiler, symex) which requires specific module imports (or wildcard) to obtain classes. (i.e. from vtil.arch import basic_block)

This does not follow the core project where "imports" are usually inside the main namespace (VTIL). For example, basic_block is accessible from the main namespace (vtil::basic_block) unlike the python project which puts the class inside vtil::arch::basic_block virtually.

This is arguably good for organizing the massive projects into submodules, but can result in a confusing import perspective. Take the following for example:

from vtil.arch import routine, basic_block
from vtil.common import tagged_order

def on_block(bbl: basic_block) -> tagged_order:
  print(bbl)
  return tagged_order.obreak

rtn = routine.load('./hello_world.vtil')
rtn.for_each(on_block)

tagged_order is actually vtil::enumerator::tagged_order which is contained inside the common project and requires to be explicitly imported, instead of being inside the global vtil namespace.

The following is considered:

from vtil import routine, basic_block, tagged_order

def on_block(bbl: basic_block) -> tagged_order:
  print(bbl)
  return tagged_order.obreak

rtn = routine.load('./hello_world.vtil')
rtn.for_each(on_block)

And the submodules would be replaced with explicitly nested namespaces inside the vtil namespace. (i.e. debugger, symbolic)

@L33T L33T added enhancement New feature or request help wanted Extra attention is needed question Further information is requested labels Jul 14, 2020
@L33T L33T self-assigned this Jul 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant