Any chance to call Tango as Extended Standard Library

[Lars Ivar Igesund]

Andrei Alexandrescu wrote:

> Lars Ivar Igesund wrote:
>> Andrei Alexandrescu wrote:
>> 
>>> Lars Ivar Igesund wrote:
>>>> Andrei Alexandrescu wrote:
>>>> 
>>>>> For example, I'm not sure how code in std.algorithm could help
>>>>> containers or streams in Tango (as it should), or how to
>>>>> reconcile std.algorithm with std.core.array.
>>>> If the language (D2++) will have a new way of iteration and
>>>> ranges known and enforced by the compiler, then I expect Tango to
>>>> support those at some point, and std.algorithm would presumably
>>>> just work. However, if it is based on some interface, ad hoc
>>>> (these methods must be present) or properly via an interface
>>>> Range { }, I would expect Tango developers to be involved in the
>>>> process of defining those interfaces (if Tango is meant to
>>>> use/know about them). Since I have seen neither, it is somewhat
>>>> difficult to make a well informed comment on the subject.
>>> It's been there for a while now (since 25 Nov 2008).
>>> 
>>> http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement
>>> 
>>> Scroll down to "Foreach over Structs and Classes with Ranges". The
>>> changelog reflects that too:
>>> 
>>> http://www.digitalmars.com/d/2.0/changelog.html
>>> 
>>> Version 2.021 mentions "Added range support to foreach statement."
>> 
>> Ah, thanks :)
>> 
>> However, replacing the "single" opApply with 5 properties seems
>> somewhat excessive? At least it becomes even more obvious that a form
>> of (runtime queryable) struct interfaces will be necessary - the one
>> and only feature I really really want in D2.
> 
> opApply was very inefficient and defining an abstraction that allows
> efficient iteration was a key goal of range design and foreach overhaul.
> Using duck typing and implicit interfaces was a tried and true
> technique. On top of this framework it is easy to define and use
> explicit interfaces. Using classic interfaces would have hamstrung
> efficiency of iteration from day one.
> 
> I'd be curious to find out more about a runtime queryable struct
> interface. How would it work? What idioms would it enable?

The point is that with classes and interfaces, you can query the class (at runtime) for whether it contains a certain set of functionality. Now, I know that the virtuality of doing so isn't the most efficient in most cases, but that is besides the point - if there is an efficient way of doing this with structs, then that should work with classes too. 

When you have functionality (at runtime) that relies only on a container to have a specific set of functions/properties/methods, then it seems unfair to restrict that to classes. In practice I see this as something that operates via additional type info.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango