On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky
<[email protected]> wrote:
21-May-2013 17:03, Regan Heath пишет:
[snip]
[snip]
If we make it a part of restructuring std.* that is long overdue then
I'm fine as long as package structure is well thought out as a whole.
Good structure can come about from a complete top down design.. but also
from many small changes towards a better whole. This is perhaps one
such change?
Without direction to follow there could be no end of such changes nor
grief for the user and maintenance burden for maintainers.
Now you're generalising. I am not suggesting we start to rename the
standard library piecemeal. I am suggesting we change one module which is
changing anyway combining the "grief" and lessening it's effect on
everyone.
Changing it now before adopting a package structure risks the 2nd
change and another set of arguments for keeping things as is.
Are we ever going to have a complete restructuring? I doubt it..
Why not - Phobos is going to grow way beyond what it's now. There has
been thread on which structure to adopt but it didn't went far.
And you're surprised by that? I'm not. I'm not trying to be cynical, but
realistic. Realistically re-organising the standard library isn't high on
the priority list, yet. So we can wait, or we can do something specific
now when it'll have less detrimental effects.
Meaning if we can make an incremental change for the better
For better how? The endless churn in my opinion is not worth the
incremental change for better. You also would have to argue for every
single change with folks pushing whichever way they feel like to (not
talking about uni). This is a proverbial "design by committee".
Another generalisation. No-one is suggesting we start renaming modules
just because user X wants to. All I suggested is that if we get a chance
to do so at the same time as another breaking change to the same module,
we should - provided the benefit of the rename is clear.
now when
there is some obviation of the resulting issues then we should, or we
risk more resistance in the future.
Any change will leave a deprecated module that references it's new true
location. Thus the less steps we do the less is damage done in the long
run.
Sure, and that would be "ideal" but the trade off is that every user has
to live with badly named modules we could have changed at no additional
cost to the users. Only library maintainers will see and care about the
existance of the deprecated modules.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
