Hello,
[This is another currently unfixed point of D2 that prevents us implementing
our project the way we wish it.]
AFAIK, using '$' for custom collection types is not yet possible: oDollar is
simply not implemented (correct?). But why do we need it? I do not understand
the logic requiring an opDollar special method to "desugarise" the '$'
operator. For me, '$' simply means length, so I would be fully happy with the
simple rewrite of
coll[$] coll[$-i] coll[i..$]
to
coll[coll.length] coll[coll.length-i] coll[i..coll.length]
et caetera.
I have thought at two objections against this.
First, 'length' is not a language-defined special member. Actually, it is
already one for the 3 kinds of D arrays --if coll is an array, '$' actually
maps to length, I guess. We could extend this principle to programmer-defined
collections: make 'length' a special member, just like opIndex or range
properties; it is just a decision to take.
Precisely, if needed, index could be either a plain data member _or_ a
property, possibly depending on the kind of collection (or rather on whether
the designer wants to maintain length or compute it on demand).
Finally, I consider 'length' as already somewhat special for random-access
ranges: how else determine index validity, or simply the end point?
Second, length (in the sense of size, or count of elements) may not really make
sense for every kind of collections. For instance, there are open, potential,
sequences like the set of all integer cubes. Also, there are collections for
which the notion of element --thus of count-- is ambiguous or unclear (eg
sequences in which elements should be grouped like code unit strings, or trees
for which only some nodes hold actual elements,...).
But precisely, I think such non-trivial kinds of collections which do not
conceptually have (an obvious) length also do not support '$' (in a simple
way). I vaguely have in mind a kind of equivalence class between collections
for which indexing/slicing makes full sense and the notion of random-access
range with its special attribute 'length'. What so you think?
For what it's worth, python's equivalent to [i..$] ([i:]) is AFAIK actually
rewritten to the magic __len__ method for custom types. The equivalent of D's
coll[$-1] (coll[-i]) is rewritten to coll[coll.__len__()-i]. I do not know of
any practicle issue or limitation of this design in Python --a language in
which many features have been fixed or generalised along times.
[OT]
Precisely, has a python-like syntax of negative indices and slice expressions
open on right side been considered for D? Like:
coll[-3] // third element, counting from right side
coll[1..-1] // all but first and last elements
coll[3..] // all but first 3 elements
and maybe (?)
coll[..3] // first 3 elements
I would very much prefere D's explicite notation if ever "$" had any sensible
meaning in context. (I also prefere explicite '0' than an open interval on left
side.) But as "$" makes no sense, and no other ASCII sign can do the job well,
I find python's choice finally better. Also, intervals open on either side
would be consistent with D's current use of [], I guess.
[/OT]
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
