January 17, 2012
Alvaro:

> So, not bad. In those [infrequent, I'd say] cases needing an array one would do:
> 
>   auto keys = array(aa.keys);

Unfortunately in D you often need arrays, so those cases are frequent.


> even: (unsure if this would work, but somethig similar maybe)
> 
>   foreach(k; array(aa.keys).sort)
>   {
>      ... use the ordered keys
>   }

sort property is deprecated (or going to be).

Bye,
bearophile
January 17, 2012
On 17/01/12 10:11 PM, Jonathan M Davis wrote:
> You would need to come up with some really solid arguments why it should be
> thrown out (and what we should do instead) and get both Walter and Andrei (if
> not the community at large) to agree that they not only prefer your proposal
> but that it's worth the issues that the changes are going to cause at this
> stage.

There's a few good reasons to throw it out:

1. Avoids pointless discussions like this one. These discussions add nothing, it's just mindless bike shedding.

2. The -property flag *creates* a new kind of error, but doesn't actually help find real problems with your code. Without properties, member function access would always be a.b(), and this artificial error could be avoided.

3. Properties introduce another thing to remember, with no value ("was it byKeys, or byKeys()?"). Without properties, it would be byKeys(). No need to remember.

4. Properties obfuscate code. Is (a.b = c) a variable assignment or arbitrary function call? Who knows! Is a.b an actual variable? Can I write &a.b to get its address, or is it a function masquerading as a variable?

5. One less language feature to implement, learn, document, debug, and discuss.

Is it practical or realistic to throw it out at this stage? I don't know. But there are reasons to.
January 17, 2012
On 1/17/12 4:49 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> I hate I must ask this:
>
> I am sorry to see you do something you hate :-(
>
> Regarding your question, I'd like keys/values to require () because they do lot of work to create the dynamic array, while I like byKey/byValue to be properties because (I think) their creation is O(1). But now we can't change keys/values. So I'd like to keep all five of them as properties.
>
> I'd like a byPair property too:
> http://d.puremagic.com/issues/show_bug.cgi?id=5466

byPair is tricky because std.tuple is not visible from object.

Andrei
January 17, 2012
On 1/17/12 5:13 PM, Peter Alexander wrote:
> On 17/01/12 10:11 PM, Jonathan M Davis wrote:
>> You would need to come up with some really solid arguments why it
>> should be
>> thrown out (and what we should do instead) and get both Walter and
>> Andrei (if
>> not the community at large) to agree that they not only prefer your
>> proposal
>> but that it's worth the issues that the changes are going to cause at
>> this
>> stage.
>
> There's a few good reasons to throw it out:
>
> 1. Avoids pointless discussions like this one. These discussions add
> nothing, it's just mindless bike shedding.

Yes.

> 2. The -property flag *creates* a new kind of error, but doesn't
> actually help find real problems with your code. Without properties,
> member function access would always be a.b(), and this artificial error
> could be avoided.

Yes! I can't believe we have a check that has _zero_ contribution to improving code.

> 3. Properties introduce another thing to remember, with no value ("was
> it byKeys, or byKeys()?"). Without properties, it would be byKeys(). No
> need to remember.

YES!!!

> 4. Properties obfuscate code. Is (a.b = c) a variable assignment or
> arbitrary function call? Who knows! Is a.b an actual variable? Can I
> write &a.b to get its address, or is it a function masquerading as a
> variable?

Hm, actually that's not bad.

> 5. One less language feature to implement, learn, document, debug, and
> discuss.

Back to yes.

> Is it practical or realistic to throw it out at this stage? I don't
> know. But there are reasons to.

Me neither. If I had my way I'd carefully redo the feature to only require @property on rare cases that would otherwise be ambiguous, and make parens optional everywhere else.


Andrei
January 18, 2012
Is there even a point to having byKey/byValue?
Once UFCS comes in (and there's already a seemingly working pull request for it), having .keys return a range like byKey/byValue should will be a silent (though more efficient) change for most programs. And in the situations where it's not (namely when you want to store it as an array), just adding a .array at the end would work.

On 17/01/2012 12:48 AM, Andrei Alexandrescu wrote:
> I hate I must ask this:
>
> int[string] aa;
> foreach (k; aa.byKey) { ... }
>
> or
>
> int[string] aa;
> foreach (k; aa.byKey()) { ... }
>
>
>
> Thanks,
>
> Andrei "I told you" Alexandrescu

January 18, 2012
"Alvaro" <alvaroDotSegura@gmail.com> wrote in message news:jf4tr4$lnv$1@digitalmars.com...
> El 17/01/2012 23:32, Timon Gehr escribió:
>> On 01/17/2012 11:19 PM, Alvaro wrote:
>>> El 17/01/2012 18:24, Andrei Alexandrescu escribió:
>>>>> On 2012-01-17 06:48:26 +0000, Andrei Alexandrescu
>>> ...
>>>>
>>>> aa.keys is taken btw.
>>>>
>>>
>>>
>>> OK, I see, .keys and .values currently return dynamic arrays.
>>>
>>> But the most appropriate property name for the above range should indeed be .keys !
>>>
>>> Now, wouldn't it be be better to turn .keys into the proposed range?
>>>
>>> Let's see. What is the use of .keys?
>>>
>>> I searched phobos and found that .keys is mostly used to itarate over the keys in a foreach loop. With the problem that is needs to allocate a dynamic array. If silently changed to the proposed range, the foreach loop would do the same and without an allocation.
>>>
>>> In a few unittests, .keys is followed by .sort, usually to print the keys in order. That would not work... unless the produced range includes a .sort method. Alternatively a .sortedKeys property can be added.
>>>
>>> The other use I see in phobos is just a typeof(a.keys[0]), which could
>>> be replaced by typeof(a.keys.front)
>>>
>>>
>>> What is the benefit of .keys as a range? it does not allocate an array, just gives the keys.
>>>
>>> And if an array is needed, it is easy to turn a range into an array. [Well, I'm missing a more direct way of doing that than using foreach and appending]
>>>
>>
>> See std.array.array.
>
> Oops. Yes, thanks.
>
> So, not bad. In those [infrequent, I'd say] cases needing an array one would do:
>
>  auto keys = array(aa.keys);
>

My thoughts exactly. The current .keys made sense back in the days before ranges, std.algorithm, etc, but not so much anymore. Vote++


January 18, 2012
Andrei Alexandrescu:

> > I'd like a byPair property too: http://d.puremagic.com/issues/show_bug.cgi?id=5466
> 
> byPair is tricky because std.tuple is not visible from object.

I will add this answer to the issue 5466.

But I hope we'll have the unpacking syntax sugar for tuples. I think this too requires object to see tuples. There are functions in std.math that are better to return a tuple. While having complex numbers as built-in in D is not that useful for most people, I believe tuples are a basic language data type, even more than associative arrays :-)

By the way, I have already started using byKey/byValue ranges in my code, and I've already seen a speedup in some programs :-)

Bye,
bearophile
January 18, 2012
"Peter Alexander" <peter.alexander.au@gmail.com> wrote in message news:jf4ull$n6b$1@digitalmars.com...
> On 17/01/12 10:11 PM, Jonathan M Davis wrote:
>> You would need to come up with some really solid arguments why it should
>> be
>> thrown out (and what we should do instead) and get both Walter and Andrei
>> (if
>> not the community at large) to agree that they not only prefer your
>> proposal
>> but that it's worth the issues that the changes are going to cause at
>> this
>> stage.
>
> There's a few good reasons to throw it out:
>
> 1. Avoids pointless discussions like this one. These discussions add nothing, it's just mindless bike shedding.
>

Andrei's the only one that ever starts any of this "Is this a property or func?!?" nonsense, because he's been against the distinction from the start. We finally got him to give in due to the delegate ambiguity, and he's been bitching about it at every opportinity since.

> 2. The -property flag *creates* a new kind of error, but doesn't actually help find real problems with your code. Without properties, member function access would always be a.b(), and this artificial error could be avoided.
>

Bullshit. Without properties, member function access *ANY* many value accesses are "a.b()". Is this member value a plain-old-var or a function? Who knows! It's a leeked out implementation detail, hooray!

> 3. Properties introduce another thing to remember, with no value ("was it byKeys, or byKeys()?"). Without properties, it would be byKeys(). No need to remember.
>

Of *course* there's a need to remember useless shit: There's a need to remember that it's implemented as a function and not just simply as a member variable. In this *particular* case it may be a little easier since we know it returns range, but what about "aa.keys"? What about every other property out there?

> 4. Properties obfuscate code. Is (a.b = c) a variable assignment or arbitrary function call? Who knows! Is a.b an actual variable?

Who the hell cares? The whole damn *point* is that you don't have to give a shit about the member's implementation on *every* fucking member access. If you want transparency, use assembler.

> Can I write &a.b to get its address, or is it a function masquerading as a variable?
>

That's only an issue when you actually want to take the address of something (and there are ways to improve that situation anyway). But forcing every property to be used as if it were a function instead of data access forces the user to figure out how it's implemented *EVERY* time it's accessed.

> 5. One less language feature to implement, learn, document, debug, and discuss.
>

So we're taking the Java/JavaScript/Brainfuck route of "minimal language == good langauge" now?

> Is it practical or realistic to throw it out at this stage?

I wouldn't think so even if I wanted them gone.

> I don't know. But there are reasons to.

No there aren't. The only reason to throw it out is that Andrei keeps whining and moaning about it just because it's something he can't/won't grok. But being that he's Andrei, that just might end up being enough of a reason, which is why I'm so insistent about the matter.


January 18, 2012
"Nick Sabalausky" <a@a.a> wrote in message news:jf53c2$u86$1@digitalmars.com...
> "Peter Alexander" <peter.alexander.au@gmail.com> wrote in message news:jf4ull$n6b$1@digitalmars.com...
>> 2. The -property flag *creates* a new kind of error, but doesn't actually help find real problems with your code. Without properties, member function access would always be a.b(), and this artificial error could be avoided.
>>
>
> Bullshit. Without properties, member function access *ANY* many value accesses are "a.b()". Is this member value a plain-old-var or a function? Who knows! It's a leeked out implementation detail, hooray!
>

Obviously, I need to re-proofread *after* I edit... ;)

The:

"...member function access *ANY* many..."

Should be:

"...member function accesses *AND* many..."

(Little less grammatically non-sensical that way ;) )


January 18, 2012
Nick Sabalausky:

> Without properties, member function access *ANY* many value accesses are "a.b()". Is this member value a plain-old-var or a function? Who knows! It's a leeked out implementation detail, hooray!

I have a partially related question.

Currently this code compiles even with -property:

void main() {
    int[int] aa = [1:2];
    auto byval = aa.byValue();
}

But I think byValue is a property, so isn't it right to give a compilation error if you add () after the name of a property?

-----------------

By the way, I have just seen this code gives a Access Violation, I think it's a bug for Bugzilla:

void main() {
    int[int] aa;
    auto byval = aa.byValue();
}

Bye,
bearophile