1 |
> Not unless we can come up with some reason why we would need to add the |
2 |
> code complexity to catalyst. Essentially, there would have to be a few |
3 |
> use cases that would absolutely prohibit using absolute paths, |
4 |
> otherwise I don't see a reason for changing it. This has been brought |
5 |
> up before and always shot down simply because nobody could ever give me |
6 |
> a reason why an absolute path wouldn't work for them and only a |
7 |
> relative would. If you can show that what you want to do cannot be |
8 |
> accomplished with the current code and absolute paths, then it would be |
9 |
> accepted. Remember that simply making something easier for you isn't a |
10 |
> valid reason for hacking up catalyst internals that much. |
11 |
|
12 |
i'd ask the other way around: why only allow absolute paths? |
13 |
this limitation strikes me as counter intuitive. |
14 |
|
15 |
when i started using catalyst, i was expecting it to work this way and |
16 |
wondered why it didnt. so far, i find your arguments against it a bit |
17 |
weak.... i would love to have that extra flexibility. |
18 |
(the guy even said he wanted to do the coding!) |
19 |
|
20 |
heck, show the (hackish) patch, and lets examine "the bloat"... |
21 |
perhaps this needs to be part of the 2.1 branch! |
22 |
:) |
23 |
|
24 |
have fun |
25 |
kind regards |
26 |
Thilo |