Jump to page: 1 2
Thread overview
suggestion for template equivalent
Aug 16, 2001
Chris Friesen
Aug 16, 2001
Walter
Aug 17, 2001
Michael Lindner
Aug 17, 2001
Chris Friesen
Aug 18, 2001
Michael Lindner
Aug 17, 2001
Sheldon Simms
Aug 17, 2001
Chris Friesen
Aug 17, 2001
Sheldon Simms
Aug 17, 2001
Charles Hixson
Aug 17, 2001
Chris Friesen
Aug 26, 2001
Walter
Aug 26, 2001
Walter
Aug 18, 2001
Brent Schartung
August 16, 2001
I remember the generic types in Eiffel as being very convenient.  Perhaps you could do something equivalent?

An example would be a stack.  A simplistic example would be something like

class Stack : T
{
   int push(T item);
   T pop();
   T[] storage;
   int arrayIndex;
}

Then you could use it as

int main()
{
   Stack:int myStack;
   myStack.push(5);
   int a = myStack.pop
}


To get a bit fancier, you could have some constraints on what the generic type is

class BinaryTree : T->Sortable
{
  insert(T item);
  ...
}


Then we would have a base virtual Sortable class that has virtual routines that define what it is to be sortable.  Those routines would then be accessable within the BinaryTree methods.

Of course, this really only comes into its own if you can have multiple inheritance so that you can inherit from Sortable as well as whatever your real parent is.

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com
August 16, 2001
That's a great idea. But I want to try to make it work without needing multiple inheritance!

"Chris Friesen" <cfriesen@nortelnetworks.com> wrote in message news:3B7C1DB9.F5C04019@nortelnetworks.com...
>
> I remember the generic types in Eiffel as being very convenient.  Perhaps
you could do something equivalent?
>
> An example would be a stack.  A simplistic example would be something like
>
> class Stack : T
> {
>    int push(T item);
>    T pop();
>    T[] storage;
>    int arrayIndex;
> }
>
> Then you could use it as
>
> int main()
> {
>    Stack:int myStack;
>    myStack.push(5);
>    int a = myStack.pop
> }
>
>
> To get a bit fancier, you could have some constraints on what the generic
type is
>
> class BinaryTree : T->Sortable
> {
>   insert(T item);
>   ...
> }
>
>
> Then we would have a base virtual Sortable class that has virtual routines
that
> define what it is to be sortable.  Those routines would then be accessable
within
> the BinaryTree methods.
>
> Of course, this really only comes into its own if you can have multiple
inheritance
> so that you can inherit from Sortable as well as whatever your real parent
is.
>
> Chris
>
> --
> Chris Friesen                    | MailStop: 043/33/F10
> Nortel Networks                  | work: (613) 765-0557
> 3500 Carling Avenue              | fax:  (613) 765-2986
> Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com


August 17, 2001
Walter wrote:
> 
> That's a great idea. But I want to try to make it work without needing multiple inheritance!

Agreed. Have you looked at functional programming languages at all? There are some nice typing systems that do "template-y" things much better than templates. Consider the pseudocode:

min(a, b)
{
	if (a <= b) {
		return a;
	}
	return b;
}

If the actual parameters passed to min() are of types that can be compared using <=, why should the developer have to specify what the types are; the compiler can infer them.

In fact, there was a nice article mentioned on /. a few months ago about such things - of course I can't find it now.
August 17, 2001
Michael Lindner wrote:

> min(a, b)
> {
>         if (a <= b) {
>                 return a;
>         }
>         return b;
> }
> 
> If the actual parameters passed to min() are of types that can be compared using <=, why should the developer have to specify what the types are; the compiler can infer them.

This would definately be cool.  The compiler would have to check at runtime that all the operations used in a given function are supported by anything that calls that function.  This may be time-consuming.

Also, some thought must be given on how to make this work with pre-compiled code libraries.  You'd almost have to compile libraries to some intermediate form and then do the final specialization later.

Chris
August 17, 2001
As I indicated in a different thread, a good model used in the LX programming language is to have real generic types, which make declarations that use them generic in turn. In addition, you can also put validation on said generic types.

    generic type ordered
    {
        // Validation code for the generic type
        ordered A, B;
        bool C = A <= B;
    }
    ordered min(ordered A; ordered B) {
        if (A <= B) { return A; } else { return B; }
    }

The LX syntax for this is basically the same thing without the brackets and parentheses :-)


Christophe


Chris Friesen wrote:

> Michael Lindner wrote:
>
> > min(a, b)
> > {
> >         if (a <= b) {
> >                 return a;
> >         }
> >         return b;
> > }
> >
> > If the actual parameters passed to min() are of types that can be compared using <=, why should the developer have to specify what the types are; the compiler can infer them.
>
> This would definately be cool.  The compiler would have to check at runtime that all the operations used in a given function are supported by anything that calls that function.  This may be time-consuming.
>
> Also, some thought must be given on how to make this work with pre-compiled code libraries.  You'd almost have to compile libraries to some intermediate form and then do the final specialization later.
>
> Chris

August 17, 2001
Why do you need multiple inheritance? Why can't Sortable just be an interface?

Im Artikel <9lhh1h$50n$1@digitaldaemon.com> schrieb "Walter" <walter@digitalmars.com>:

> That's a great idea. But I want to try to make it work without needing multiple inheritance!
> 
> "Chris Friesen" <cfriesen@nortelnetworks.com> wrote in message news:3B7C1DB9.F5C04019@nortelnetworks.com...
>>
>> I remember the generic types in Eiffel as being very convenient. Perhaps
> you could do something equivalent?
>>
>> An example would be a stack.  A simplistic example would be something like
>>
>> class Stack : T
>> {
>>    int push(T item);
>>    T pop();
>>    T[] storage;
>>    int arrayIndex;
>> }
>>
>> Then you could use it as
>>
>> int main()
>> {
>>    Stack:int myStack;
>>    myStack.push(5);
>>    int a = myStack.pop
>> }
>>
>>
>> To get a bit fancier, you could have some constraints on what the generic
> type is
>>
>> class BinaryTree : T->Sortable
>> {
>>   insert(T item);
>>   ...
>> }
>>
>>
>> Then we would have a base virtual Sortable class that has virtual routines
> that
>> define what it is to be sortable.  Those routines would then be accessable
> within
>> the BinaryTree methods.
>>
>> Of course, this really only comes into its own if you can have multiple
> inheritance
>> so that you can inherit from Sortable as well as whatever your real parent
> is.
>>
>> Chris
>>
>> --
>> Chris Friesen                    | MailStop: 043/33/F10 Nortel Networks
>>                  | work: (613) 765-0557 3500 Carling Avenue
>>  | fax:  (613) 765-2986 Nepean, ON K2H 8E9 Canada        | email:
>> cfriesen@nortelnetworks.com
> 
> 


-- 
Sheldon Simms / sheldon@semanticedge.com
August 17, 2001
Sheldon Simms wrote:
> 
> Why do you need multiple inheritance? Why can't Sortable just be an interface?

I suppose it could.  I was taking my example from Eiffel where multiple inheritance is easy and useful, but there's no reason why we need to make it identical.

So the interface would describe the methods which must be present in a class but then you can add more, right?  (Its been a while since I've used interfaces.)

Chris


-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com
August 17, 2001
Chris Friesen wrote:

> I remember the generic types in Eiffel as being very convenient.  Perhaps you could do something equivalent?

Eiffel and Ada don't have implicit instantiation. That means that you can't implement the STL (or most generic libraries, like Blitz++) in Eiffel or Ada. According to the authors.


Christophe

August 17, 2001
Im Artikel <3B7D16D0.29DCA80B@nortelnetworks.com> schrieb "Chris Friesen" <cfriesen@nortelnetworks.com>:

> Sheldon Simms wrote:
>> 
>> Why do you need multiple inheritance? Why can't Sortable just be an interface?
> 
> I suppose it could.  I was taking my example from Eiffel where multiple inheritance is easy and useful, but there's no reason why we need to make it identical.
> 
> So the interface would describe the methods which must be present in a class but then you can add more, right?  (Its been a while since I've used interfaces.)

Yes. Personally I don't see why multiple inheritance should be disallowed (*), but I just wanted to point out that your example doesn't require it.

(*) I do understand why multiple inheritance can be problematic but I think that only allowing inheritance trees (arbitrary DAGs not allowed) solves most, if not all, of the problems. Java has interfaces instead of multiple inheritance and it also has a lot of redundant "utility classes" that implement interfaces to make up for it.

-- 
Sheldon Simms / sheldon@semanticedge.com
August 17, 2001
Sheldon Simms wrote:
> Why do you need multiple inheritance? Why can't Sortable just
> be an interface?
> 
> ...
> 

If you're going to define interfaces, may I suggest that they be ex post facto.

I.e., an interface is a description of a set of calls and objects. Anything that possesses those calls and variables automatically implements the interface, whether it knows it or not.

This would allow one to look at a bunch of existing code, abstract a commonality, and then just define a matching interface, which could then be called on all objects that match that code.  I don't know how hard this would be, but it seems to me that it could be quite useful.

« First   ‹ Prev
1 2