"deadalnix" wrote in message news:jtn1ol$juu$1...@digitalmars.com...
On 12/07/2012 19:31, Iain Buclaw wrote:
On 12 July 2012 17:49, deadalnix<deadal...@gmail.com> wrote:
One thing PHP has been good at is evolving, and introducing change in the
language (some can argument that the language is so fucked up that this
is
unavoidable, so I do it now and we can discuss interesting topic).
I discussed that system with Rasmus Ledorf at afup 2012 and it something
that D should definitively look into.
The const vs OOP discussion have shown once again that D will have to
introduce breaking changes in the language. This isn't easy matter
because
if we break people code, D isn't attractive. But as long as code isn't
broken, D people can't worked on what's next and it slows down D
progress.
The system adopted in PHP works with a 3 number version. The first number
is
used for major languages changes (for instance 4> 5 imply passing object
by
reference when it was by copy before, 5> 6 switched the whole thing to
unicode).
The second number imply language changes, but either non breaking or very
specific, rarely used stuff. For instance 5.2> 5.3 added GC, closures
and
namespace which does not break code.
The last one is reserved for bug fixes. Several version are maintained at
the same time (even if a large amount of code base is common, so bug
fixes
can be used for many version at the time).
We should leverage the benefit of having switched to git to go in that
way.
We can start right now D2.1.xx with the opX dropped from object and see
how
it goes without requiring everybody to switch now.
Such a system would also permit to drop all D1 stuff that are in current
DMD
because D1 vs D2 can be chosen at compile time on the same sources.
git provide all we need to implement such a process, it is easy to do it
soon (after 2.060 for instance) because it doesn't imply drastic changes
for
users.
Might as well just say "Lets start D3 now - Let's drop all features
that have been deprecated since 0.103 - everyone make a hype and
party!"
No, user will need backward compatible support for any real life work.
This is why besides some small D toy projects, I keep using C++(11) for any
native coding at work
when the oportunity surfaces.
While I keep complaining on Go forums that I don't like that the language
lacks enums and
generics, the way Google oposes language featuritis and is keen on Go 1
stability, makes it easier
to sell to management.
--
Paulo
