www.digitalmars.com         C & C++   DMDScript  

D - a few extensiosn on the interface concept?

reply Mark Van De Wielle <mark.vandewielle student.kuleuven.ac.be> writes:
I've been looking at the D specification for a while and I was wondering if
there's any room left in your specification for two small extensions on the
interface concept.  The first being a really logical addition, the second
being something i've been wondering about and would like to hear other
people's opinion on.


First extension is a built-in mechanism for empty interfaces called tags,
which are just boolean true or falses not involving any actual methods.  It
should really take an absolute minimal amount of work to add this to D since
interfaces are already there,  but interfaces and tags should be available
as different concepts. The syntax is completely identical to that of
interfaces:

interface A{
   int foo();
}

tag B;

class C: A, B{
...
}




Second is a way of sort of "class casting" objects at run-time called
interpretation.  With interpretation, an object from class A can be used as
if it belonged to class B by supplying a toB() method in class A.  This is
marked using two standard interfaces called to(...) and from(...), each
taking a list of classes this new class can be used as.
For example say i declare a class Weekdays

class WeekDays: to( String, Integer ){
    ...
    toString(){...}
    toInteger(){...}
}

Now say we have a call somewhere along the lines of
System.out.println( (String)myWeekday )

This would normally throw a class cast exception at run time  (well, in Java
it would, which is what i'm swimming in these days).  With interpretations,
before a class cast exception is thrown, it would first be checked if the
object, while it may no BE a string, can be USED as a string.  The interface
Interpretable seems to be implemented, the object seems to be interpretable
as a String - so the function toString() is called and the world keeps on
spinning.  

The from() interface would work the other way around.  If a class A says it
can interpret class B there should be a constructor A taking an object of
class B as its only parameter.  In case of ambiguity the to() conversion
preceeds the from() conversion.

Interpretations do NOT offer any great new abilities, but i think they offer
a powerful simplification of class conversion.  Any thoughts (including
"this is BS" or "just syntactic sugar, not worth mentioning") are welcome of
course :-)



That's my 2 cents
A nice day to all of you


mark
Jan 12 2003
next sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
A tag seems no different to me than an interface with no methods.  Just use
an empty interface.  RTTI will allow you to dynamically convert or test
presence of a "tag".

I've thought about the "interpretation" thing quite a bit in regards to C++
and it seems to me that conversion constructors (from()) and user-defined
conversions (to()) are really the same thing.  The only reason they exist in
C++ is because you cannot define new constructors on the basic types.  They
introduce ambiguity in C++;  for instance you can specify explicit on ctors,
but not on user-defined conversions.  I suppose scope access could be
another issue but in D there's a way around this:  define the conversion to
char[] or int in the same module as the class you're converting from.
Anything in a module can access private members of anything else in the
module.  This may or may not be a perfect solution but it works.

All we need is the ability to add "decorators" on existing classes or types.
That includes methods which access the public interface and constructors.

Another way to think about ctors is in terms of assignment.  The only
difference being that assignment assumes the object is already constructed
an valid and is just taking a new value from somewhere else.  D doesn't
currently have overloaded assignment, so one would assume that assignment of
one class to another would involve copying a temporary object created with a
converting constructor.

Another way to approach this whole mess is to give your class the same
interface as class char[] or class int.  Right now there are no interfaces
specified for the basic types, and I'm not sure it's feasible since
interfaces seem inherently tied to the vtable and basic types don't have a
vtable.

It seems a valid and useful concept which is currently not addressed all
that well in D.

Sean

"Mark Van De Wielle" <mark.vandewielle student.kuleuven.ac.be> wrote in
message news:BA47265E.4A31%mark.vandewielle student.kuleuven.ac.be...

 I've been looking at the D specification for a while and I was wondering


if

 there's any room left in your specification for two small extensions on


the

 interface concept.  The first being a really logical addition, the second
 being something i've been wondering about and would like to hear other
 people's opinion on.


 First extension is a built-in mechanism for empty interfaces called tags,
 which are just boolean true or falses not involving any actual methods.


It

 should really take an absolute minimal amount of work to add this to D


since

 interfaces are already there,  but interfaces and tags should be available
 as different concepts. The syntax is completely identical to that of
 interfaces:

 interface A{
    int foo();
 }

 tag B;

 class C: A, B{
 ...
 }




 Second is a way of sort of "class casting" objects at run-time called
 interpretation.  With interpretation, an object from class A can be used


as

 if it belonged to class B by supplying a toB() method in class A.  This is
 marked using two standard interfaces called to(...) and from(...), each
 taking a list of classes this new class can be used as.
 For example say i declare a class Weekdays

 class WeekDays: to( String, Integer ){
     ...
     toString(){...}
     toInteger(){...}
 }

 Now say we have a call somewhere along the lines of
 System.out.println( (String)myWeekday )

 This would normally throw a class cast exception at run time  (well, in


Java

 it would, which is what i'm swimming in these days).  With


interpretations,

 before a class cast exception is thrown, it would first be checked if the
 object, while it may no BE a string, can be USED as a string.  The


interface

 Interpretable seems to be implemented, the object seems to be


interpretable

 as a String - so the function toString() is called and the world keeps on
 spinning.

 The from() interface would work the other way around.  If a class A says


it

 can interpret class B there should be a constructor A taking an object of
 class B as its only parameter.  In case of ambiguity the to() conversion
 preceeds the from() conversion.

 Interpretations do NOT offer any great new abilities, but i think they


offer

 a powerful simplification of class conversion.  Any thoughts (including
 "this is BS" or "just syntactic sugar, not worth mentioning") are welcome


of

 course :-)



 That's my 2 cents
 A nice day to all of you


 mark
Jan 12 2003
prev sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Mark Van De Wielle" <mark.vandewielle student.kuleuven.ac.be> escreveu na
mensagem news:BA47265E.4A31%mark.vandewielle student.kuleuven.ac.be...

 I've been looking at the D specification for a while and I was wondering


if

 there's any room left in your specification for two small extensions on


the

 interface concept.  The first being a really logical addition, the second
 being something i've been wondering about and would like to hear other
 people's opinion on.


 First extension is a built-in mechanism for empty interfaces called tags,
 which are just boolean true or falses not involving any actual methods.


It

 should really take an absolute minimal amount of work to add this to D


since

 interfaces are already there,  but interfaces and tags should be available
 as different concepts. The syntax is completely identical to that of
 interfaces:

 interface A{
    int foo();
 }

 tag B;

 class C: A, B{
 ...
 }




 Second is a way of sort of "class casting" objects at run-time called
 interpretation.  With interpretation, an object from class A can be used


as

 if it belonged to class B by supplying a toB() method in class A.  This is
 marked using two standard interfaces called to(...) and from(...), each
 taking a list of classes this new class can be used as.
 For example say i declare a class Weekdays

 class WeekDays: to( String, Integer ){
     ...
     toString(){...}
     toInteger(){...}
 }

 Now say we have a call somewhere along the lines of
 System.out.println( (String)myWeekday )

 This would normally throw a class cast exception at run time  (well, in


Java

 it would, which is what i'm swimming in these days).  With


interpretations,

 before a class cast exception is thrown, it would first be checked if the
 object, while it may no BE a string, can be USED as a string.  The


interface

 Interpretable seems to be implemented, the object seems to be


interpretable

 as a String - so the function toString() is called and the world keeps on
 spinning.

 The from() interface would work the other way around.  If a class A says


it

 can interpret class B there should be a constructor A taking an object of
 class B as its only parameter.  In case of ambiguity the to() conversion
 preceeds the from() conversion.

 Interpretations do NOT offer any great new abilities, but i think they


offer

 a powerful simplification of class conversion.  Any thoughts (including
 "this is BS" or "just syntactic sugar, not worth mentioning") are welcome


of

 course :-)



 That's my 2 cents
 A nice day to all of you


 mark



Hi,

    Tags are just like empty interfaces, you will just save some typing, and
lose a good variable name. The semantics is the same:


tag B;
interface B {}


    And usually when you are defining the responsibilities of your objects
you don't just add marker interfaces. In Java it's a common idiom (e.g.
Cloneable, Serializable, RandomAccess) but IMO it is a hack due to Java's
inadequate type system and object architecture (I work as a Java developer
so I know what I'm talking about). Some time later you'll need to define a
method in your tag, promoting it to interface level. As a side note, a nice
use for interfaces in D would be using then to add dynamic type hierarchies.
If you get two classes defined in different libraries, say Socket and
ResultSet, both with a close() method but no common superclass defining
this, you could create a Closeable interface with a close() method, and
automatically a Socket or a ResultSet could be used as a Closeable. This
usage of interfaces, to provide structural subtyping could be useful.
    To and from methods are a useful thing, but I think it's better to write
a explicit method call, instead of realying in context sensitive
conversions. Suppose if you have the following code:


String name = cast(String) dataHolder.get(); //  get() returns something
with Object type


    You as a maintenance programmer will expect to extract a String and use
the cast to restore type information or that you're transforming the object
inserted in dataHolder into it's String representation? In Java when we cast
to a String we're saying to the compiler "I'm saying this is a String, if
not this is an error, so tell me so". When we use the toString() method
we're saying "I want to use this class string representation, whatever that
means".
    From methods would be good, but they're kind of virtual constructors.
Immutable value objects should have a from constructor for the different
types it support (e.g. string or xml formats). A good example of this is the
Java's Collection hierarchies idiom of always providing a constructor that
takes a Collection to allow copy constructors. This can't be enforced by the
Java compiler, and to provide something like it in D would require a large
change in it's type system AFAICS.
    Keep the ideas and critics coming. That's the only way we can improve D.

    Best regards,
    Daniel Yokomiso.

"Life is not a matter of holding good cards, but of playing a poor hand
well."
- Robert Louis Stephenson


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.435 / Virus Database: 244 - Release Date: 30/12/2002
Jan 12 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:avt4sm$12mb$1 digitaldaemon.com...

 (I work as a Java developer
 so I know what I'm talking about).


I don't think Java has much of any resemblance to D, but a lot of people who
just glance at it seem to think "hmm, garbage collection on C++, must be
Java!". Would you be interested in writing up something brief about D vs
Java? It takes an expert in both languages to do a proper job.
Jan 13 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Walter" <walter digitalmars.com> escreveu na mensagem
news:avu2df$20s3$1 digitaldaemon.com...

 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:avt4sm$12mb$1 digitaldaemon.com...

 (I work as a Java developer
 so I know what I'm talking about).


 I don't think Java has much of any resemblance to D, but a lot of people


who

 just glance at it seem to think "hmm, garbage collection on C++, must be
 Java!". Would you be interested in writing up something brief about D vs
 Java? It takes an expert in both languages to do a proper job.


I can write a medium sized-post after friday. BTW where's the D journal? Is
this project alive? I have some ideas of articles for it and interested in
writing. Anyone knows something about it?


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.435 / Virus Database: 244 - Release Date: 30/12/2002
Jan 14 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:b028i1$1vav$1 digitaldaemon.com...

 I can write a medium sized-post after friday.


Great!


 BTW where's the D journal? Is
 this project alive? I have some ideas of articles for it and interested in
 writing. Anyone knows something about it?


Matthew Wilson is in charge of it, I think he's just waiting for some
articles!
Jan 26 2003
parent "Christopher J. Sequeira" <csequeir __mit.edu> writes:
Here's the URL for The D Journal:

http://www.thedjournal.com/


Walter wrote:

 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:b028i1$1vav$1 digitaldaemon.com...
 

I can write a medium sized-post after friday.


 
 
 Great!
 
 

BTW where's the D journal? Is
this project alive? I have some ideas of articles for it and interested in
writing. Anyone knows something about it?


 
 
 Matthew Wilson is in charge of it, I think he's just waiting for some
 articles!
 
 



-- 
Christopher J. Sequeira '05
csequeir __mit.edu (remove hyphens for email)
Jan 26 2003