January 22, 2012
On 1/22/12 5:57 AM, Alvaro wrote:
> El 21/01/2012 3:05, Michel Fortin escribió:
>  >>> I think byKey and byValue are oddly named, property or not.
>  >>
>  >> Give them better names and convince others. Don't choose "keys"
>  >> and "values".
>  >
>  > Well, if the best ones are already taken, I'd say "allKeys" and
>  > "allValues" would be the next best ones. And they are obviously
>  > properties.
>  >
>
> Agree with "allKeys" and "allValues" as the next best.

byXyz is in TDPL.

> IMO, the name of a property should be a a *noun phrase* (a noun possibly
> with modifiers, complements, adjectives...) because it represents a
> thing. And if the property represens a collection of things (an array, a
> list, a range,...) that noun should be *plural* (giving the idea that it
> can be enumerable). "allKeys" follows this guideline (plural noun with a
> complement).

torhu convinced me byXyz can't be properties. I'll operate the change soon.

> byKey is what, an adverb phrase, an adjective phrase? It can't name a
> range which is a thing.

It has the implied verb "enumerate", "span". "Span hashtable by key".


Andrei
January 24, 2012
On Sun, 22 Jan 2012 10:27:42 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> byKey is what, an adverb phrase, an adjective phrase? It can't name a
>> range which is a thing.
>
> It has the implied verb "enumerate", "span". "Span hashtable by key".

Actually, it's for each (x) in (y) by key:

foreach(i; aa.byKey);

The verb is not implied, nor should it be:

for each (x) in (y) enumerate by key.

This doesn't read well...  But...

for each (x) in (y) enumerated by key.

Hm... still not an action.  It's not a noun, but looks more like an adjective (not an english major).

Even if you don't use it via foreach:

auto x = aa enumerate by key.

The call itself didn't *actually* enumerate the values, it just got you an enumerator.

Still vote property, but I see it's unlikely to change your opinion.  Oh well, back to the winnable battles :)

-Steve
January 24, 2012
On Fri, 20 Jan 2012 20:43:17 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/20/12 7:31 PM, Michel Fortin wrote:
>> I think byKey and byValue are oddly named, property or not.
>
> Give them better names and convince others. Please don't choose "keys" and "values".

On Sun, 22 Jan 2012 10:27:42 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/22/12 5:57 AM, Alvaro wrote:

>> Agree with "allKeys" and "allValues" as the next best.
>
> byXyz is in TDPL.
>

So in other words, please come up with better names, you can't chose "keys" or "values" but you must choose byKeys or byValues, because it's already in TDPL.

Got it!

Looking in TDPL, it seems byKey and byValue are already functions.  Why did we have this discussion again?  Looks like you already chose the answer...

-Steve
January 24, 2012
On 1/24/12 2:53 PM, Steven Schveighoffer wrote:
> On Sun, 22 Jan 2012 10:27:42 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> byKey is what, an adverb phrase, an adjective phrase? It can't name a
>>> range which is a thing.
>>
>> It has the implied verb "enumerate", "span". "Span hashtable by key".
>
> Actually, it's for each (x) in (y) by key:

I'm thinking independently of foreach, e.g.

auto iter = aa.byKey/*()*/;

This should clarify that iter spans aa by key.


Andrei

January 24, 2012
On 1/24/12 2:59 PM, Steven Schveighoffer wrote:
> On Fri, 20 Jan 2012 20:43:17 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 1/20/12 7:31 PM, Michel Fortin wrote:
>>> I think byKey and byValue are oddly named, property or not.
>>
>> Give them better names and convince others. Please don't choose "keys"
>> and "values".
>
> On Sun, 22 Jan 2012 10:27:42 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 1/22/12 5:57 AM, Alvaro wrote:
>
>>> Agree with "allKeys" and "allValues" as the next best.
>>
>> byXyz is in TDPL.
>>
>
> So in other words, please come up with better names, you can't chose
> "keys" or "values" but you must choose byKeys or byValues, because it's
> already in TDPL.
>
> Got it!
>
> Looking in TDPL, it seems byKey and byValue are already functions. Why
> did we have this discussion again? Looks like you already chose the
> answer...
>
> -Steve

Changing parens would be (have been) a smaller change.

Andrei
January 24, 2012
On Tue, 24 Jan 2012 15:02:33 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/24/12 2:53 PM, Steven Schveighoffer wrote:
>> On Sun, 22 Jan 2012 10:27:42 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>>> byKey is what, an adverb phrase, an adjective phrase? It can't name a
>>>> range which is a thing.
>>>
>>> It has the implied verb "enumerate", "span". "Span hashtable by key".
>>
>> Actually, it's for each (x) in (y) by key:
>
> I'm thinking independently of foreach, e.g.
>
> auto iter = aa.byKey/*()*/;
>
> This should clarify that iter spans aa by key.

I wrote about that.

auto iter = aa enumerate (or span) by key.

But it doesn't actually enumerate by calling that function.  The enumeration is done by iter, which is an enumerator/spanner/iterator.

FWIW, I think byKey or byValue is fine for a name.  We're not writing COBOL here, it can be shorthand.  I just think they are properties, and read in English as nouns/adjectives (not actions).

-Steve
February 05, 2012
On Fri, Jan 20, 2012 at 7:47 AM, Johannes Pfau <spam@example.com> wrote:
> Jose Armando Garcia wrote:
>
>> On Thu, Jan 19, 2012 at 9:41 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
>>>>
>>>> On Thu, 19 Jan 2012 14:06:00 -0500, torhu <no@spam.invalid> wrote:
>>>>>
>>>>> If the type of byKeys is Range, I would expect to be able to treat it like one. Not like one, then another, then another, then another... ad infinitum.
>>>>
>>>>
>>>> I don't know what you mean. You can treat it like one.
>>>>
>>>> -Steve
>>>
>>>
>>> It's the rvalue aspect. byKey does not hold a range inside the hashtable (as a member variable would do). Each use of byKey gives you a range that you get to iterate from the beginning.
>>>
>>> Andrie
>>
>> I think MSDN has some decent advice on when to use properties vs
>> methods:
>> http://msdn.microsoft.com/en-
> us/library/bzwdh01d(v=vs.71).aspx#cpconpropertyusageguidelinesanchor1
>
> Hi Jose,
> great that you're still around in the newsgroups. Any news on std.log? Is it
> ready for review?

std.log still works! hehe. std.log is ready for review but unfortunately it depends on some changes I have made to druntime. I have tried to get those changes into druntime but they are just sitting in there as pull requests. I have recently decided to remove all my druntime changes and just put them in std/log.d instead. I'll have a revised std.log soon and maybe we can have a review soon.

Thanks,
-Jose
February 05, 2012
On 2/5/12 11:25 AM, Jose Armando Garcia wrote:
> std.log still works! hehe. std.log is ready for review but
> unfortunately it depends on some changes I have made to druntime. I
> have tried to get those changes into druntime but they are just
> sitting in there as pull requests. I have recently decided to remove
> all my druntime changes and just put them in std/log.d instead. I'll
> have a revised std.log soon and maybe we can have a review soon.

If the changes make more sense to put in druntime let's do so. Please let me know which they are and I'll take a look today.

Andrei

February 05, 2012
On Sun, Feb 5, 2012 at 3:26 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 2/5/12 11:25 AM, Jose Armando Garcia wrote:
>>
>> std.log still works! hehe. std.log is ready for review but unfortunately it depends on some changes I have made to druntime. I have tried to get those changes into druntime but they are just sitting in there as pull requests. I have recently decided to remove all my druntime changes and just put them in std/log.d instead. I'll have a revised std.log soon and maybe we can have a review soon.
>
>
> If the changes make more sense to put in druntime let's do so. Please let me know which they are and I'll take a look today.
>

https://github.com/D-Programming-Language/druntime/pull/141/files

Let me know if there is anything I need to fix and I'll make the changes in a short time. Thanks!

> Andrei
>
February 05, 2012
El 18/01/2012 21:37, Nick Sabalausky escribió:
> "Nick Sabalausky"<a@a.a>  wrote in message
> Plus I've spent time in other langauges where using a function name without
> parens is the way to refer to a function itself, rather than invoke the
> function. That's something I very much like: "foo" refers to the function,
> "foo()" calls the function. Period. End of story. But in D, while "foo()"
> calls a function, refering to a function is a mess: usually it's "&foo", but
> if you're aliasing it or passing it as a template alias parameter than it's
> "foo". But then if you use "foo" in other places, it calls the function
> instead of referring to it! Bleh!!! Messy, messy.

Exactly, to my eyes the () is what says "execute!", what triggers the action, so:

f = func; // even if not in D, looks like getting the function itself (a pointer to it)

x = func(); // looks like "execute func" and assign its ret value to x

even with void returning functions:

doThat(); // the () is like "Action!"

In fact, why not get rid of the & to get a reference to a function?

So my vote is: properties: always without (), methods: always ()
4 5 6 7 8 9 10 11 12 13 14
Next ›   Last »