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

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
>

"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

"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.

"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

"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!

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)