Daniel Yokomiso wrote:
> "Walter" <walter@digitalmars.com> escreveu na mensagem
> news:b411ej$2gpo$1@digitaldaemon.com...
> 
>>"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message
>>news:b40pqk$2c3e$1@digitaldaemon.com...
>>
>>>"Walter" <walter@digitalmars.com> escreveu na mensagem
>>>
>>>>I've been looking at adding 'virtual types', too.
>>>>
>>>
>>>By virtual types do you mean Beta like virtual classes?
>>>http://www.mjolner.com/mjolner-system/documentation/beta-intro/
>>
>>I don't understand Beta at all.
>>
> 
> 
> There's a good paper about virtual types and genericity in Beta:
> 
> http://citeseer.nj.nec.com/thorup99unifying.html
> 
> What'll be virtual types in D?
> 
> 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.459 / Virus Database: 258 - Release Date: 26/2/2003
> 
> 

Just two more facts supporting the need for "virtual class" functionallity.

I just counted 5 places in an IC router I'm working on that would benifit from inheriting graph functionality.  Virtual classes allow this to happen in a way that's natural.

There have been no entries in "The Great D Pizza Contest" so far.  No one on this group has yet succeeded in writing a reusable graph package in D of any kind (although Patric Down made a good start).  I'm still offering 30 bucks worth of pizza for it.

Here's an interesting idea... Walter, can I bribe you with 30 bucks worth of pizza to add vitual classes or Sather's "include" constructs? If so, I see a lot of pizza in your future.

Bill

Hi,

    Comments embedded.

"Bill Cox" <bill@viasic.com> escreveu na mensagem
news:3E64B6C0.9040903@viasic.com...
[snip]
>
> Hi, Daniel.
>
> I read most of the paper you listed.  Yep.  Those are virtual types, and they provide a powerful programming capability.  One major problem I have with the version of virtual types described in the paper is that I will probably fail in getting my team to use them.  Look at how long and hard to understand the paper is.  It's not the author's fault, it's simply a difficult subject.  The other major issue I have with them is they look really hard to implement.


    Every level of abstraction requires more models and less "reality" than
the earlier level. Most programmers don't need to understand the details of
a sufficiently advanced type system, but it should be easy enough for them
to use without much problems. Something like: "Hey Bob, here's what you'll
do. Inherit from this generic class Alice wrote using such and such
parameters and everything will be alright". If the library hides all the
complexity from the programmer and the usage syntax is simple, nothing will
go wrong. Perhaps I'm too opmistic, but I don't think that Beta-like virtual
types should be that hard to implement. AFAICS they're just another level of
indirection.


> An even more powerfull capability can be found in Sather, although it doesn't have the static type checking capability.  It's called "include" in that language.  The "include" construct seems easy to understand and use, and it is very easy to implement.
>
> Here's a URL to the manual page on the "include" construct.
>
>
http://www.icsi.berkeley.edu/~sather/Documentation/LanguageDescription/webma ker/DescriptionX2Erem-chapters-1.html#HEADING1-2
>
> I think the lack of static type checking makes it more powerful, not less.  For example, with the include construct, I can apply a module's functionality to all kinds of other modules, even though they don't in any way inherit from anything that the original module knows about. That's the way it should be.  You can also apply a module's functionality multiple times to other modules, without any multiple-inheritance kinds of crud in the compiler or generated code.
>
> Another nice advantage of the "include" construct is that it allows us to reuse any code, not just template code.  You don't have to rely on a programmer having 20/20 foresight and providing exactly correct template wrappers in order for you to reuse his code.  Everything is a template.


    Hmmm, code inclusion is a form of inheritance. However there's no
subtyping relationship. If we keep these two concepts separated, subclassing
and subtyping, we have more coherence in the type system (i.e. no more
non-conforming subtypes). Inheritance is a mechanism that many languages use
to achieve subtyping but it's not its only use.
    AFAIK there are no problems regaring static type checking of included
partial classes. Could you elaborate more on that?
    Eiffel is planning to include a code inclusion form of inheritance,
called "non-conforming inheritance" in the next version (ETL 3). I don't
know about other statically typed languages using this mechanism, but I
think it's checked by the compiler.
    About the last remark, include mechanisms are based on inheritance.
Templates are based on composition (i.e. template parameters). One can be
used to emulate the other, it's just a matter of taste. IMHO there's no way
to create a generic module that'll satisfy everyone, as time passes we'll
always refactor base modules to improve extensibility or genericity. Mixin
are easier to extend, but templates are easier to use, you don't need to
subclass them and write hook functions.

> Perl has some difficult to understand features.  However, I've never seen a single one get used, and I've read a lot of Perl code.  It also has very very many simple features that get used all the time (too often in my opinion).  I think that's a major part of Perl's success.
>
> I'm putting in a vote for the simple version of virtual types (Sather's "include" construct).  The KISS rule is rarely wrong.
>
> Bill


    IMO we should first start using D and see what are really the
deficiencies in current mechanisms (e.g. templates, classes, delegates). If
these tools fails us then we should implement alternatives. Putting features
without real need it's always a bad decision.

    Best regards,
    Daniel Yokomiso.

"Physics is like sex: sure, it may give some practical results, but that's
not why we do it."
- Richard Feynman


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/2/2003

"Bill Cox" <bill@viasic.com> wrote in message news:3E64B884.9060901@viasic.com...
> I just counted 5 places in an IC router I'm working on that would benifit from inheriting graph functionality.  Virtual classes allow this to happen in a way that's natural.

What I was thinking is to allow:

class C { }
class D : C { }

class A
{
    C c;
}

class B : A
{
    D c;
}

where A.c shares its storage with B.c, instead of B.c creating a new, distinct member. It will work just like virtual functions (but no vtable is required). With my reading of virtual types, this mechanism looks like it should cover the territory. What do you think?

> There have been no entries in "The Great D Pizza Contest" so far.  No one on this group has yet succeeded in writing a reusable graph package in D of any kind (although Patric Down made a good start).  I'm still offering 30 bucks worth of pizza for it.

I was thinking of running some sort of contest too, with a Digital Mars t-shirt as the prize, but I don't know what the challenge should be.

> Here's an interesting idea... Walter, can I bribe you with 30 bucks worth of pizza to add vitual classes or Sather's "include" constructs? If so, I see a lot of pizza in your future.

I'm pretty burned out on pizza <g>. If you want to help out Digital Mars financially, the best way is to buy the CD from www.digitalmars.com/shop.html, buy a nerd shirt from www.digitalmars.com/gift/index.html, or when you buy anything from amazon, reach amazon through one of the links at www.digitalmars.com/bibliography.html.

"Walter" <walter@digitalmars.com> escreveu na mensagem news:b42l2l$beu$1@digitaldaemon.com...
>
> "Bill Cox" <bill@viasic.com> wrote in message news:3E64B884.9060901@viasic.com...
> > I just counted 5 places in an IC router I'm working on that would benifit from inheriting graph functionality.  Virtual classes allow this to happen in a way that's natural.
>
> What I was thinking is to allow:
>
> class C { }
> class D : C { }
>
> class A
> {
>     C c;
> }
>
> class B : A
> {
>     D c;
> }
>
> where A.c shares its storage with B.c, instead of B.c creating a new, distinct member. It will work just like virtual functions (but no vtable
is
> required). With my reading of virtual types, this mechanism looks like it should cover the territory. What do you think?

Won't this break lots of code? All places that assign to c will need revision. Also with interface semantics subtle bugs can appear (this is a issue with covariant return types too):

interface I {
    int foo();
}

class C : I {
    int foo() {
        return 1;
    }
}
class D : C, I {
    int foo() {
        return 2;
    }
}
class A {
    C c;
}
class B : A {
    D d;
}

A a = new B();

I i = cast(I) a.c;
i.foo(); // what will it return? there's any implicit casts to C here?


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/2/2003

Hi, Walter.

> What I was thinking is to allow:
> 
> class C { }
> class D : C { }
> 
> class A
> {
>     C c;
> }
> 
> class B : A
> {
>     D c;
> }
> 
> where A.c shares its storage with B.c, instead of B.c creating a new,
> distinct member. It will work just like virtual functions (but no vtable is
> required). With my reading of virtual types, this mechanism looks like it
> should cover the territory. What do you think?

This looks close.  However, I get into some trouble in that the classes I want to add graph functionality to may already inherit from another class.  In D, we'd have to make Graph an interface, or we'd be into multiple inheritance teritory.  Interfaces aren't quite what I want, since I'd like some members from Graph, Node, and Edge added to my classes so that the Graph methods could run.

The "include" feature from Sather doesn't seem to suffer from this problem.  Of course, you could add multiple inheritance as a feature, but I'd be against it.

>>There have been no entries in "The Great D Pizza Contest" so far.  No
>>one on this group has yet succeeded in writing a reusable graph package
>>in D of any kind (although Patric Down made a good start).  I'm still
>>offering 30 bucks worth of pizza for it.
> 
> 
> I was thinking of running some sort of contest too, with a Digital Mars
> t-shirt as the prize, but I don't know what the challenge should be.
> 
> 
>>Here's an interesting idea... Walter, can I bribe you with 30 bucks
>>worth of pizza to add vitual classes or Sather's "include" constructs?
>>If so, I see a lot of pizza in your future.
> 
> 
> I'm pretty burned out on pizza <g>. If you want to help out Digital Mars
> financially, the best way is to buy the CD from
> www.digitalmars.com/shop.html, buy a nerd shirt from
> www.digitalmars.com/gift/index.html, or when you buy anything from amazon,
> reach amazon through one of the links at
> www.digitalmars.com/bibliography.html.

Ok.

-- Bill

>
> What I was thinking is to allow:
>
> class C { }
> class D : C { }
>
> class A
> {
>     C c;
> }
>
> class B : A
> {
>     D c;
> }
>
> where A.c shares its storage with B.c, instead of B.c creating a new, distinct member. It will work just like virtual functions (but no vtable
is
> required). With my reading of virtual types, this mechanism looks like it should cover the territory. What do you think?
>
it is basically a light weight template, (different type be not need change to code); dynamic array, list or tree classes would benift from a good syntax to allow this type of construct.

why not ;

class A( T : C ) // must define the base class
{
     T c;
}

class B : A(D)
{
}

I think the syntax is O.K.

int func( A(D) a ) {
    ....
}

int other() { return func( new B() ); }

arrays/new arrays might cause parsing problems as the types A and D may not be known at the time the line is parsed

A(D)[] ar = new A(D)[4];

forcing an alias first would solve any problems there, no bigger issue than
having to instatiate templates first.
alias A(D) AD; or use the asme syntax as real templates.

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:b42m76$c9c$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> escreveu na mensagem news:b42l2l$beu$1@digitaldaemon.com...
> >
> > "Bill Cox" <bill@viasic.com> wrote in message news:3E64B884.9060901@viasic.com...
> > > I just counted 5 places in an IC router I'm working on that would benifit from inheriting graph functionality.  Virtual classes allow
this
> > > to happen in a way that's natural.
> >
> > What I was thinking is to allow:
> >
> > class C { }
> > class D : C { }
> >
> > class A
> > {
> >     C c;
> > }
> >
> > class B : A
> > {
> >     D c;
> > }
> >
> > where A.c shares its storage with B.c, instead of B.c creating a new, distinct member. It will work just like virtual functions (but no vtable
> is
> > required). With my reading of virtual types, this mechanism looks like
it
> > should cover the territory. What do you think?
>
> Won't this break lots of code? All places that assign to c will need revision. Also with interface semantics subtle bugs can appear (this is a issue with covariant return types too):
>
> interface I {
>     int foo();
> }
>
> class C : I {
>     int foo() {
>         return 1;
>     }
> }
> class D : C, I {
>     int foo() {
>         return 2;
>     }
> }
> class A {
>     C c;
> }
> class B : A {
>     D d;

I assume you meant D c; here.

> }
>
> A a = new B();
>
> I i = cast(I) a.c;
> i.foo(); // what will it return? there's any implicit casts to C here?

It will work, in this case, exactly as if (in the current implementation):
    A a = new B();
    a.c = new D();
    I i = cast(I) a.c;
    i.foo();

"Walter" <walter@digitalmars.com> escreveu na mensagem news:b42pbd$edm$1@digitaldaemon.com...
>
> "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:b42m76$c9c$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> escreveu na mensagem news:b42l2l$beu$1@digitaldaemon.com...
> > >
> > > "Bill Cox" <bill@viasic.com> wrote in message news:3E64B884.9060901@viasic.com...
> > > > I just counted 5 places in an IC router I'm working on that would benifit from inheriting graph functionality.  Virtual classes allow
> this
> > > > to happen in a way that's natural.
> > >
> > > What I was thinking is to allow:
> > >
> > > class C { }
> > > class D : C { }
> > >
> > > class A
> > > {
> > >     C c;
> > > }
> > >
> > > class B : A
> > > {
> > >     D c;
> > > }
> > >
> > > where A.c shares its storage with B.c, instead of B.c creating a new, distinct member. It will work just like virtual functions (but no
vtable
> > is
> > > required). With my reading of virtual types, this mechanism looks like
> it
> > > should cover the territory. What do you think?
> >
> > Won't this break lots of code? All places that assign to c will need revision. Also with interface semantics subtle bugs can appear (this is
a
> > issue with covariant return types too):
> >
> > interface I {
> >     int foo();
> > }
> >
> > class C : I {
> >     int foo() {
> >         return 1;
> >     }
> > }
> > class D : C, I {
> >     int foo() {
> >         return 2;
> >     }
> > }
> > class A {
> >     C c;
> > }
> > class B : A {
> >     D d;
>
> I assume you meant D c; here.

yes, my mistake.


> > }
> >
> > A a = new B();
> >
> > I i = cast(I) a.c;
> > i.foo(); // what will it return? there's any implicit casts to C here?
>
> It will work, in this case, exactly as if (in the current implementation):
>     A a = new B();
>     a.c = new D();
>     I i = cast(I) a.c;
>     i.foo();

    Hmmm, so it'll return 1. This return 2, I suppose:


B b = new B();
I i = cast(I) b.c;
i.foo();


    Will this code be valid?


A a = new B();
a.c = new C();


    Or you'll add rules disallowing such classes (i.e. B) to covariantly
redefine some of its attributes types? BTW the quick cheat sheet of variance
is: "in" parameters must be contravariant, "out" and return type must be
covariant and inout must be invariant. The same rules could be applied to
D's type system, and everything would be type-safe. Or we could follow the
Eiffel road and allow CAT calls (i.e. type mismatches due to type anchors,
similar to virtual types).


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/2/2003

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b42nk1$dad$1@digitaldaemon.com...
> >
> > What I was thinking is to allow:
> >
> > class C { }
> > class D : C { }
> >
> > class A
> > {
> >     C c;
> > }
> >
> > class B : A
> > {
> >     D c;
> > }
> >
> > where A.c shares its storage with B.c, instead of B.c creating a new, distinct member. It will work just like virtual functions (but no vtable
> is
> > required). With my reading of virtual types, this mechanism looks like
it
> > should cover the territory. What do you think?
> >
> it is basically a light weight template, (different type be not need
change
> to code); dynamic array, list or tree classes would benift from a good syntax to allow this type of construct.
>
> why not ;
>
> class A( T : C ) // must define the base class
> {
>      T c;
> }
>
> class B : A(D)
> {
> }
>
> I think the syntax is O.K.

It leads to similar ambiguity problems that C++ suffers from with A<D>

>
> int func( A(D) a ) {
>     ....
> }
>
> int other() { return func( new B() ); }
>
> arrays/new arrays might cause parsing problems as the types A and D may
not
> be known at the time the line is parsed

Yes. Need to be able to parse D without needing to do semantic analysis.

> A(D)[] ar = new A(D)[4];
>
> forcing an alias first would solve any problems there, no bigger issue
than
> having to instatiate templates first.
> alias A(D) AD; or use the asme syntax as real templates.

That would likely be better.

Can we have support for "typename" as in C++?  It doesn't have to have the same keyword.

It's mainly for templates, to indicate to the compiler that something is a type not a value, and for when you don't know whether something is a class, basic type, enum, or whatever.

I would specifically like for it not to require being in a template, thus we could use it for any kind of forward declaration where the exact type isn't needed.

Unless D doesn't ever need a forward declaration?  I suspect that it still would require them in certain cases..

Sean