Gonna reduce this to a response without trying to do context:
S-Expressions:
There's two things about S-Expressions:
* Operators require whitespace separation
This is basically that (- foo bar) and (-foo bar) are two different things.
I think that's a fine conversation to have, and I see how enabling
operator chars inside IDs can be a pro.
* Operator-first notation
This one, sorry, is just awkward. No kid learns math this way. 1 + 3 is
elementary school, and I might go into details of how I suffer from
people not getting this right, but seriously, this is something we
should build on, and not break.
Conditionals:
I think there's a valid point whether the ternary is the best way to
express conditionals.
foo ? one : two
vs
if(condition, if_true), if(condition, if_true, else_value)
Semantical structures:
This is one of the basic design principles I had way back when.
There's no semantics to hashes.
Semantics depend on the language and the grammar of that language. They
also to some extent depend on the use case in the app, like, refactoring
strings into app and toolkit.
The basic gist of hashes is that, in a software context, the number of
possibilities is finite, and thus you can always create a hash mapping
to get things right.
There's an explicit denial of semantics in that approach.
eval(), in a sense:
{{ @get('_unit' + $unit) }}
vs
{{ _uniteDeMesure[$unit] }}
From my Math point-of-view, there are two cases:
Linear functions, which are implemented through matrix multiplications
(internal entity with an index), and
non-linear functions, which are macros.
There's a tad of anti-Perl here, in that, if I can rule out an
alternative way of implementing stuff, I'd rule it out.
Note, from a POV of "let's have a string per thing", requesting the same
entity for B, kB, mB etc, is already a premature optimization. But it's
also OK in practice, so I don't think we should spend to much effort to
create a white theory for it.
That's what I remember to put into this so far.
Axel
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
