Change namespace to TightenCo and alias to Illuminate namespace #56
Conversation
|
Can we rename TightenCo to Tightenco to be consistent with our other packages? I like this way a lot. Let me give it a day for us to think of other potential problems. |
|
No. |
|
Oh, OK fine. :) |
| if (! class_exists($illuminate) && ! interface_exists($illuminate) && ! trait_exists($illuminate)) { | ||
| class_alias($tighten, $illuminate); | ||
| } | ||
| } |
There was a problem hiding this comment.
I'm wondering if we would be wiser to alias either all classes, or none of them if there's a single conflict. Theoretically, we could end up with a mixture of Laravel and Collect classes.
There was a problem hiding this comment.
I sort of doubt it, but I still like the idea of a single check instead of many.
# Conflicts: # src/Tightenco/Support/Traits/Macroable.php # src/Tightenco/Support/helpers.php
|
Guys, how do you handle the conflicts with Laravel now? |
|
Ok, I'm just seeing that : laravel/framework@5caa88a |
Resolves #54
I agree that moving this to a
TightenConamespace makes sense, and that we need to provide a fallbackIlluminatenamespace for existing users. @adamwathan's PR (#55) does this by duplicating all the classes, but I think @RemiCollin's solution (#54 (comment)) to alias the classes would be easier to maintain.I believe this PR accomplishes that—it loads an
alias.phpfile via composer, which takes care of it all. This works in my testing...but a second (or third or fourth) set of eyes on this would be appreciated, preferably by someone with more composer chops than I have 😆