# An Analysis of Dart Language Design Choices and Developer Intent

DevFeed: [An Analysis of Dart Language Design Choices and Developer Intent](<https://devfeed.tech/articles/dart-language-bad-design-choices-38610.md>)

Original publisher: [Read original article](<https://krossovochkin.com/posts/2019_04_08_dart_language_bad_design_choices/>)

Published: 2019-04-08T00:00:00Z

Content type: opinion

Language: en

Sources: [Vasya Drobushkov](<https://devfeed.tech/sources/vasya-drobushkov.md>)

Topics: [Dart](<https://devfeed.tech/topics/dart.md>), [Code](<https://devfeed.tech/topics/code.md>), [implementation](<https://devfeed.tech/topics/implementation.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [dart](<https://devfeed.tech/tags/dart.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [visibility](<https://devfeed.tech/tags/visibility.md>)

## AI overview

This opinion article evaluates design choices in the Dart language using criteria centered on expressing developer intent, avoiding implicit behavior, and separating different concerns. It focuses on visibility modifiers, library-based privacy, and the absence of class-level private and protected modifiers.

## Source excerpt

Introduction Before raising a point about some design choices we need to define some criteria. Intent/Declaration > Usage/Implementation Code one write should clearly state the intent. Implementation is not that important than an intent. Implicit is bad Implicit things do not share the intention, therefore from the first point it means that any implicit thing hides true intent. If anything hides intention -- it can be considered bad. Mixing different things together is bad. Partially it relates to the first point about intention. If you do the change and it is not clear whether it is because of one thing or another (which are mixed into one) -- then intention is hidden and it is bad.