HaxeFoundation / haxe

Haxe - The Cross-Platform Toolkit
https://haxe.org
6.13k stars 653 forks source link

Issue 1027 - template specialization (and Partial specialization) - haxe #1027

Closed issuesbot closed 11 years ago

issuesbot commented 11 years ago

[Google Issue #1027 : https://code.google.com/p/haxe/issues/detail?id=1027] by ploplopl...@gmail.com, at 07/07/2012, 19:50:36 template specialization

In many cases when working with templates, you'll write one generic version for all possible data types and leave it at that-- for example every vector may be implemented in exactly the same way. The idea of template specialization is to override the default template implementation to handle a particular type in a different way.

class HashMap<KeyType, ValueType>

{
    .... default implementation
    public function getValue( key:KeyType ) : ValueType {   ....   }
    }

// specialization used by the compliler in case of Bool keyValue parameter class HashMap<Bool, ValueType>

{
    ... here optimal partial specialization
    private _trueVal:ValueType;
    private _falseVal:ValueType;
    public function getValue( key:Bool ) : ValueType 
    { 
        return   key ? _trueVal : _falseVal;
        }
    }

sources : http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/topic/com.ibm.xlcpp8a.doc/language/ref/explicit_specialization.htm http://www.cprogramming.com/tutorial/template_specialization.html

issuesbot commented 11 years ago

[comment from ncanna...@gmail.com, published at 08/07/2012, 09:02:59] In Haxe what you would so is :

class BoolHashMap extends HashMap {
    override function getValue( key : Bool ) : ValueType { ... }
}
issuesbot commented 11 years ago

[comment from ploplopl...@gmail.com, published at 08/07/2012, 13:21:03] It isn't the same because the user need to know BoolHashMap to use it. If you have N specialization the user need to knows the N,each with a different name. Plus, after some investigation, you can implement an optimized specialisation of a given parameter without changing existing code to benefit of the new implementation. Specialization handle it in a transparent way. For template libraries, as-fast-as-you-can implementation, it's really powerfull.

Plus, with inherence you have to override something and suppose a cost in some plateform.

issuesbot commented 11 years ago

[comment from stephane...@gmail.com, published at 08/07/2012, 16:58:30] Hummm.. maybe you're going toward type directed instance resolution with most specific type selection. aka implicits.. :)

issuesbot commented 11 years ago

[comment from ploplopl...@gmail.com, published at 09/07/2012, 16:02:37] sadly, I would expect some debate before closing the proposal. Maybe I ommited the haxe.rtti.Generic tag that make more sens to the concept. (real template) As I want to use haxe also for critical performance things as a replacement of C/C++... (interractive installation) template specialization isn't a dupplicate and make sens. It give new power over genericity, polymorphism and mostly optimizations that actual syntax (your response) doesn't fit well. It's not only a proposal for you nicolas but also for the comunity :p

The idea is to swith at compile time over the most specific implementation. The only constraint we have is to garantie that the specialization implement all the expected method of the model.

we can for example use the @ :override tag to specify the specializations...?

issuesbot commented 11 years ago

[comment from simon.kr...@simn.de, published at 09/07/2012, 18:14:57] A problem I see with your suggestion is that we'd have to find a way of recognizing the Bool in your example as a bound type instead of a type parameter named Bool (it may seem really obvious here, but you can be sure it could become a problem in more complex scenarios). This has to be made explicit by syntax somehow.

I like the general idea though.

issuesbot commented 11 years ago

[comment from ploplopl...@gmail.com, published at 11/07/2012, 15:55:27] Yes I see what do you mean, it's a little problematic.

If we use the @ override keyword on the class or an other keyword/system to specify the model or the derived, with some logics, we can guaranty that specializations have the same type parameter names as the model. All unmatched parameter follow the default resolution mecanism. need import...

I think that the specializations should override only the needed ones. In the background specialization should be a copy/past of the model with syntaxic replacement (like with macro and $Var) of overriden parameter and methods. maybe we should discuss it on the forum to have community feedback ? About performance, I think some people may be interested.

issuesbot commented 11 years ago

[comment from ploplopl...@gmail.com, published at 05/08/2012, 03:03:08] Indeed, I agree with the fact that normal class shouldn't have several implementations. Specialization make sense only for haxe.rtti.Generic Classes. With @ :generic each parameterization has its proper implementation isn't it ? ( HashMap<Int, String> become HashMap_Int_String )

@ :generic class HashMap<KeyType, ValueType>

{
    .... default implementation
    public function getValue( key:KeyType ) : ValueType {   ....   }
}

// specialization used by the compliler in case of Bool keyValue parameter // like classA implements classB this implementation have to expose the same interface than the basis. // it's simpler if nothing is shared. @ :implicit class HashMap<Bool, ValueType>

{
    ... here optimal partial specialization
    private _trueVal:ValueType;
    private _falseVal:ValueType;
    override public function getValue( key:Bool ) : ValueType 
    { 
        return   key ? _trueVal : _falseVal;
    }
}