On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:
Right, ideally a @proptery function can perfectly replace a
variable, but practically calling the return value seems far
fetched.
What would you use that for, a handwritten interface struct
with function pointers made read-only using @property?
It doesn't matter. If you want an explosion of special cases,
there is already a language for that, it is called C++.
Every time an exception is introduced, the "burden of proof" is
to prove this exception actually bring sufficient value to pay
for itself, not the other way around.
To me the whole property discussion looks like one of those
endless debates about an insignificant detail.
Scala and Ruby seem to do well with sloppy parens.
For what I've touched of ruby, the language is very permissive
and nice. This is good when you do your first prototype, but this
is also what causes it to be intractable at scale (and also
impossible to optimize, but that is beside the point here).
Is the parentheses thing a problem ? Not really on its own, but
it compound.
The parentheses thing and with it the special _ syntax to NOT
call a function is not considered as a good thing by most scala
people I've talked to.
With the introduction of UFCS it became clear that nobody likes
byLine().array().sort().release(), and even less
rng.release.sort().array().front.
For some functions it's really hard to decide whether or not
something is a property, e.g. for me Range.save is an
action/function not a property. So for me using @property
appears to waste time making pointless decisions.
One can reach the desired effect by having a consistent set of
rules and define the calling as a fallback rewrite when there is
an error. Namely, add a rule that says : if this is an error, add
() and retry. Here you go, problem solved, you can use
parentheses function call in every places it is not ambiguous
without introducing Byzantines set of rules into the language.
