On Monday, 21 November 2022 at 00:29:12 UTC, thebluepandabear
wrote:
.. not to mention, I'd be out of job if I stopped writing
getters/setters ;-)
I value your input in this discussion, you have brought some
good points.
Out of interest, what type of industry-level software are you
creating with D? I don't know much companies using D
commercially.
As someone else mentioned in this thread, there are some
'arbitrary changes' in D, for example, to the traditional concept
of the class type, as being a user-defined type for encapsulating
data and methods that operate on that data.
That is, the module, not the class, is the unit of encapsulation
in D.
In addition, public is the default visibility in a class in D,
which also goes against the traditional concept of using an
encapsulated user-defined data type in conjunction with
'information hiding' (or access controls, depending on what
terminology you want to use).
These decisions no doubt, are design decisions, and not
accidental, I presume.
These decisions have consequences of course.
You should be completely aware of these changes in D, *before*
embarking on using classes in D. Some would say those
consequences are benefical, while others would reject that
proposition, entirely ;-)
As such I leave it to the designer(s) of D to better explain
their reasoning.
These changes by themself rule out the use of D in our
environment.
"..utility functions operating on data structures. Welcome to
1972!"
There are many other reasons also of course, which frankly are
unrelated to (and more important) than the above.
But otherwise, I find D to be an enjoyable hobby language,
particulary for lower-level programming, to both use and explore
its capabilities.
There are of course some companies using it commercially. But not
the company I work for.
