On Monday, 22 August 2016 at 21:46:35 UTC, Engine Machine wrote:
I'm sorry if it confuses you... it doesn't confuse me.
Confuses? No.
I do not know why you have to try and prove something that is a
preference. Do you often get in to arguments with people about
how ford is better than chevy or
On 08/23/2016 03:23 AM, Engine Machine wrote:
On Monday, 22 August 2016 at 22:52:28 UTC, ag0aep6g wrote:
[...]
Simply not replying is an option, too. It may be a bit less
polite, but it's better than escalating things.
True, but then you should also take your own advice.
Yeah, I'm going to
On Monday, 22 August 2016 at 22:52:28 UTC, ag0aep6g wrote:
On Monday, 22 August 2016 at 21:46:35 UTC, Engine Machine wrote:
I'm sorry if it confuses you... it doesn't confuse me.
You needed quite some help to get this thing to work. And you
made some mistakes and wrong statements in the
On Monday, 22 August 2016 at 21:46:35 UTC, Engine Machine wrote:
I'm sorry if it confuses you... it doesn't confuse me.
You needed quite some help to get this thing to work. And you
made some mistakes and wrong statements in the process. That's
perfectly fine, but please don't act as if Jack
On Monday, 22 August 2016 at 19:09:34 UTC, Jack Applegame wrote:
On Monday, 22 August 2016 at 18:04:43 UTC, Engine Machine wrote:
How do you seriously think this is cleaner/simpler?
1. No extra encrypted things, such as InstantiateOrEmptySeq
2. Much more understandable.
You have two classes.
On Monday, 22 August 2016 at 19:56:08 UTC, ag0aep6g wrote:
So this is just to avoid typing out `class Pug : Dog {...}
class Dog : Animal {...} class Animal {...}`?
This allows you to create different inheritance chains with the
same components quickly and easily. I don't know any use case,
but
On 08/22/2016 08:54 PM, Engine Machine wrote:
Yeah, but a name means nothing. Change it if you want ;)
Even with a better name it still requires a good amount of thinking by
the reader to see what's going on.
[...]
What it achieves is a uniform way to create a hierarchical relationship
On Monday, 22 August 2016 at 18:48:12 UTC, ag0aep6g wrote:
You can take this further with template constraints. Gives it a
more uniform appearance at the price of some repetition:
class T()
{
int x;
}
class T(A...) : T!(A[0..$-1])
if (A.length > 0 && A[$-1] == "Animal")
{
int
On Monday, 22 August 2016 at 18:04:43 UTC, Engine Machine wrote:
How do you seriously think this is cleaner/simpler?
1. No extra encrypted things, such as InstantiateOrEmptySeq
2. Much more understandable.
You have two classes.
No. I have one template with two specializations. Class template
On Monday, 22 August 2016 at 18:48:12 UTC, ag0aep6g wrote:
On 08/22/2016 08:04 PM, Engine Machine wrote:
How do you seriously think this is cleaner/simpler? You have
two
classes. Their is no uniformity between them. You have
uniformity
between all the derived classes then have a special case
On 08/22/2016 08:04 PM, Engine Machine wrote:
How do you seriously think this is cleaner/simpler? You have two
classes. Their is no uniformity between them. You have uniformity
between all the derived classes then have a special case for the base
class. A certain easy to follow pattern is set up
On Monday, 22 August 2016 at 07:54:36 UTC, Jack Applegame wrote:
On Monday, 22 August 2016 at 00:43:00 UTC, Engine Machine wrote:
The following code works and does what I want!
template InstantiateOrEmptySeq(alias tmpl, args...)
{
alias Seq(T...)=T;
static if (args.length > 0)
On Monday, 22 August 2016 at 00:43:00 UTC, Engine Machine wrote:
The following code works and does what I want!
template InstantiateOrEmptySeq(alias tmpl, args...)
{
alias Seq(T...)=T;
static if (args.length > 0)
alias InstantiateOrEmptySeq = tmpl!(args[0 .. $-1]);
else
On Monday, 22 August 2016 at 00:22:48 UTC, ag0aep6g wrote:
On 08/22/2016 12:06 AM, Engine Machine wrote:
T!()'s "data" is specified in the class just like all the other
derivations. I don't want to have to specify an external base
class as
in your InstaniateOrBase. Why? Because!!! (There
On 08/22/2016 12:06 AM, Engine Machine wrote:
T!()'s "data" is specified in the class just like all the other
derivations. I don't want to have to specify an external base class as
in your InstaniateOrBase. Why? Because!!! (There should be no need to,
and if one goes this route of creating
On Sunday, 21 August 2016 at 21:11:37 UTC, ag0aep6g wrote:
On 08/21/2016 09:29 PM, Engine Machine wrote:
I know you like to play the right or wrong game, but did you
ever learn
that a single example does not prove the truth of something?
But you can show in a single example that something
On 08/21/2016 09:29 PM, Engine Machine wrote:
I know you like to play the right or wrong game, but did you ever learn
that a single example does not prove the truth of something?
But you can show in a single example that something doesn't work. You
tried to do that, and you did it with a
On Sunday, 21 August 2016 at 20:36:54 UTC, Engine Machine wrote:
On Sunday, 21 August 2016 at 19:42:08 UTC, Lodovico Giaretta
wrote:
[...]
You're right. I didn't realize that variables could be shadowed
in classes. Seems dangerous. D doesn't allow shadowing in a
normal context and gives an
On Sunday, 21 August 2016 at 19:42:08 UTC, Lodovico Giaretta
wrote:
On Sunday, 21 August 2016 at 19:29:26 UTC, Engine Machine wrote:
[...]
The problem of this code has nothing to do with aliases. They
work correctly. The problem is variable shadowing. In the
following code, Child has two x
On Sunday, 21 August 2016 at 19:29:26 UTC, Engine Machine wrote:
I know you like to play the right or wrong game, but did you
ever learn that a single example does not prove the truth of
something?
How about something more complex?
Your demagogy will not help you learn the basics of the D
On Sunday, 21 August 2016 at 19:42:08 UTC, Lodovico Giaretta
wrote:
On Sunday, 21 August 2016 at 19:29:26 UTC, Engine Machine wrote:
[...]
The problem of this code has nothing to do with aliases. They
work correctly. The problem is variable shadowing. In the
following code, Child has two x
On Sunday, 21 August 2016 at 19:29:26 UTC, Engine Machine wrote:
[...]
The problem of this code has nothing to do with aliases. They
work correctly. The problem is variable shadowing. In the
following code, Child has two x variables, one of which is only
accessible from a Parent reference,
On Sunday, 21 August 2016 at 06:28:25 UTC, Jack Applegame wrote:
On Sunday, 21 August 2016 at 00:06:07 UTC, Engine Machine wrote:
On Saturday, 20 August 2016 at 22:21:00 UTC, ag0aep6g wrote:
On 08/21/2016 12:11 AM, Engine Machine wrote:
Is there a way to rebind the arguments of a template?
23 matches
Mail list logo
