https://issues.dlang.org/show_bug.cgi?id=19767
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=19767
Basile-z changed:
What|Removed |Added
CC|b2.t...@gmx.com |
--
https://issues.dlang.org/show_bug.cgi?id=19767
Andrei Alexandrescu changed:
What|Removed |Added
CC||and...@erdani.com
https://issues.dlang.org/show_bug.cgi?id=19767
Basile-z changed:
What|Removed |Added
CC||b2.t...@gmx.com
Hardware|x86_64
https://issues.dlang.org/show_bug.cgi?id=19767
Issue ID: 19767
Summary: Classes that inherit from an interface can override
static interface methods
Product: D
Version: D2
Hardware: x86_64
OS: Linux
First things first: I've been told on IRC that this idea has already come
up and was rejected in favor of template guards. But it wasn't clear what
the reasons were.
The idea is to have static interface or protocol for structs similar
to the interface for classes. The benefit comes from
that this idea has already come up
and was rejected in favor of template guards. But it wasn't clear what the
reasons were.
The idea is to have static interface or protocol for structs similar to
the interface for classes. The benefit comes from the fact that in D we
often see structs used
On 10/11/11, Gor Gyolchanyan gor.f.gyolchan...@gmail.com wrote:
Actually, the __traits(compiles, ...) is a marvelous and very powerful
tool that will allow you to test if the struct is fit for your
particular task by just specifying the task.
Yeah, but you have to write very specific code to
Right. It is far too verbose, but those protocols are too restrictive.
With no run-time value, the protocols must be very flexible to contain
any kind of requirements on structs, that are practically useful to
have.
The __traits(compiles, ...) would be awesome to be automatically be
used in
BTW, you can make a template, which takes an interface type and a
struct type and evaluates to a bool, indicating whether the struct
theoretically implements the interface.
I actually had a success in doing something similar.
Here are the main features I use in these situations:
You can have those protocols: import(my_protocol.pr);
mixin(parseProtocol(protocol)), etc...
On Tue, Oct 11, 2011 at 6:24 PM, Gor Gyolchanyan
gor.f.gyolchan...@gmail.com wrote:
BTW, you can make a template, which takes an interface type and a
struct type and evaluates to a bool, indicating
Leandro Lucarella llu...@gmail.com wrote:
What do you think?
I was inspired:
template staticInterface( T, iface ) {
static assert( is( iface == interface ) );
static assert( is( T == struct ) );
alias staticInterfaceImpl!( T, MemberTuple!( iface ) ) staticInterface;
}
Simen kjaeraas, el 19 de noviembre a las 12:47 me escribiste:
Leandro Lucarella llu...@gmail.com wrote:
What do you think?
I was inspired:
[...]
Usage:
interface I;
struct S;
static if ( staticInterface!( S, I ) ) {}
[...]
Nice! :)
--
Leandro Lucarella (AKA luca)
In order to achieve good completion support by editors (like
IntelliSense) with duck-typed variables, concept-checking code should
contain more type information than that of the code now used in Phobos.
Example:
static interface InputRange(T) {
const bool empty();
T front();
void
rearranged your code to see the equivalent snippets side-by-side:
static interface InputRange(T) {
bool empty();
T front();
void popFront();
}
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
{
R r;
if (r.empty) {}
r.popFront
is: is it really that much of an improvement?
I've rearranged your code to see the equivalent snippets side-by-side:
static interface InputRange(T) {
bool empty();
T front();
void popFront();
}
template isInputRange(R)
{
enum bool isInputRange = is(typeof
Lars T. Kyllingstad, el 17 de noviembre a las 09:54 me escribiste:
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature. Whether the code will work is really the minimal
restriction you can place
can't use arrays)
2) All calls to ranges functions are virtual (inefficient; this is
particularly relevant since they are called inside loops = lot of
times)
A static interface don't have those problems, and I don't see a way to mix
static and dynamic interfaces without introducing
Leandro Lucarella wrote:
Lars T. Kyllingstad, el 17 de noviembre a las 09:54 me escribiste:
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature. Whether the code will work is really the minimal
== Quote from Leandro Lucarella (llu...@gmail.com)'s article
Lars T. Kyllingstad, el 17 de noviembre a las 09:54 me escribiste:
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature. Whether the
Lars T. Kyllingstad, el 17 de noviembre a las 15:12 me escribiste:
Leandro Lucarella wrote:
Lars T. Kyllingstad, el 17 de noviembre a las 09:54 me escribiste:
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific
On 2009-11-17 09:12:04 -0500, Lars T. Kyllingstad
pub...@kyllingen.nospamnet said:
That's why I mentioned infinite ranges. An infinite range is *defined*
as a range where empty is implemented as
enum bool empty = false;
isInfinite(Range) tests whether this is the case, which it wouldn't
messages from failures of __traits(compiles, xxx).
My question is: is it really that much of an improvement?
I've rearranged your code to see the equivalent snippets side-by-side:
static interface InputRange(T) {
bool empty();
T front();
void popFront
is a very nice feature
which might deserve a little magic to avoid the boilerplate (or at least
odd implementation).
What I'm suggesting is just some syntax sugar for compile-time
duck-typing. My suggestion is to make this (a real example from the range
module):
static interface InputRange(T
Leandro Lucarella schrieb:
What do you think?
I like it.
Leandro Lucarella Wrote:
static interface InputRange(T) {
Few days ago a professional C# programmer, a smart person that doesn't know
much about D, has asked me if in D there are static interfaces. I think he was
thinking about something similar.
I think that's a nice idea, or it can become
Is there a reason not to have all interfaces compile time checked? It would
still be allowable to state a class implements an interface and have the
compiler check it.
The reason I say this is it would remove the complexity of having the two types
of interfaces. And if you wanted to be able to
Leandro Lucarella wrote:
Why not? ;)
The actual question is if Andrei/Walter are interested at all in this.
Because they didn't show any interest so far. D will probably be doomed
to compile time bug-typing I mean duck-typing forever.
static interface InputRange(T) {
bool empty
grauzone wrote:
Leandro Lucarella wrote:
Why not? ;)
The actual question is if Andrei/Walter are interested at all in this.
Because they didn't show any interest so far. D will probably be doomed
to compile time bug-typing I mean duck-typing forever.
There's an embarrassment of riches
Andrei Alexandrescu wrote:
grauzone wrote:
Leandro Lucarella wrote:
Why not? ;)
The actual question is if Andrei/Walter are interested at all in this.
Because they didn't show any interest so far. D will probably be
doomed to compile time bug-typing I mean duck-typing forever.
There's an
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Leandro Lucarella wrote:
Why not? ;)
The actual question is if Andrei/Walter are interested at all in
this. Because they didn't show any interest so far. D will probably
be doomed to compile time bug-typing I mean duck-typing
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Leandro Lucarella wrote:
Why not? ;)
The actual question is if Andrei/Walter are interested at all in
this. Because they didn't show any interest so far. D will probably
be doomed to compile time
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Leandro Lucarella wrote:
Why not? ;)
The actual question is if Andrei/Walter are interested at all in
this. Because they didn't show any interest so far. D will probably
be doomed to
from the interface (i.e., you can't use arrays)
2) All calls to ranges functions are virtual (inefficient; this is
particularly relevant since they are called inside loops = lot of
times)
A static interface don't have those problems, and I don't see a way to mix
static and dynamic interfaces
Andrei Alexandrescu, el 16 de noviembre a las 12:19 me escribiste:
grauzone wrote:
Leandro Lucarella wrote:
Why not? ;)
The actual question is if Andrei/Walter are interested at all in
this. Because they didn't show any interest so far. D will
probably be doomed to compile time bug-typing
On Mon, Nov 16, 2009 at 9:25 AM, Leandro Lucarella llu...@gmail.com wrote:
Why not? ;)
I know you might want to hit me for bringing just another feature request
inspired in Google's Go, but please do read it without preconceptions,
because I think the features I'm suggesting are mostly
Leandro Lucarella wrote:
Andrei Alexandrescu, el 16 de noviembre a las 12:19 me escribiste:
grauzone wrote:
Leandro Lucarella wrote:
Why not? ;)
The actual question is if Andrei/Walter are interested at all in
this. Because they didn't show any interest so far. D will
probably be doomed to
to see the equivalent snippets side-by-side:
static interface InputRange(T) {
bool empty();
T front();
void popFront();
}
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
{
R r;
if (r.empty) {}
r.popFront;
auto h
(inefficient; this is
particularly relevant since they are called inside loops = lot of
times)
A static interface don't have those problems, and I don't see a way to mix
static and dynamic interfaces without introducing a new type of
interfaces (static interface).
I realize that a class
39 matches
Mail list logo
