"Bane" wrote in message
news:hjfvv2$85...@digitalmars.com...
> I naively and firmly believe, from my standpoint as a individual, that
> any large corporation is evil.
If you remove "naively" and change "corporation" to "institution" or even
"organization", I would be inclined to agree with y
"Andrei Alexandrescu" wrote in message
news:hjo75f$2g3...@digitalmars.com...
> Nick Sabalausky wrote:
>> "Justin Johansson" wrote in message
>> news:hjo31b$275...@digitalmars.com...
>>> Ary Borenszweig wrote:
Walter Bright wrote:
> Justin Johansson wrote:
>> (1) For some reason (p
"Walter Bright" wrote in message
news:hjnt03$1od...@digitalmars.com...
> dsimcha wrote:
>> I've never understood the recommendation not to put complex logic in
>> the
>> constructor.
>
> Complex logic is fine, just logic that cannot fail.
>
>> If you need complex logic to establish the class's
"Walter Bright" wrote in message
news:hjnrej$1kp...@digitalmars.com...
> Justin Johansson wrote:
>> (1) For some reason (possibly valid only in an historic context), I
>> have this great aversion to throwing exceptions from inside C++
>> constructors. From memory, I once threw an exception fro
"Walter Bright" wrote in message
news:hjni3o$r2...@digitalmars.com...
> Andrei Alexandrescu wrote:
>> Walter Bright wrote:
>>> bearophile wrote:
In GCC there is also the "warn_unused_result" function attribute
that
raises a compile time warning if you don't use the return value o
Robert Jacques wrote:
On Fri, 29 Jan 2010 15:18:14 -0500, Andrei Alexandrescu
wrote:
Lutger wrote:
On 01/29/2010 06:36 PM, Andrei Alexandrescu wrote:
...
One problem I foresee is the growth of std.algorithm. It already has
many things in it, and I fear that some user who just wants to trim
On Fri, 29 Jan 2010 15:18:14 -0500, Andrei Alexandrescu
wrote:
Lutger wrote:
On 01/29/2010 06:36 PM, Andrei Alexandrescu wrote:
...
One problem I foresee is the growth of std.algorithm. It already has
many things in it, and I fear that some user who just wants to trim a
string may find it i
dsimcha wrote:
> == Quote from Jacob Carlborg (d...@me.com)'s article
>> Perhaps it's time to start adding more packages than just the std. Make
>> std.algorithm a package and try to split it into several modules.
>
> Please, no. I **HATE** fine-grained imports like Tango has. I don't want
> to
Andrei Alexandrescu wrote:
Justin Johansson wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
versa for that matter?
Note that properties can be
Michiel Helvensteijn wrote:
> Ah, my bad. I was guessing. Still, returning a handle from a property that
> can change the state of the originating object is.. iffy.
I disagree.
For example, I recently had to deal with tables. Each table has rows
and columns. Removing a row removes a cell from e
Andrei Alexandrescu wrote:
> Nick Sabalausky wrote:
>> auto car = new Car();
>> auto wheel = car.getWheel_ThisIsAFunctionNotAProperty();
>> wheel.paintTheCar();
>
> Because a function doesn't attempt to emulate a field.
Not really relevant, since the same applies to fields.
auto car = new Car();
Ali Çehreli wrote:
D is great that it supports three separate Unicode encodings in the
language, but encodings are at a lower level of abstraction than
"letters". I am not sure what data is used for toUniUpper and toUniLower
in std.uni, but they can't work correctly without alphabet information
On 2010-01-29 17:22:11 -0500, Gerrit Wichert said:
[skipping a long part]
But I don't want to advertise any Perl, just hoping the idees behind
Moose can be helpful. So back to D.
Objective-C properties look like that too. You declare a property with
a name, a type and some flags (like readon
Jacob Carlborg wrote:
> On 1/29/10 22:18, Ali Çehreli wrote:
>> Jacob Carlborg wrote:
>>
>> > I would keep std.string for string specific functions and perhaps
>> > publicly import std.algorithm. For exmaple functions like: tolower,
>> icmp
>> > and toStringz.
>>
>> I've been thinking about cha
On 1/29/10 22:18, Ali Çehreli wrote:
Jacob Carlborg wrote:
> I would keep std.string for string specific functions and perhaps
> publicly import std.algorithm. For exmaple functions like: tolower, icmp
> and toStringz.
I've been thinking about characters lately and have realized that
tolower
Hello,
I think the biggest part of our problem with @property is, that we are
using the wrong words. I'm no native english speaker so it may be that
i'm totaly wrong with this, but that's my impression. When i hear the
word property i'm thinking: "ok, this is a well defined part of the
internal
Andrei Alexandrescu:
> // in client code
> // get everything tagged with "string"
> import std.algorithm : @tag(string);
A next step is to allow to import all names with a specified tag, even if such
names are inside more than one text file (the compiler can create a json txt
file to speed up t
== Quote from Jacob Carlborg (d...@me.com)'s article
> Perhaps it's time to start adding more packages than just the std. Make
> std.algorithm a package and try to split it into several modules.
Please, no. I **HATE** fine-grained imports like Tango has. I don't want to
write tons of boilerplate
Ali Çehreli wrote:
Jacob Carlborg wrote:
> I would keep std.string for string specific functions and perhaps
> publicly import std.algorithm. For exmaple functions like: tolower, icmp
> and toStringz.
I've been thinking about characters lately and have realized that
tolower, toupper, icmp,
Lutger wrote:
On 01/29/2010 09:43 PM, bearophile wrote:
Andrei Alexandrescu:
I think the idea of tags is awesome, particularly because it doesn't
require one to divide items in disjoint sets. I'll think some more of
it.
A hierarchical D/Python-like module system isn't the only way to
organi
Jacob Carlborg wrote:
> I would keep std.string for string specific functions and perhaps
> publicly import std.algorithm. For exmaple functions like: tolower, icmp
> and toStringz.
I've been thinking about characters lately and have realized that
tolower, toupper, icmp, and friends should not
Hello bearophile,
BCS:
Because you complained I added the other two, but because I think
they are silly I make it so you can switch them on and off (they are
placed under a "version(FullSI)").
What's the definition of "silly SI units"?
Base SI units that are or can be defined in terms of
Hello bearophile,
BCS:
Things I'd use in place of that:
/
char[] str, int at = 0;
...
switch(str[at]) { ... }
...
at++;
or
/
char[] str;
...
switch(str[0]) { ... }
...
str = str[1..$];
When in not-debug mode that struct of mine is just 1 word long, so it
hopefully gets optimized wel
On 01/29/2010 09:43 PM, bearophile wrote:
Andrei Alexandrescu:
I think the idea of tags is awesome, particularly because it doesn't
require one to divide items in disjoint sets. I'll think some more of it.
A hierarchical D/Python-like module system isn't the only way to organize
blocks of cod
"Michel Fortin" wrote in message
news:hjtpb4$1t1...@digitalmars.com...
>
> Andrei, you keep complaining it's a convention. It *is* a convention,
> because only a convention can differentiate actions from accessors.
> Ideally, we wouldn't need a special syntax: English words would be enough.
>
Andrei Alexandrescu:
> I think the idea of tags is awesome, particularly because it doesn't
> require one to divide items in disjoint sets. I'll think some more of it.
A hierarchical D/Python-like module system isn't the only way to organize
blocks of code. Both future Windows file system and Go
On 01/29/2010 09:18 PM, Andrei Alexandrescu wrote:
Lutger wrote:
On 01/29/2010 06:36 PM, Andrei Alexandrescu wrote:
...
One problem I foresee is the growth of std.algorithm. It already has
many things in it, and I fear that some user who just wants to trim a
string may find it intimidating to b
"Pelle Månsson" wrote in message
news:hjv9sf$1n5...@digitalmars.com...
> On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
>> Note in the anecdote above, both users would have
>> been satisfied if you could *only* call empty without parentheses.
>>
>
> That's a good point. The writeln = 3; is a
On 2010-01-29 15:02:13 -0500, Andrei Alexandrescu
said:
Ok how about this: if just calling the thing changes the parent, it
can't be a property. Guess I could live with that.
Hopefully that rule will only apply to the getter. :-)
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com
Lutger wrote:
On 01/29/2010 06:36 PM, Andrei Alexandrescu wrote:
...
One problem I foresee is the growth of std.algorithm. It already has
many things in it, and I fear that some user who just wants to trim a
string may find it intimidating to browse through all that
documentation. I wonder how w
On 01/29/2010 09:13 PM, Lutger wrote:
http://www.naturaldocs.org/documenting/reference.html#Example_Class
sorry, wrong anchor:
http://www.naturaldocs.org/documenting/reference.html#Summaries
On 01/29/2010 06:36 PM, Andrei Alexandrescu wrote:
...
One problem I foresee is the growth of std.algorithm. It already has
many things in it, and I fear that some user who just wants to trim a
string may find it intimidating to browse through all that
documentation. I wonder how we could break s
Bill Baxter wrote:
One more example to consider: RNG.randomInt() or RNG.randomInt
I think Steven is right that you can always find corner cases, but
that the existence of corner cases is pretty irrelevant.
I agree. It's not the existence of corner cases I'm worried about, it's
the frequency
On Fri, Jan 29, 2010 at 12:02 PM, Andrei Alexandrescu
wrote:
> Steven Schveighoffer wrote:
>>
>> On Fri, 29 Jan 2010 13:43:50 -0500, Pelle Månsson
>> wrote:
>>
>>> On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
Note in the anecdote above, both users would have
been satisfied i
On Fri, Jan 29, 2010 at 10:41 AM, Michel Fortin
wrote:
> On 2010-01-29 12:56:43 -0500, Andrei Alexandrescu
> said:
>
>> Steven Schveighoffer wrote:
>>>
>>> On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu
>>> wrote:
Consider:
struct Stack(T) {
T pop();
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 13:43:50 -0500, Pelle Månsson
wrote:
On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
Note in the anecdote above, both users would have
been satisfied if you could *only* call empty without parentheses.
That's a good point. The writeln =
Continuing from another very deep thread...
On Fri, 29 Jan 2010 14:43:12 -0500, Lutger
wrote:
On 01/29/2010 07:01 PM, Andrei Alexandrescu wrote:
...
How about @property? When you add a @property to a function it can be
called as an assignment. @property does not touch the calling of
no-ar
On 1/29/10 18:36, Andrei Alexandrescu wrote:
I plan a few improvements to Phobos that will improve string handling.
Currently arrays of characters count as random-access ranges, which is
not true for arrays of char and wchar. I plan to make std.range aware of
that and only characterize char[] an
On 2010-01-29 13:52:25 -0500, Andrei Alexandrescu
said:
Ok this makes sense. So something is a property if fetching it doesn't
mess up the parent object. (Maybe properties should be pure even.)
Logical-pure, to be precise. ;-)
The lingering question is whether you can later use the fetched
On Fri, 29 Jan 2010 14:23:55 -0500, Pelle Månsson
wrote:
On 01/29/2010 08:07 PM, Steven Schveighoffer wrote:
f.next();
Looks like it advances f, even though next isn't a verb. Without the
parentheses, it looks like a noop access of a property.
I disagree, it doesn't look like it advances
On 01/29/2010 07:01 PM, Andrei Alexandrescu wrote:
...
How about @property? When you add a @property to a function it can be
called as an assignment. @property does not touch the calling of
no-argument functions.
Are there any problems with that?
Such a "@property is just for the writing" desi
On Fri, 29 Jan 2010 13:52:25 -0500, Andrei Alexandrescu
wrote:
Michel Fortin wrote:
My definition is that a property gives access to an aspect of an
object and doesn't modify it (the getter is essentially logical-const).
Ok this makes sense. So something is a property if fetching it does
On 2010-01-29 13:57:06 -0500, "Steven Schveighoffer"
said:
You win because Steven's definition is not good enough. I said before
that we should have a authoritative definition. If we really can't
define how a property should be defined after some reflection, then you
really win.
Be care
On 01/29/2010 08:07 PM, Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 13:43:50 -0500, Pelle Månsson
wrote:
On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
Note in the anecdote above, both users would have
been satisfied if you could *only* call empty without parentheses.
That's a goo
On Fri, 29 Jan 2010 13:43:50 -0500, Pelle Månsson
wrote:
On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
Note in the anecdote above, both users would have
been satisfied if you could *only* call empty without parentheses.
That's a good point. The writeln = 3; is also a good point. :)
On Fri, 29 Jan 2010 13:41:43 -0500, Michel Fortin
wrote:
On 2010-01-29 12:56:43 -0500, Andrei Alexandrescu
said:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu
wrote:
Consider:
struct Stack(T) {
T pop();
...
}
By your definition, pop()
Michel Fortin wrote:
On 2010-01-29 12:56:43 -0500, Andrei Alexandrescu
said:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu
wrote:
Consider:
struct Stack(T) {
T pop();
...
}
By your definition, pop() should be a property. It doesn't quite
s
Michel Fortin wrote:
On 2010-01-29 12:53:27 -0500, Andrei Alexandrescu
said:
An algorithm can fail in many silent ways if it misuses the range
interface. None of std.algorithm algorithms uses front naively.
Easy to say. How did you verify that?
It's simply a mistake I make very seldom if
On 2010-01-29 12:53:27 -0500, Andrei Alexandrescu
said:
An algorithm can fail in many silent ways if it misuses the range
interface. None of std.algorithm algorithms uses front naively.
Easy to say. How did you verify that?
The problem is very subtle: if you call front after popFront on
so
On 2010-01-29 12:56:43 -0500, Andrei Alexandrescu
said:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu
wrote:
Consider:
struct Stack(T) {
T pop();
...
}
By your definition, pop() should be a property. It doesn't quite strike
me as an intuiti
On 01/29/2010 07:23 PM, Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or
vice versa f
On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
Note in the anecdote above, both users would have
been satisfied if you could *only* call empty without parentheses.
That's a good point. The writeln = 3; is also a good point. :)
What I'm trying to defend is the ability to call non-property
On Fri, 29 Jan 2010 12:56:43 -0500, Andrei Alexandrescu
wrote:
So now we're down to proportions, nuance, and where "main" goes. You
made my point. I win.
You just don't get it. declaring property or not is part of naming the
function. Any naming convention either can have strict rules
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
versa for that matter?
Note that properties can be n
On Fri, 29 Jan 2010 12:42:57 -0500, Pelle Månsson
wrote:
On 01/29/2010 02:01 PM, Steven Schveighoffer wrote:
That's a deficiency in the design of byLine. It's a range that "primes"
itself with a line of text. The fact that you can enter the line above
and just throw away the data seems error
Pelle Månsson wrote:
On 01/29/2010 06:19 PM, Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
versa for
bearophile wrote:
Andrei Alexandrescu:
Currently arrays of characters count as random-access ranges, which is
not true for arrays of char and wchar. I plan to make std.range aware of
that and only characterize char[] and wchar[] (and their qualified
versions) as bidirectional ranges.
32 bits
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:29:22 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.by
On 01/29/2010 06:19 PM, Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
versa for that matter?
Note t
Andrei Alexandrescu:
> Currently arrays of characters count as random-access ranges, which is
> not true for arrays of char and wchar. I plan to make std.range aware of
> that and only characterize char[] and wchar[] (and their qualified
> versions) as bidirectional ranges.
32 bits are not enou
Michel Fortin wrote:
On 2010-01-29 12:21:18 -0500, Andrei Alexandrescu
said:
Michel Fortin wrote:
Yeah, it's less likely to be a problem. But "less likely to be a
problem" does still does not make things reliable. Something reliable
works all the time, or it just doesn't work and tells you.
On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:29:22 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambi
On 2010-01-29 12:21:18 -0500, Andrei Alexandrescu
said:
Michel Fortin wrote:
Yeah, it's less likely to be a problem. But "less likely to be a
problem" does still does not make things reliable. Something reliable
works all the time, or it just doesn't work and tells you.
stream.front after
On 01/29/2010 02:01 PM, Steven Schveighoffer wrote:
That's a deficiency in the design of byLine. It's a range that "primes"
itself with a line of text. The fact that you can enter the line above
and just throw away the data seems error prone to me. When would you
ever use that "feature"? In pract
I plan a few improvements to Phobos that will improve string handling.
Currently arrays of characters count as random-access ranges, which is
not true for arrays of char and wchar. I plan to make std.range aware of
that and only characterize char[] and wchar[] (and their qualified
versions) as
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:29:22 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
versa for that matter?
Note that pro
Michel Fortin wrote:
Yeah, it's less likely to be a problem. But "less likely to be a
problem" does still does not make things reliable. Something reliable
works all the time, or it just doesn't work and tells you.
stream.front after stream.popFront works all the time and fetches a new
line o
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
versa for that matter?
Note that properties can be named things other than byLin
On 2010-01-29 11:54:41 -0500, "Steven Schveighoffer"
said:
On Fri, 29 Jan 2010 11:33:17 -0500, Michel Fortin
wrote:
On 2010-01-29 11:18:46 -0500, Andrei Alexandrescu
said:
It should work for stream ranges if front() checks the "filled" flag
and eats the next line if false, and popFr
Justin Johansson wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
versa for that matter?
Note that properties can be named things other than byLi
Michel Fortin wrote:
On 2010-01-29 11:18:46 -0500, Andrei Alexandrescu
said:
It should work for stream ranges if front() checks the "filled" flag
and eats the next line if false, and popFront clears the "filled" flag.
So now you want the front to fetch from stdin on the first call? It's
th
On Fri, 29 Jan 2010 11:33:17 -0500, Michel Fortin
wrote:
On 2010-01-29 11:18:46 -0500, Andrei Alexandrescu
said:
It should work for stream ranges if front() checks the "filled" flag
and eats the next line if false, and popFront clears the "filled" flag.
So now you want the front to fe
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
versa for that matter?
Note that properties can be named things other than byLine.
-Steve
What I mean
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
versa for that matter?
Note that properties can be named things other than byLine.
-Steve
What I mean
Michel Fortin wrote:
On 2010-01-29 10:40:23 -0500, Andrei Alexandrescu
said:
I'll tell you what I'd have liked: a landslide of responses to my
question revealing my mistaken ways and clarifying without a shade of
a doubt that byLine should be a @property. Or not. (I don't even care
which.)
Michel Fortin wrote:
On 2010-01-29 11:47:17 -0500, Justin Johansson said:
Closer to the mark would be ...
digitalmars.d1.dont_ask
digitalmars.d2.should_this_be_a_class_or_struct
digitalmars.d2.should_this_symbol_be_capitalized
digitalmars.d2.should_this_use_a_function_pointer_or_delegate
digi
On Fri, 29 Jan 2010 11:29:22 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
versa for that matter?
Note that properties can be named thing
On 2010-01-29 11:18:46 -0500, Andrei Alexandrescu
said:
It should work for stream ranges if front() checks the "filled" flag
and eats the next line if false, and popFront clears the "filled" flag.
So now you want the front to fetch from stdin on the first call? It's
the same problem as 'byL
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
versa for that matter?
Note that properties can be named things other than byLine.
-Steve
What I meant to say is that in the @pro
On 2010-01-29 11:19:32 -0500, Andrei Alexandrescu
said:
That's an implementation problem of byLine, not a issue with the byLine name.
Ok, so if you agree that 'byLine' eating a line on creation is a bug,
that means you don't expect 'byLine' to eat a line. That makes 'byLine'
a property sin
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:18:46 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin
wrote:
On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer"
said:
ugh... much simpler with a true stream-like range
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
wrote:
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
versa for that matter?
Note that properties can be named things other than byLine.
-Steve
On Fri, 29 Jan 2010 11:18:46 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin
wrote:
On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer"
said:
ugh... much simpler with a true stream-like range that supports what
is n
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:17:04 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 10:40:23 -0500, Andrei Alexandrescu
wrote:
Michel Fortin wrote:
On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer"
said:
Hey, it's that dead h
On 2010-01-29 11:47:17 -0500, Justin Johansson said:
Closer to the mark would be ...
digitalmars.d1.dont_ask
digitalmars.d2.should_this_be_a_class_or_struct
digitalmars.d2.should_this_symbol_be_capitalized
digitalmars.d2.should_this_use_a_function_pointer_or_delegate
digitalmars.d2.should_this
Michel Fortin wrote:
On 2010-01-29 10:40:23 -0500, Andrei Alexandrescu
said:
I'll tell you what I'd have liked: a landslide of responses to my
question revealing my mistaken ways and clarifying without a shade of
a doubt that byLine should be a @property. Or not. (I don't even care
which.)
On Fri, 29 Jan 2010 11:17:04 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 10:40:23 -0500, Andrei Alexandrescu
wrote:
Michel Fortin wrote:
On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer"
said:
Hey, it's that dead horse again, let's beat it!
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin
wrote:
On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer"
said:
ugh... much simpler with a true stream-like range that supports what
is natural for streams:
for(int i = 0; i < count && !range.empty; i++) {
Steven Schveighoffer wrote:
We need digitalmars.D.is_it_a_property_or_not. Whenever in doubt,
people can ask a question there.
OK:
digitalmars.d.should_this_be_a_class_or_struct.
digitalmars.d.should_this_symbol_be_capitalized.
digitalmars.d.should_this_use_a_function_pointer_or_delegate.
di
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 10:40:23 -0500, Andrei Alexandrescu
wrote:
Michel Fortin wrote:
On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer"
said:
Hey, it's that dead horse again, let's beat it!
Andrei and I and several others discussed this ad infinitum. You
w
On Fri, 29 Jan 2010 11:08:37 -0500, Michel Fortin
wrote:
On 2010-01-29 11:00:31 -0500, "Steven Schveighoffer"
said:
On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin
wrote:
On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer"
said:
ugh... much simpler with a true stream-like r
Andrei Alexandrescu wrote:
We need digitalmars.D.is_it_a_property_or_not. Whenever in doubt, people
can ask a question there.
Andrei
Obviously that's a rhetorical suggestion by Andrei ... but
maybe a good idea if all this silliness prevails.
Justin
On 2010-01-29 11:00:31 -0500, "Steven Schveighoffer"
said:
On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin
wrote:
On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer"
said:
ugh... much simpler with a true stream-like range that supports what is
natural for streams:
for(int i =
On 2010-01-29 10:40:23 -0500, Andrei Alexandrescu
said:
I'll tell you what I'd have liked: a landslide of responses to my
question revealing my mistaken ways and clarifying without a shade of a
doubt that byLine should be a @property. Or not. (I don't even care
which.)
The fact we're havin
On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin
wrote:
On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer"
said:
ugh... much simpler with a true stream-like range that supports what is
natural for streams:
for(int i = 0; i < count && !range.empty; i++) {
elements ~= range.get(
On Fri, 29 Jan 2010 10:40:23 -0500, Andrei Alexandrescu
wrote:
Michel Fortin wrote:
On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer"
said:
Hey, it's that dead horse again, let's beat it!
Andrei and I and several others discussed this ad infinitum. You
will never convince Andrei
On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer"
said:
ugh... much simpler with a true stream-like range that supports what is
natural for streams:
for(int i = 0; i < count && !range.empty; i++) {
elements ~= range.get();
}
But of course, then this function doesn't work for other r
On Fri, 29 Jan 2010 10:31:28 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 08:03:13 -0500, Michel Fortin
wrote:
On 2010-01-29 06:25:44 -0500, Pelle Månsson
said:
On 01/29/2010 05:48 AM, Michel Fortin wrote:
No. Calling byLine doesn't change the s
Nick Sabalausky wrote:
"Nick Sabalausky" wrote in message
news:hjtl33$1da...@digitalmars.com...
"Andrei Alexandrescu" wrote in message
news:hjtet5$111...@digitalmars.com...
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:hjtcbd$r0...@digitalmars.com...
Nick Sabalausky wr
Michel Fortin wrote:
On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer"
said:
Hey, it's that dead horse again, let's beat it!
Andrei and I and several others discussed this ad infinitum. You
will never convince Andrei that his design is wrong :)
Andrei is the one who complained that i
1 - 100 of 119 matches
Mail list logo
