Hi, and thanks for your quick reply. Eventually interfaces/concepts would be
the way to go. But for now I've managed to push the generics to the child class
as you suggested.
For now I have defined functions meant to be overridden by user as functions
with empty body. However I'd like to issue some diagnostics if these empty
functions are called, either at compile- or runtime. Something along the lines
of die("message") or exit("message"). I tried compilerError, but apparently it
generates an error regardless whether the method is overridden or not.
29.01.2015, 20:17, "Brad Chamberlain" <[email protected]>:
> Hi John --
>> I tried creating a base policy class and deriving from it, but ran into
>> problems with generics stuff. Namely, in my base class I have:
>>
>> param rank: int;
>> type idxType;
>>
>> When trying to derive a class myPolicy from it I get error:
>>
>> unresolved type specifier 'myPolicy(rank=1, idxType=type int(64))'
>>
>> Trying to provide any user specifiec constructors just gets me different
>> error messages...
> Yes, unfortunately there is currently a note in the STATUS file that says
> "subclassing uninstantiated generic classes should be prohibited but is
> not," indicating a previous developer's position on the topic. This same
> limitation came up in discussion via another user query this week and the
> team's sense was that it should be supported -- but it isn't at present in
> either case. In use cases like this, I believe we usually either push the
> generics down into the child classes (if possible) or move away from
> subclassing using a technique like the one in my earlier mail.
>
> The Chapel constructor/OOP story developed under HPCS was a bit naive in
> several respects (supporting the stereotype that HPC programmers really
> don't use objects?), and we're currently undertaking an effort to beef up
> these capabilities to fix the warts and mis-steps during those early years
> which also ought to result in closing issues like this.
>> The more I think this the more I'd like to take the base class approach,
>> so that default methods would be provided but they could be overridden
>> if user so wants... Or does chapel have a way to check(at compile time)
>> if a class has a method with given name?
> I don't believe we have that type of introspection in the class hierarchy.
> I don't think we'd be philosophically opposed to it, but simply haven't
> designed or implemented any support for it that I'm aware of.
>
> -Brad
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
