Skip to content
This repository was archived by the owner on Jan 29, 2020. It is now read-only.

WIP[3.0] Pull logic out of TraitUsageGenerator and into ImportGenerator #33

Closed
wants to merge 4 commits into from
Closed

WIP[3.0] Pull logic out of TraitUsageGenerator and into ImportGenerator #33

wants to merge 4 commits into from

Conversation

basz
Copy link
Contributor

@basz basz commented Jan 8, 2016

  • not the responsibility of TraitUsageGenerator.
  • Additionally since i want to add has- and remove methods (see completes hasSomething & removeSomething methods on the Classgenerator #26) I think the alias logic has to be rewritten. It is currently stored in an array where the key equals its value. It's sibling method 'getUses' simply returns array_values for that. I don't see any reason for this state keeping.
    What would be a good way to properly store use and aliases such that I can add hasUse($use), hasUseAlias($use, $alias) removeUse($use) and removeUseAlias($use, $alias)?

@basz basz changed the title WIP pull logic out of TraitUsageGenerator and into ClassGenerator pull logic out of TraitUsageGenerator and into ClassGenerator Jan 8, 2016
@basz basz mentioned this pull request Jan 8, 2016
Closed
@basz
Copy link
Contributor Author

basz commented Jan 12, 2016

@Ocramius pointed out to me this can't be merged until 3.0 (BC)

also perhaps the TraitUsageGenerator should be named 'UsageGenerator'. If so this functionality should remain in (the renamed) UsageGenerator class.

for now I will place the (refactored) functionality (with remove/has methods) in TraitUsageGenerator via #26

@basz basz changed the title pull logic out of TraitUsageGenerator and into ClassGenerator WIP[3.0] Pull logic out of TraitUsageGenerator and into ImportGenerator Jan 13, 2016
Ocramius
Ocramius reviewed Jan 25, 2016
View reviewed changes
src/Generator/ClassGenerator.php
@@ -30,6 +30,11 @@ class ClassGenerator extends AbstractGenerator
protected $namespaceName = null;

/**
* @var array Array of string names
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be UseGenerator[], or UseStatement[]. Stringly typed will bite us back here

@Ocramius Ocramius added this to the 3.1.0 milestone Jan 25, 2016
@Ocramius Ocramius self-assigned this Jan 25, 2016
@Ocramius
Copy link
Member

Looking back at this: having a usage generator feels simpler. Can't remember what the backing reasoning for this PR was...

@Ocramius Ocramius removed their assignment Sep 20, 2016
@Ocramius Ocramius removed this from the 3.1.0 milestone Sep 20, 2016
@Ocramius
Copy link
Member

Closing as incomplete: I don't think we should go further with this unless there is a strong use-case for generating a lot of trait imports (and since this is a code generator, we can actually do the compiler-aided includes ourselves, instead of using traits ;-) )

@Ocramius Ocramius closed this Jul 23, 2017
@Ocramius Ocramius self-assigned this Jul 23, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees

@Ocramius Ocramius

Labels
awaiting author updates enhancement wontfix
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@basz @Ocramius