Embrace the from template?

Jonathan M Davis newsgroup.d at jmdavisprog.com
Sat Aug 25 09:30:27 UTC 2018


On Saturday, August 25, 2018 2:02:51 AM MDT Jonathan Marler via Digitalmars-
d wrote:
> So assuming we're on the same page, you mentioned that the `from`
> template is too verbose. I can see this point.  To measure this I
> consider the least verbose syntax for achieving the semantics of
> the `from` template.  The semantics can be stated as "take symbol
> X from module Y".  The shortest syntax possible would be the
> following:
>
> <module-name><special-from-operator-character><identifier>
>
> If we defined ':' as the special "from operator" then the
> following would be equivalent:
>
> foo.bar:baz
> from!"foo.bar".baz
>
> Of course, reserving a special character for such an operator
> should require that the operation is common enough to warrant the
> reservation of a character.  Less common operators piggy back on
> keywords or combinations of special characters.  For example, you
> could make the syntax a bit more verbose by re-using the import
> keyword, i.e.
>
> import(foo.bar).baz
>
> but this example is only 1 character less than the `from`
> template.  In the end I don't know if these semantics warrant a
> special operator.  Maybe they warrant new syntax, however, the
> solution that requires the least amount of justification is
> adding a template to `object.d`.  The overhead will be virtually
> zero and only requires a few lines of code because it leverages
> existing D semantics.

Honestly, I don't want to be doing _anything_ like from with _any_ syntax.
It's not just a question of from itself being too long. It's the fact that
you're having to use the import path all over the place. I don't want to be
putting anything other than the actual symbol name in the function's
signature. IMHO, the ideal is to be able to just put

import blah;

at the top and then just use whatever was in module blah without having to
repeat it everywhere. On the whole, I find this whole trend of constantly
having to list exactly which symbols you're importing / exactly where a
symbol comes from instead of just being able to just slap an import at the
top and use the symbols te be way, way too verbose and a general maintenance
problem. Yes, it can make it easier to figure out where a symbol came from
when reading the code, and sometimes, it can improve compilation speed, but
it means having to add a ton of extra code in comparison to just importing
the module once, and you have to maintain all of that, constantly tweaking
import statements, because you've changed which symbols you've used. It's
like a cancer except that it comes with just enough benefits that some folks
keep pushing for it.

from is not the entire problem, but IMHO, it's definitely the straw that
breaks the camel's back. It's taking all of this specificity way too far. I
don't want to have to write or read code that's constantly putting import
information everywhere. Sadly, it makes C's #include mess start looking
desirable in comparison.

- Jonathan M Davis





More information about the Digitalmars-d mailing list