09-Apr-2013 23:39, Rob T пишет:
On Tuesday, 9 April 2013 at 18:38:55 UTC, Dmitry Olshansky wrote:
[...]
All of this should be CUSTOMIZABLE and DECOUPLED! Give people the
frigging control over the OOP breed they want to use.
Providing people a toolkit not a one-button black box (and that button
keeps getting stuck!) would be awesome.
What we have is a traditional monolithic language and compiler which is
rather inflexible and not as useful as it could be if it were instead a
library of components that you can pick and choose from to assemble the
language sub-set and compiler components that you need for a particular
application. If you don't like a component, you should be able to plug a
different one in or write your own.
Love the positive radical nature of your post ;)
But - it can't hot swap components, it would break guarantees: say
library expect Ref-Counted objects and you hot-swapped that for GC ones,
and so and so forth.
The sane way is sub-setting by restrictions - no changes and no extras.
At least you can use the libraries if your set of restictions is
superset of theirs.
Same with the features of the language. I should be able to say "No I
don't want dynamic arrays" in this part of my code and the compiler will
refuse to compile them in.
Fine and nice. See threads about nogc.
Perhaps I should even be able to create my
own language features that natively compile.
Too bad and doesn't scale. Sub-setting works pulling custom built-ins
doesn't. What could work is seeking smaller sets of "meta" or "proto"
features in which we can implement others (in std-lib) at no loss in
expressiveness, performance etc.
I claim that the whole OOP should be the first one to be broken down
into few smallish proto-features. But as a start we'd better fix the AA
in library disaster (by completing the move) though.
--
Dmitry Olshansky
