El 18/01/2012 21:37, Nick Sabalausky escribió:
"Nick Sabalausky" 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 f
On Sun, Feb 5, 2012 at 3:26 PM, Andrei Alexandrescu
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 t
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
On Fri, Jan 20, 2012 at 7:47 AM, Johannes Pfau wrote:
> Jose Armando Garcia wrote:
>
>> On Thu, Jan 19, 2012 at 9:41 PM, Andrei Alexandrescu
>> wrote:
>>> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
On Thu, 19 Jan 2012 14:06:00 -0500, torhu wrote:
>
> If the type of byKeys
> The builtin associative arrays of D. i.e.:
>
> int[string] aa;
I could tell it was a container. Guess this shows how far I'm not looking (or
behind) with the details of implementation.
> If key, it must be read only, since keys must be immutable.
>
> If value, it could potentially be read/
On Tue, 24 Jan 2012 16:43:33 -0500, Era Scarecrow
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.byK
On Tue, 24 Jan 2012 15:02:33 -0500, Andrei Alexandrescu
wrote:
On 1/24/12 2:53 PM, Steven Schveighoffer wrote:
On Sun, 22 Jan 2012 10:27:42 -0500, Andrei Alexandrescu
wrote:
byKey is what, an adverb phrase, an adjective phrase? It can't name a
range which is a thing.
It has the implied
> >> 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 shou
On 1/24/12 2:59 PM, Steven Schveighoffer wrote:
On Fri, 20 Jan 2012 20:43:17 -0500, Andrei Alexandrescu
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 "
On 1/24/12 2:53 PM, Steven Schveighoffer wrote:
On Sun, 22 Jan 2012 10:27:42 -0500, Andrei Alexandrescu
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
On Fri, 20 Jan 2012 20:43:17 -0500, Andrei Alexandrescu
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, 2
On Sun, 22 Jan 2012 10:27:42 -0500, Andrei Alexandrescu
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.byKe
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".
&g
On Sunday, January 22, 2012 12:57:14 Alvaro wrote:
> byKey is what, an adverb phrase, an adjective phrase?
Prepositional phrase actually.
- Jonathan M Davis
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 ta
El 20/01/2012 18:58, Andrei Alexandrescu escribió:
On 1/17/12 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()) { ... }
I vote properties.
The general rule to me the is a function represent
On 21.01.2012 02:43, Andrei Alexandrescu wrote:
A good outcome of this vote might have been the distillation of some
simple guidelines, as opposed to enforcing some arbitrary consistency.
Apparently the participants in this thread are divided regarding general
rules as well as their applicabilit
On 21/01/12 1:43 AM, Andrei Alexandrescu wrote:
Apparently the participants in this thread are divided regarding general
rules as well as their applicability to this particular case.
And this is exactly the problem. There are no general rules because
everyone disagrees with what exactly a prop
gt;> Manzana, torhu.
>>>
>>> Property: Nick Sabalausky, Simen Kjaeraas.
>>>
>>> I wasn't able to discern a clear vote from the others. Please correct
>>> the list.
>>
>> Votes ?!?
>>
>> I think byKey and byValue are oddl
On 20/01/2012 17:58, Andrei Alexandrescu wrote:
On 1/17/12 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
I tallied the votes.
Functio
, Simen Kjaeraas.
I wasn't able to discern a clear vote from the others. Please correct
the list.
Votes ?!?
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".
Well
from the others. Please correct
the list.
Votes ?!?
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".
Since you
asked, I think they should be properties. But I don'
list.
Votes ?!?
I think byKey and byValue are oddly named, property or not. Since you
asked, I think they should be properties. But I don't care really. What
I care about is consistency.
Voting on a case by case basis is just nonsensical. What's needed are
guidelines and rationales
On 20/01/12 5:58 PM, Andrei Alexandrescu wrote:
I tallied the votes.
Function: Mail Mantis, bearophile, Jacob Carlborg, Olivier Pisano, Ary
Manzana, torhu.
Property: Nick Sabalausky, Simen Kjaeraas.
I wasn't able to discern a clear vote from the others. Please correct
the list.
I vote functi
Andrei Alexandrescu:
> I tallied the votes.
>
> Function: Mail Mantis, bearophile, Jacob Carlborg, Olivier Pisano, Ary
> Manzana, torhu.
>
> Property: Nick Sabalausky, Simen Kjaeraas.
>
> I wasn't able to discern a clear vote from the others. Please correct
>
On 01/20/2012 06:58 PM, Andrei Alexandrescu wrote:
On 1/17/12 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
I tallied the votes.
Func
On 01/20/2012 01:43 PM, Jonathan M Davis wrote:
On Friday, January 20, 2012 11:58:28 Andrei Alexandrescu wrote:
On 1/17/12 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,
On Friday, January 20, 2012 11:58:28 Andrei Alexandrescu wrote:
> On 1/17/12 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
On Fri, 20 Jan 2012 12:58:28 -0500, Andrei Alexandrescu
wrote:
On 1/17/12 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
I tallied
On 1/17/12 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
I tallied the votes.
Function: Mail Mantis, bearophile, Jacob Carlborg, Olivi
On Fri, 20 Jan 2012 04:29:12 -0500, Peter Alexander
wrote:
On 20/01/12 12:57 AM, Steven Schveighoffer wrote:
On Thu, 19 Jan 2012 18:41:44 -0500, Andrei Alexandrescu
wrote:
On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
On Thu, 19 Jan 2012 14:06:00 -0500, torhu wrote:
If the type of by
On Friday, January 20, 2012 15:13:51 Alvaro wrote:
> Well, there is the case of std::map and its [] operator which adds an
> element if it does not exist. Even if in the right hand side:
>
> a = map[x]; // modifies map if x was not found in it
>
> Maybe Marco is talking about something like that.
El 20/01/2012 10:15, Jonathan M Davis escribió:
On Friday, January 20, 2012 09:58:42 Marco Leise wrote:
Ah, I meant to say that getters should not modify their object. When I see
"a = abc.x[i]" I would be a little surprised to find that it changes the
observable state of abc. The same goes for "
Jonathan M Davis wrote:
> On Friday, January 20, 2012 11:01:10 Jens Mueller wrote:
> > Jonathan M Davis wrote:
> > > On Thursday, January 19, 2012 22:30:46 Jose Armando Garcia wrote:
> > > > I think MSDN has some decent advice on when to use properties vs
> > > > methods:
> > > > http://msdn.micros
On Friday, January 20, 2012 11:01:10 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > On Thursday, January 19, 2012 22:30:46 Jose Armando Garcia wrote:
> > > I think MSDN has some decent advice on when to use properties vs
> > > methods:
> > > http://msdn.microsoft.com/en-us/library/bzwdh01d(v=vs.
Jonathan M Davis wrote:
> On Thursday, January 19, 2012 22:30:46 Jose Armando Garcia wrote:
> > 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#cpconpropert
> > yusageguidelinesanchor1
>
> Those do see
Jose Armando Garcia wrote:
> On Thu, Jan 19, 2012 at 9:41 PM, Andrei Alexandrescu
> wrote:
>> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
>>>
>>> On Thu, 19 Jan 2012 14:06:00 -0500, torhu wrote:
If the type of byKeys is Range, I would expect to be able to treat it
like one. No
On Friday, January 20, 2012 09:29:12 Peter Alexander wrote:
> Can you define what "is logically a property means"? (I assume you meant
> "field" there)
>
> That means different things to different people. For example, in my
> mind, something that is logically a field would have an address. From
>
On 20/01/12 12:57 AM, Steven Schveighoffer wrote:
On Thu, 19 Jan 2012 18:41:44 -0500, Andrei Alexandrescu
wrote:
On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
On Thu, 19 Jan 2012 14:06:00 -0500, torhu wrote:
If the type of byKeys is Range, I would expect to be able to treat it
like one. N
On Friday, January 20, 2012 09:58:42 Marco Leise wrote:
> Ah, I meant to say that getters should not modify their object. When I see
> "a = abc.x[i]" I would be a little surprised to find that it changes the
> observable state of abc. The same goes for "a = b.length()". Now it is
> clearer, isn't i
Am 19.01.2012, 21:53 Uhr, schrieb Jonathan M Davis :
On Thursday, January 19, 2012 20:56:39 Marco Leise wrote:
I just came across some C++ code and came to the conclusion, that
properties and indexed access should not modify the structure. In other
words all my @property and opIndex will probab
On Thu, 19 Jan 2012 18:41:44 -0500, Andrei Alexandrescu
wrote:
On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
On Thu, 19 Jan 2012 14:06:00 -0500, torhu 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 ano
On Thursday, January 19, 2012 22:30:46 Jose Armando Garcia wrote:
> 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#cpconpropert
> yusageguidelinesanchor1
Those do seem like pretty good guidelines.
- Jona
On Thu, Jan 19, 2012 at 9:41 PM, Andrei Alexandrescu
wrote:
> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
>>
>> On Thu, 19 Jan 2012 14:06:00 -0500, torhu 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
On Thursday, January 19, 2012 18:07:50 Andrei Alexandrescu wrote:
> Yah, but .length acts to a better extent like an lvalue.
True, but that's because it's both a getter and a setter. What's weirder IMHO
is properties which are just setters, but they do make sense once in a while.
- Jonathan M Da
On 1/19/12 5:57 PM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 17:41:44 Andrei Alexandrescu wrote:
On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
On Thu, 19 Jan 2012 14:06:00 -0500, torhu wrote:
If the type of byKeys is Range, I would expect to be able to treat it
like one. Not li
On Thursday, January 19, 2012 17:41:44 Andrei Alexandrescu wrote:
> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
> > On Thu, 19 Jan 2012 14:06:00 -0500, torhu 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 anothe
On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
On Thu, 19 Jan 2012 14:06:00 -0500, torhu 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
On Thu, 19 Jan 2012 14:06:00 -0500, torhu wrote:
On 19.01.2012 19:17, Steven Schveighoffer wrote:
That's like saying this:
int[] arr;
int l = arr.length;
l++;
should be the same as this:
arr.length++;
because it's a property.
This is an orthogonal problem. byKey doesn't try to affect t
On Thursday, January 19, 2012 20:56:39 Marco Leise wrote:
> I just came across some C++ code and came to the conclusion, that
> properties and indexed access should not modify the structure. In other
> words all my @property and opIndex will probably also by const. An
> exception to that being cach
Am 19.01.2012, 19:19 Uhr, schrieb Jonathan M Davis :
On Thursday, January 19, 2012 11:33:24 Andrei Alexandrescu wrote:
On 1/19/12 11:29 AM, torhu wrote:
> The reason would be that if it looks like field access, it should
behave
> like that.
The difficulty is in knowing where to stop. The on
On 19.01.2012 19:17, Steven Schveighoffer wrote:
That's like saying this:
int[] arr;
int l = arr.length;
l++;
should be the same as this:
arr.length++;
because it's a property.
This is an orthogonal problem. byKey doesn't try to affect the original
AA, so the semantics should be the same
On Thursday, January 19, 2012 11:33:24 Andrei Alexandrescu wrote:
> On 1/19/12 11:29 AM, torhu wrote:
> > The reason would be that if it looks like field access, it should behave
> > like that.
>
> The difficulty is in knowing where to stop. The only things that behaves
> exactly like a field acce
On Thursday, January 19, 2012 18:33:15 Timon Gehr wrote:
> Parens should be removed completely from lazy values. They don't add a
> lot while being inconsistent with how other STCs work.
Ignoring the fact that this will break code, I completely agree. However,
given the fact that it's going to br
On Thu, 19 Jan 2012 12:19:09 -0500, torhu wrote:
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you should be able to simplify this
On 1/19/12 11:29 AM, torhu wrote:
The reason would be that if it looks like field access, it should behave
like that.
The difficulty is in knowing where to stop. The only things that behaves
exactly like a field access is a field access. This is a known issue in
C++, e.g. smart pointers "are
On 01/19/2012 03:47 PM, Peter Alexander wrote:
On 19/01/12 12:51 AM, Timon Gehr wrote:
On 01/19/2012 01:41 AM, Peter Alexander wrote:
On 18/01/12 12:52 AM, Timon Gehr wrote:
On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
Nick Sabalausk
On 19.01.2012 18:21, torhu wrote:
On 19.01.2012 18:19, torhu wrote:
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you s
On 1/19/12 11:19 AM, torhu wrote:
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you should be able to simplify this
example:
---
auto
On 19.01.2012 18:19, torhu wrote:
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you should be able to simplify this
example:
--
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you should be able to simplify this
example:
---
auto k = aa.byKey;
writeln(k.front);
On 1/17/12 8:29 PM, Andrei Alexandrescu wrote:
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 t
On 19/01/12 12:51 AM, Timon Gehr wrote:
On 01/19/2012 01:41 AM, Peter Alexander wrote:
On 18/01/12 12:52 AM, Timon Gehr wrote:
On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
Nick Sabalausky:
Without properties, member function access *
On 2012-01-18 21:26, Nick Sabalausky wrote:
"Jacob Carlborg" wrote in message
news:jf6e7a$1929$1...@digitalmars.com...
method:
no parameters - parentheses are optional
FWIW, I always do a double-take when I see code like:
functionName;
//or
object.functionName;
It sets off all mannar of "n
On Thursday, January 19, 2012 03:18:22 Timon Gehr wrote:
> They are only required if you want to call a lazy delegate/function
> pointer. They are optional in all other cases.
I could have sworn that they were required. If not, then yeah, that seems
pretty bad. It's certainly not the end of the w
On 01/19/2012 01:52 AM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 01:38:23 Alex Rønne Petersen wrote:
But couldn't that be considered leaking an implementation detail of lazy
values? Or is this intentional design?
The language requires that lazy parameters be accessed with (). That
On Thursday, January 19, 2012 01:38:23 Alex Rønne Petersen wrote:
> But couldn't that be considered leaking an implementation detail of lazy
> values? Or is this intentional design?
The language requires that lazy parameters be accessed with (). That leaks the
fact that the variable is lazy into
On 01/19/2012 01:38 AM, Alex Rønne Petersen wrote:
On 19-01-2012 01:41, Peter Alexander wrote:
On 18/01/12 12:52 AM, Timon Gehr wrote:
On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
Nick Sabalausky:
Without properties, member function
On 01/19/2012 01:41 AM, Peter Alexander wrote:
On 18/01/12 12:52 AM, Timon Gehr wrote:
On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
Nick Sabalausky:
Without properties, member function access *ANY* many value
accesses are "a.b()". Is
On 19-01-2012 01:41, Peter Alexander wrote:
On 18/01/12 12:52 AM, Timon Gehr wrote:
On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
Nick Sabalausky:
Without properties, member function access *ANY* many value
accesses are "a.b()". Is thi
On 18/01/12 12:52 AM, Timon Gehr wrote:
On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
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?
Alex Rønne Petersen wrote:
> if the semicolon wasn't there
... it would look like a parameterless command in a shell:
pwd, ls, du, df, date, uptime, ...
-manfred
On 18-01-2012 21:26, Nick Sabalausky wrote:
"Jacob Carlborg" wrote in message
news:jf6e7a$1929$1...@digitalmars.com...
method:
no parameters - parentheses are optional
FWIW, I always do a double-take when I see code like:
functionName;
//or
object.functionName;
It sets off all mannar of "n
"Nick Sabalausky" wrote in message
news:jf79sh$2l7b$1...@digitalmars.com...
> "Jacob Carlborg" wrote in message
> news:jf6e7a$1929$1...@digitalmars.com...
>>
>> method:
>> no parameters - parentheses are optional
>
> FWIW, I always do a double-take when I see code like:
>
> functionName;
> //or
Le 17/01/2012 07:48, Andrei Alexandrescu a écrit :
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
I vote for the methods.
Cheers,
Olivier
"Jacob Carlborg" wrote in message
news:jf6e7a$1929$1...@digitalmars.com...
>
> method:
> no parameters - parentheses are optional
FWIW, I always do a double-take when I see code like:
functionName;
//or
object.functionName;
It sets off all mannar of "no-effect expression!" bells and buzzers in
imple and efficient byKey and byValue
are thanks to migrating hashes into the runtime.
Not to mention *possible* :)
-Steve
mple, look at how simple and efficient byKey and byValue
are thanks to migrating hashes into the runtime.
Andrei
On Wed, 18 Jan 2012 08:59:57 -0500, Andrei Alexandrescu
wrote:
On 1/18/12 7:20 AM, Steven Schveighoffer wrote:
The only array-specific properties of an array that the compiler should
worry about are ptr and length. Everything else should be a library
function.
Even ptr and length should be
Steven Schveighoffer:
> There is one significant problem with changing aa.keys to be a lazy range
> instead of an array. This is valid code (and does exist in the wild):
>
> foreach(k; aa.keys)
> {
> if(shouldRemove(k))
>aa.remove(k);
> }
>
> This would silently start crashing pro
On Wednesday, January 18, 2012 08:13:37 Andrei Alexandrescu wrote:
> On 1/18/12 7:44 AM, Steven Schveighoffer wrote:
> > If you think the names of things aren't
> > important, name them whatever you want, but at least you as the author
> > get to choose instead of the user.
>
> I understand this p
On Wed, 18 Jan 2012 09:40:00 -0500, Andrei Alexandrescu
wrote:
On 1/18/12 8:34 AM, Steven Schveighoffer wrote:
On Wed, 18 Jan 2012 09:13:37 -0500, Andrei Alexandrescu
wrote:
On 1/18/12 7:44 AM, Steven Schveighoffer wrote:
The solution is easy, just don't start the discussion. Make a deci
On 1/18/12 8:34 AM, Steven Schveighoffer wrote:
On Wed, 18 Jan 2012 09:13:37 -0500, Andrei Alexandrescu
wrote:
On 1/18/12 7:44 AM, Steven Schveighoffer wrote:
The solution is easy, just don't start the discussion. Make a decision
(property or no), and that's the end of it. My intuition says t
On Wed, 18 Jan 2012 09:13:37 -0500, Andrei Alexandrescu
wrote:
On 1/18/12 7:44 AM, Steven Schveighoffer wrote:
The solution is easy, just don't start the discussion. Make a decision
(property or no), and that's the end of it. My intuition says that you
will purposely make the *wrong* choice
On 2012-01-18 14:59, Andrei Alexandrescu wrote:
On 1/18/12 7:20 AM, Steven Schveighoffer wrote:
I think the compiler should not be in the business of generating methods
or properties that could be trivially handled by the library.
Yes. I'm fighting Walter tooth and nail over that, with pale su
On 1/18/12 7:44 AM, Steven Schveighoffer wrote:
The solution is easy, just don't start the discussion. Make a decision
(property or no), and that's the end of it. My intuition says that you
will purposely make the *wrong* choice just to try and get others to
complain so you can "be right".
Well
On 2012-01-18 14:47, Steven Schveighoffer wrote:
On Wed, 18 Jan 2012 07:33:45 -0500, Jacob Carlborg wrote:
On 2012-01-18 09:30, sclytrack wrote:
Is it practical or realistic to throw it out at this stage? I don't
know. But there are reasons to.
I hope we are not dropping properties
rega
On 1/18/12 7:20 AM, Steven Schveighoffer wrote:
I think the compiler should not be in the business of generating methods
or properties that could be trivially handled by the library.
Yes. I'm fighting Walter tooth and nail over that, with pale success.
The only array-specific properties of an
On Wed, 18 Jan 2012 07:33:45 -0500, Jacob Carlborg wrote:
On 2012-01-18 09:30, sclytrack wrote:
Is it practical or realistic to throw it out at this stage? I don't
know. But there are reasons to.
I hope we are not dropping properties
regardless of the syntax of how to call them.
Keep @p
On Tue, 17 Jan 2012 18:29:11 -0500, Andrei Alexandrescu
wrote:
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
On Tue, 17 Jan 2012 19:02:03 -0500, Nick Sabalausky wrote:
"Alvaro" wrote in message
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 befo
On Tue, 17 Jan 2012 19:00:38 -0500, Kapps wrote:
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 pr
not making them properties. (I can't say that
same for .dup/.idup... I still don't get why those are properties, at
all.)
Agreed. If it were keys and values, then a property would make sense.
However,
since it's byKey and byValue, I don't think that it makes as much
sense.
On 2012-01-18 09:30, sclytrack wrote:
Is it practical or realistic to throw it out at this stage? I don't
know. But there are reasons to.
I hope we are not dropping properties
regardless of the syntax of how to call them.
Keep @property
Keep methods-as-properties
-
On 18-01-2012 01:02, Nick Sabalausky wrote:
"Alvaro" 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 +, Andrei Alexandrescu
Le 18/01/2012 01:02, Nick Sabalausky a écrit :
"Alvaro" 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 +, Andrei Alexandresc
On Wednesday, January 18, 2012 09:38:41 Martin Nowak wrote:
> But the current compiler behavior is really annoying.
> Either nobody should use enforced properties or it should
> be part of the standard warning level.
Once the implementation of -property has been fully sorted out, I believe that
i
On Tue, 17 Jan 2012 22:13:49 +0100, Peter Alexander
wrote:
On 17/01/12 6: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
byKey(aa)
Rol
Is it practical or realistic to throw it out at this stage? I don't
know. But there are reasons to.
I hope we are not dropping properties
regardless of the syntax of how to call them.
Keep @property
Keep methods-as-properties
-
(a) No ()
obj.pro
Andrei Alexandrescu wrote:
>> 1. Avoids pointless discussions like this one. These discussions
>> add nothing, it's just mindless bike shedding.
> Yes.
But only because it is planned to create a massive difference between
calls with and without parantheses.
The original idea to use mascerading f
1 - 100 of 146 matches
Mail list logo
