On Monday, 3 December 2012 at 15:52:24 UTC, Jacob Carlborg wrote:
On 2012-12-03 16:51, Jacob Carlborg wrote:
Because Object is the root of the class hierarchy. That's how
it works
in Java, for example. It's just because of these COM
interfaces, that
are not D interfaces, that we have this beh
eryi[p;
][jk'baC N,.IASWN:ZEHOL;Z
On Tuesday, 4 December 2012 at 08:22:36 UTC, Maxim Fomin wrote:
On Monday, 3 December 2012 at 15:52:24 UTC, Jacob Carlborg
wrote:
On 2012-12-03 16:51, Jacob Carlborg wrote:
Because Object is the root of the class hierarchy. That's how
it works
in Java, for example. It's just because of these C
On Tuesday, 4 December 2012 at 07:38:31 UTC, Maxim Fomin wrote:
On Monday, 3 December 2012 at 23:53:26 UTC, deadalnix wrote:
On Monday, 3 December 2012 at 21:53:47 UTC, Walter Bright
wrote:
I really don't know what issue you're trying to solve here.
The typeid's work fine - and interfaces are n
On 2012-12-04 08:47, Vladimir Panteleev wrote:
I've recently updated my watchdog wrapper script which starts D services
to use gdb and disable rt_trapExceptions. My intention was to bypass D's
standard exception handler and let gdb handle uncaught exceptions, and
perhaps print better stack traces
On Monday, 3 December 2012 at 20:59:24 UTC, Walter Bright wrote:
On 12/4/2012 2:52 AM, Jacob Carlborg wrote:
Note, I'm not saying that an interface should be implicitly
converted to
any class, only to Object.
But not all interfaces come from Objects.
IMO this is a design mistake - the spec
On 2012-12-04 09:22, Maxim Fomin wrote:
And what happens if nobody implements an interface?
import std.stdio;
interface I { }
class A { }
void main()
{
I i;
// assume this is implicit
Object o = cast(Object)i;
writeln(typeid(o));
}
You get a segmentation fault since bot
On Tuesday, 4 December 2012 at 07:38:31 UTC, Maxim Fomin wrote:
On Monday, 3 December 2012 at 23:53:26 UTC, deadalnix wrote:
On Monday, 3 December 2012 at 21:53:47 UTC, Walter Bright
wrote:
I really don't know what issue you're trying to solve here.
The typeid's work fine - and interfaces are n
On 2012-12-04 13:15, foobar wrote:
IMO this is a design mistake - the special case is preferred over the
common case which goes against the D philosophy of making the common
case easy and the special case possible.
All COM instances are known at _compile_time_ as they're all required to
inherit
On Tuesday, 4 December 2012 at 12:26:53 UTC, Jacob Carlborg wrote:
On 2012-12-04 09:22, Maxim Fomin wrote:
And what happens if nobody implements an interface?
import std.stdio;
interface I { }
class A { }
void main()
{
I i;
// assume this is implicit
Object o = cast(Object)i;
On Tuesday, 4 December 2012 at 12:30:29 UTC, Paulo Pinto wrote:
On Tuesday, 4 December 2012 at 12:26:53 UTC, Jacob Carlborg
wrote:
On 2012-12-04 09:22, Maxim Fomin wrote:
And what happens if nobody implements an interface?
import std.stdio;
interface I { }
class A { }
void main()
{
I i;
On 03/12/2012 20:17, Rob T wrote:
On Monday, 3 December 2012 at 14:22:28 UTC, Nick Treleaven wrote:
Most programmers would probably just pollute the existing scope:
auto x = "thing" in arr;
if (x && *x == 45)
{
...
}
You can always wrap it inside its own scope
Yes, that's why I wrote:
On Tuesday, 4 December 2012 at 13:07:59 UTC, foobar wrote:
On Tuesday, 4 December 2012 at 12:30:29 UTC, Paulo Pinto wrote:
On Tuesday, 4 December 2012 at 12:26:53 UTC, Jacob Carlborg
wrote:
On 2012-12-04 09:22, Maxim Fomin wrote:
And what happens if nobody implements an interface?
import std
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
At the risk of being too persistent, curious as to the reason for
disdain for named field initialization syntax and talk of its
deprecation.
- does it cause problems?
- is it on the chopping block?
- is this the best way to find out the status of a specific issue
like this?
This was original
On Tuesday, 4 December 2012 at 13:47:39 UTC, Paulo Pinto wrote:
Generally speaking you are right. But specifically regarding
toString, what would you suggest?
Should each and every Interface have a toString method?
Yes for each interface where you intend to call toString().
That's a lot of
On 04/12/2012 16:24, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
I expect it is, perhaps by disallowing callin
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
module main;
voi
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
This is exactly what Nimrod does. ;-) The () can also be omitted
in calls used as a statement (not as an expression).
BTW Nimrod calls it "method call syntax"; there
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
module main;
voi
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
module main;
voi
03.12.2012 11:49, Oliver Plow:
Just got the idea whether it would make sense to ask the people at
JetBrains whether they would make a plugin for D. IntelliJ IDEA seems
to me to be the IDE with must support for other languages than Java.
The Scala and Groovy plugin to me are the best ones compar
On Tuesday, December 04, 2012 17:35:23 foobar wrote:
> That's a lot of duplication considering D already provides this
> in Object.
Though per the last major discussion on const-correctness and Object, it's
likely that toString, toHash, opCmp, and opEquals will be removed from Object,
in which c
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
module main;
voi
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
module main;
voi
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
module main;
voi
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
I expect it is, perhaps by disallowing calling a property
function with no arguments.
It's regular function called as property [getter] of module.
It's nice to have @property like in C
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
I expect it is, perhaps by disallowing calling a property
function with no arguments.
It's regular function called as property [getter] of module.
It's nice to have @property like in C
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
That's exactly what Nimrod does ;-). It also allows to leave out
the () for calls used as a statement (not as an expression).
BTW Nimrod calls it "method call syntax"
I like this syntax too. I think/hope that for static stuff it
will be here to stay.
On Tuesday, 4 December 2012 at 16:25:12 UTC, Dan wrote:
At the risk of being too persistent, curious as to the reason
for disdain for named field initialization syntax and talk of
its deprecation.
- does it c
On Mon, 03 Dec 2012 04:02:15 -, Timon Gehr wrote:
On 12/02/2012 09:19 PM, Regan Heath wrote:
On Sun, 02 Dec 2012 18:47:26 -, Rob T wrote:
If someone can honestly demonstrate a non-subjective reason why there
must be a difference between function call and variable assignments,
please
On 3 December 2012 02:26, 1100110 <0b1100...@gmail.com> wrote:
> On 11/30/2012 09:08 AM, Andrei Alexandrescu wrote:
>>
>> On 11/30/12 4:49 AM, 1100110 wrote:
>>>
>>> Andrei's support is also necessary, IIRC he is one of main person behind
>>> phobos. A stable version of D is not useful without a st
On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
+1
5.writeln is go
One of my pull requests is experiencing autotester failures on a
particular platform, but I've been unable to reproduce the problem (it
works on my environment, plus I don't have ready access to said
platform).
Is there a simple way of reproducing an autotester failure in a way that
can be used fo
34 matches
Mail list logo
