C# - идея расширения для where - новое ограничение для типа
От: konstardiy  
Дата: 28.12.09 15:19
Оценка:
Вот простой пример:
        public class TemplateT<A> where A has { A Operation(); }
        {
            A DoubleOperation(A arg)
            {
                return arg.Operation().Operation();
            }
        }

Предлагаю осудить, кому интересно.
Что такое расширение даст, что потребует, и так далее.
c# where generic clases
Re: C# - идея расширения для where - новое ограничение для т
От: Andir Россия
Дата: 28.12.09 15:29
Оценка: +3
Здравствуйте, konstardiy, Вы писали:

K>Предлагаю осудить, кому интересно.

K>Что такое расширение даст, что потребует, и так далее.

Чем не подходит стандартное требование реализации интерфейса? Зачем дробить ещё на более мелкие функциональные единицы?

С Уважением, Andir!
Re[2]: C# - идея расширения для where - новое ограничение дл
От: konstardiy  
Дата: 28.12.09 15:41
Оценка: +1
Здравствуйте, Andir, Вы писали:

A>Чем не подходит стандартное требование реализации интерфейса? Зачем дробить ещё на более мелкие функциональные единицы?


A>С Уважением, Andir!

Существуют случаи, когда применить алгоритм к набору объектов класса, к которому у вас нет исходников, чтобы добавить реализацию нужного вам интерфейса. А формально сигнатуры методов есть и они видны в области видимости вашего алгоритма. Что вы в таких случаях бы делали?
Я подозреваю, что писали бы wrapper-ы либо для объектов либо для шагов алгоритма, что усложнило бы итоговый код.
Re: C# - идея расширения для where - новое ограничение для т
От: nikov США http://www.linkedin.com/in/nikov
Дата: 28.12.09 15:47
Оценка:
Здравствуйте, konstardiy, Вы писали:

K>Предлагаю осудить, кому интересно.

K>Что такое расширение даст, что потребует, и так далее.

Предлагаю взглянуть на F# 1.9.7 Specification, 5.1.5.3 Member Constraints
Re[3]: C# - идея расширения для where - новое ограничение дл
От: Lloyd Россия  
Дата: 28.12.09 15:50
Оценка:
Здравствуйте, konstardiy, Вы писали:

K>Существуют случаи, когда применить алгоритм к набору объектов класса, к которому у вас нет исходников, чтобы добавить реализацию нужного вам интерфейса. А формально сигнатуры методов есть и они видны в области видимости вашего алгоритма. Что вы в таких случаях бы делали?

K>Я подозреваю, что писали бы wrapper-ы либо для объектов либо для шагов алгоритма, что усложнило бы итоговый код.

wrapper-ы не едиственное решение. можно стратегию вызова метода Operation передавать. выйдет даже гибче.
Re[2]: C# - идея расширения для where - новое ограничение дл
От: Пельмешко Россия blog
Дата: 28.12.09 16:00
Оценка: 42 (1) +1
Здравствуйте, nikov, Вы писали:

N>Здравствуйте, konstardiy, Вы писали:


K>>Предлагаю осудить, кому интересно.


Изобрели Type Classes практически

K>>Что такое расширение даст, что потребует, и так далее.


Если уж делать для всех языков, то потребуется серьёзное изменение рантайма...

N>Предлагаю взглянуть на F# 1.9.7 Specification, 5.1.5.3 Member Constraints


Мало там информации, лучше Matthew Podwysocki почитать...

Синтаксис — полный трэш на самом деле
let inline doubleOperation arg = 
    let oper a = (^a : (member Operation : unit -> ^a) a)
    oper (oper arg)

usage:
type Foo(x:int) =
     member self.Value = x
     member self.Operation() = Foo(x + 1)

doubleOperation(Foo(3)).Value
(* val it : int = 5 *)

И всё это работает только в мирке F#, вдобавок самое обидное для меня:

The member-sig may not be generic, i.e. may not include explicit type parameter definitions.

Нельзя написать обобщённый код над классами-builder'ами computation expressions
Re[4]: C# - идея расширения для where - новое ограничение дл
От: konstardiy  
Дата: 28.12.09 16:05
Оценка: +1
Здравствуйте, Lloyd, Вы писали:

L>wrapper-ы не едиственное решение. можно стратегию вызова метода Operation передавать. выйдет даже гибче.


Интересно.. Передавать в сумматор стратегию сложения.. Это даже немного забавно...
Если бы в c# был базовый класс Number или возможность объявить в интерфейсе перегрузку оператора и соответственно интерфейс INumber, половина потребности в has испарилась бы в стратосферу.
Re: C# - идея расширения для where - новое ограничение для т
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.09 16:24
Оценка: +1
Здравствуйте, konstardiy, Вы писали:

K>Вот простой пример:

K>
K>        public class TemplateT<A> where A has { A Operation(); }
K>        {
K>            A DoubleOperation(A arg)
K>            {
K>                return arg.Operation().Operation();
K>            }
K>        }
K>

K>Предлагаю осудить, кому интересно.
K>Что такое расширение даст, что потребует, и так далее.

Что там обсуждать? Это называется "концепты". Планировалось добавить к C++0x, но было выбрашено в виду того, что комитету не хватало времени на пьянки.

Проблема в том, что этот подход подразумевает утиную типизацию которая не поддерживается напрямую в дотнете (в рантайме). Некоторая эмуляция есть в F#.

Собственно что уж тогда останавливаться? Тогда уж можно было бы описывать операторы и статические функции. Вот только это еще хуже вяжется с подходами используемыми в рантайме дотнета.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: C# - идея расширения для where - новое ограничение дл
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.09 16:28
Оценка:
Здравствуйте, Andir, Вы писали:

A>Чем не подходит стандартное требование реализации интерфейса?


Тем что оно прибивает гвоздями к необходимости реализации этих интерфейсов в классах. А что делать если класс не твой, он sealed или struct?

A>Зачем дробить ещё на более мелкие функциональные единицы?


Чтобы иметь большую гибкость.

Собственно описывать отдельные "операции" (точнее функции) не обязательно. Можно было бы ввести поддержку утиной типизации для интерфейсов (как в гуглевском Гоу). Но это нужно реализовывать не в шарпе, а в дотнете, а уже потом во всех языках донета.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: C# - идея расширения для where - новое ограничение дл
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.09 16:30
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>wrapper-ы не едиственное решение. можно стратегию вызова метода Operation передавать. выйдет даже гибче.


Это и есть обертки. Гикость там где она не нужна — это кривость.

К тому же за эту гибкость ты вынужден платить снижением произвоидтельности. Скажем вместо операторов (+, -, *, /) ты будешь создавать какие-то классы и перпедавать на них ссылки, что превратит любой числодробильный алгоритм в ленивца.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: C# - идея расширения для where - новое ограничение дл
От: Lloyd Россия  
Дата: 28.12.09 16:34
Оценка: +1
Здравствуйте, konstardiy, Вы писали:

L>>wrapper-ы не едиственное решение. можно стратегию вызова метода Operation передавать. выйдет даже гибче.


K>Интересно.. Передавать в сумматор стратегию сложения.. Это даже немного забавно...


Сумматор — это частный случай fold-а, который уже есть в .Net-е (Enumerable.Aggregate)
Re[5]: C# - идея расширения для where - новое ограничение дл
От: Пельмешко Россия blog
Дата: 28.12.09 16:35
Оценка:
Здравствуйте, konstardiy, Вы писали:

K>Здравствуйте, Lloyd, Вы писали:


L>>wrapper-ы не едиственное решение. можно стратегию вызова метода Operation передавать. выйдет даже гибче.


K>Интересно.. Передавать в сумматор стратегию сложения.. Это даже немного забавно...

K>Если бы в c# был базовый класс Number или возможность объявить в интерфейсе перегрузку оператора и соответственно интерфейс INumber, половина потребности в has испарилась бы в стратосферу.

Кстати, если был бы интерфейс IArithmetical и примитивные типы реализовывали бы его методы, то можно было бы писать обобщённые алгоритмы даже устранив вызовы через интерфейс:

public T Square(T value) where T : IArithmetical
{
  return value * value;
}

Если в качестве T будет valuetype, то вызовы будут заинлайнены. Однако для комфортной работы
Re[5]: C# - идея расширения для where - новое ограничение дл
От: samius Япония http://sams-tricks.blogspot.com
Дата: 28.12.09 16:37
Оценка:
Здравствуйте, konstardiy, Вы писали:

K>Здравствуйте, Lloyd, Вы писали:


L>>wrapper-ы не едиственное решение. можно стратегию вызова метода Operation передавать. выйдет даже гибче.


K>Интересно.. Передавать в сумматор стратегию сложения.. Это даже немного забавно...


Это даже так же быстро как и просто складывать, за счет инлайнинга. Но все-же пользоваться этим неудобно.

K>Если бы в c# был базовый класс Number или возможность объявить в интерфейсе перегрузку оператора и соответственно интерфейс INumber, половина потребности в has испарилась бы в стратосферу.


Все немного сложнее. Объявления операций сложения/умножения и т.п. в INumber сами по себе мало чем полезны. Даже для того, чтобы посчитать среднее арифметическое от T[] нужно уметь складывать T с типом накопителя (например double) и потом делить тип накопителя на целое (double умеем, но TAgregate в общем случае — нет). Можно складывать T- друг с другом, но в случае byte[] быстро получим переполнение.
Потому приходится все приведения, которые умеет делать компилятор (явно или неявно), уметь описывать с помощью констрейнтов, и передавать соответствующие стратегии, в которых должы быть не только способы сложения и умножения T с T, но и приведения типа T ко всему остальному.

В итоге для выполнения обобщенного вычисления среднего арифметического в double вектора int[], придется написать довольно много кода. В разы больше, чем у необобщенного варианта.

Что говорить, если мы захотим реализовать обобщенные фильтры для Bitmap<T>?!?!
Re[5]: C# - идея расширения для where - новое ограничение дл
От: Lloyd Россия  
Дата: 28.12.09 16:37
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>wrapper-ы не едиственное решение. можно стратегию вызова метода Operation передавать. выйдет даже гибче.


VD>Это и есть обертки. Гикость там где она не нужна — это кривость.


Для меня "обертка" — это адаптер. Отличия от стратегии все-таки имеются.

VD>К тому же за эту гибкость ты вынужден платить снижением произвоидтельности. Скажем вместо операторов (+, -, *, /) ты будешь создавать какие-то классы и перпедавать на них ссылки, что превратит любой числодробильный алгоритм в ленивца.


Есть такое.
Re[3]: C# - идея расширения для where - новое ограничение дл
От: konstardiy  
Дата: 28.12.09 17:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Andir, Вы писали:


A>>Чем не подходит стандартное требование реализации интерфейса?


VD>Тем что оно прибивает гвоздями к необходимости реализации этих интерфейсов в классах. А что делать если класс не твой, он sealed или struct?


A>>Зачем дробить ещё на более мелкие функциональные единицы?


VD>Чтобы иметь большую гибкость.


VD>Собственно описывать отдельные "операции" (точнее функции) не обязательно. Можно было бы ввести поддержку утиной типизации для интерфейсов (как в гуглевском Гоу). Но это нужно реализовывать не в шарпе, а в дотнете, а уже потом во всех языках донета.


На этот счет у меня была идея для другого расширения, другго констрэйнта:
public interface IExecutable
{
   void Execute();
}
public T Code<T>(T arg) where T simular IExecutable
{
    atg.Execute();
}

где T реализует IExecutable либо объявляет как минимум то же самое public что и в IExecutable.
Типа
public T Code<T>(T arg) where T simular <IntefaceType>
Re[6]: C# - идея расширения для where - новое ограничение дл
От: konstardiy  
Дата: 28.12.09 17:56
Оценка:
Здравствуйте, Пельмешко, Вы писали:

П>Кстати, если был бы интерфейс IArithmetical и примитивные типы реализовывали бы его методы, то можно было бы писать обобщённые алгоритмы даже устранив вызовы через интерфейс:


П>
П>public T Square(T value) where T : IArithmetical
П>{
П>  return value * value;
П>}
П>

П>Если в качестве T будет valuetype, то вызовы будут заинлайнены. Однако для комфортной работы

Но... в интерфейсе нельзя объявить операторы. А жаль.
Re[4]: C# - идея расширения для where - новое ограничение дл
От: Пельмешко Россия blog
Дата: 28.12.09 17:56
Оценка:
Здравствуйте, konstardiy, Вы писали:

K>На этот счет у меня была идея для другого расширения, другго констрэйнта:


А в чём разница от первого поста кроме взятия перечисления методов из интерфейса?
Re[6]: C# - идея расширения для where - новое ограничение дл
От: konstardiy  
Дата: 28.12.09 18:10
Оценка:
Здравствуйте, samius, Вы писали:


S>Все немного сложнее. Объявления операций сложения/умножения и т.п. в INumber сами по себе мало чем полезны. Даже для того, чтобы посчитать среднее арифметическое от T[] нужно уметь складывать T с типом накопителя (например double) и потом делить тип накопителя на целое (double умеем, но TAgregate в общем случае — нет). Можно складывать T- друг с другом, но в случае byte[] быстро получим переполнение.

S>Потому приходится все приведения, которые умеет делать компилятор (явно или неявно), уметь описывать с помощью констрейнтов, и передавать соответствующие стратегии, в которых должы быть не только способы сложения и умножения T с T, но и приведения типа T ко всему остальному.

S>В итоге для выполнения обобщенного вычисления среднего арифметического в double вектора int[], придется написать довольно много кода. В разы больше, чем у необобщенного варианта.


S>Что говорить, если мы захотим реализовать обобщенные фильтры для Bitmap<T>?!?!


Смотря что он фильтрует — отдельные экщемпляры T или Bitnap<T> в целом. Вот во втором случае
public abstract FilterBase<T, ValueT> where T has { ValueT R { get; set; } ValueT G { get; set; } ValueT B { get; set; } ValueT A { get; set; }  
//simular IPixelData<ValueT>
{
public Bitmap<T> Context { get; private set; }
public abstract double ApplianceStrength(T pixel, int x, int y);
public abstract T Apply(T pixrl, int X, int Y); 
public virtual void Apply()
{
   foreach(PixelCoordInfo<T> p in Context.EnumerateAllPixels())
   {
        Context[p.x, p.y] = Aply(p.Pixel, p.X, p.Y); 
   }
}
}

Пробемы начинаются если мы не знаем точно, что это за ValueT. Их конечно можно решить по другоому, но у has или simular (см в другой ветке) наверно есть какето преимущества?
Re[5]: C# - идея расширения для where - новое ограничение дл
От: konstardiy  
Дата: 28.12.09 18:16
Оценка:
Здравствуйте, Пельмешко, Вы писали:

П>А в чём разница от первого поста кроме взятия перечисления методов из интерфейса?

В снижении количества копипасты в тех случаях, когда тебе нужны все методы интерфейса.
Has нужен если опрация мало или если не хочешь ссылаться на сборку с интерфейсом. Чтобы указать simular — ограничение, нужно ведь сослаться на сборку где объявлен интерфейс...
Re[7]: C# - идея расширения для where - новое ограничение дл
От: samius Япония http://sams-tricks.blogspot.com
Дата: 28.12.09 18:34
Оценка:
Здравствуйте, konstardiy, Вы писали:

K>Здравствуйте, samius, Вы писали:



S>>Все немного сложнее. Объявления операций сложения/умножения и т.п. в INumber сами по себе мало чем полезны. Даже для того, чтобы посчитать среднее арифметическое от T[] нужно уметь складывать T с типом накопителя (например double) и потом делить тип накопителя на целое (double умеем, но TAgregate в общем случае — нет). Можно складывать T- друг с другом, но в случае byte[] быстро получим переполнение.

S>>Потому приходится все приведения, которые умеет делать компилятор (явно или неявно), уметь описывать с помощью констрейнтов, и передавать соответствующие стратегии, в которых должы быть не только способы сложения и умножения T с T, но и приведения типа T ко всему остальному.

S>>В итоге для выполнения обобщенного вычисления среднего арифметического в double вектора int[], придется написать довольно много кода. В разы больше, чем у необобщенного варианта.


S>>Что говорить, если мы захотим реализовать обобщенные фильтры для Bitmap<T>?!?!


K>Смотря что он фильтрует — отдельные экщемпляры T или Bitnap<T> в целом. Вот во втором случае

Я имел в виду convolution filter-ы
K>
K>public abstract FilterBase<T, ValueT> where T has { ValueT R { get; set; } ValueT G { get; set; } ValueT B { get; set; } ValueT A { get; set; }  
K>

не очень удачный подход, т.к. не все растры 4-х компонентны. Есть монохромные, indexed, colored и т.п.

K>Пробемы начинаются если мы не знаем точно, что это за ValueT.

даже если мы знаем что T это точно byte или точно float, то проблем не избежать. Поинт не в том, чтобы определить абстрактный Apply и реализовывать его для каждого класса T, а в том, чтобы реализовать Apply для некого алгоритма обобщенно лишь однажды и применить его к частным типам.

K>Их конечно можно решить по другоому, но у has или simular (см в другой ветке) наверно есть какето преимущества?

Никаких преимуществ нет. Чтобы убедиться, стоит прикинуть gaussian blur над Bitmap<byte> и Bitmap<System.Drawing.Color>.
Re[5]: C# - идея расширения для where - новое ограничение дл
От: Klapaucius  
Дата: 28.12.09 19:34
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>К тому же за эту гибкость ты вынужден платить снижением произвоидтельности. Скажем вместо операторов (+, -, *, /) ты будешь создавать какие-то классы и перпедавать на них ссылки, что превратит любой числодробильный алгоритм в ленивца.


Ну, если стратегию передавать через дженерик-параметр, то снижения производительности не будет. Т.е. обобщенное числодробление
Автор: Klapaucius
Дата: 23.03.07
все-таки писать можно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1325>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re: C# - идея расширения для where - новое ограничение для т
От: Klapaucius  
Дата: 28.12.09 19:34
Оценка:
Здравствуйте, konstardiy, Вы писали:

K>Вот простой пример:

K>
K>        public class TemplateT<A> where A has { A Operation(); }
K>        {
K>            A DoubleOperation(A arg)
K>            {
K>                return arg.Operation().Operation();
K>            }
K>        }
K>

K>Предлагаю осудить, кому интересно.
K>Что такое расширение даст, что потребует, и так далее.

Я считаю, что лучше дать возможность сопоставлять констрейнт любому типу неинтрузивно.

Т.е. как-то так:

public interface COperationable<A> { A Operation(A arg); }

//Foo - класс или структура, которую мы не можем изменить.
public type Foo implements COperationable
{
    A Operation(A arg)
    {
     //реализация
    }
}

public class TemplateT<A> where A : class COperationable
{
  A DoubleOperation(A arg)
  {
    return arg.Operation().Operation();
  }
}

...

var tt = new TemplateT<Foo>();

Т.е. добавить урезанные классы типов, ну или абстрактные интерфейсы из Nice.
Все это разворачивается в:
public interface COperationable<A> { A Operation(A arg); }

[Implementation("Foo", "COperationable")]
public struct Foo_COperationable : COperation<Foo>
{
    A Operation(A arg)
    {
     //реализация
    }
}

[Implicit("CT")]
[ClassType("A", "COperationable")]
public class TemplateT<A, CT> where CT : COperationable<A>, new()
{
    static CT ct = new CT();
  A DoubleOperation(A arg)
  {
    return ct.Operation(ct.Operation(ct));
  }
}

...
//компилятор подставляет второй неявный параметр,
//подбирая соответствующую реализацию для типа Foo из области видимости.
var tt = new TemplateT<Foo, Foo_COperationable>();
... << RSDN@Home 1.2.0 alpha 4 rev. 1325>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[4]: C# - идея расширения для where - новое ограничение дл
От: barn_czn  
Дата: 29.12.09 03:49
Оценка:
K>На этот счет у меня была идея для другого расширения, другго констрэйнта:
K>
K>public interface IExecutable
K>{
K>   void Execute();
K>}
K>public T Code<T>(T arg) where T simular IExecutable
K>{
K>    atg.Execute();
K>}
K>

K>где T реализует IExecutable либо объявляет как минимум то же самое public что и в IExecutable.
K>Типа
K>
K>public T Code<T>(T arg) where T simular <IntefaceType>
K>



Это хорошая идея, и приходила в голову она не только вам ).
Но думаю воплотить ее не просто.

А вот еще идея. А что если вообще не завязыватся на имена методов? Ну скажем требование к типу-параметру
"тип должен иметь метод A : void A(double x)" заменяем на
"тип должен иметь метод с сигнатурой void [MethodName](double x)". Но тогда генерик не поймет какой из 2х методов одинаковой сигнатуры юзать.
Тут должен появится мапинг методов.

К чему бы это привело на практике — незнаю. Как обычно наверно, в кривых руках эта фича создала бы монстроподобный код.
Re[6]: C# - идея расширения для where - новое ограничение дл
От: IT Россия linq2db.com
Дата: 29.12.09 05:39
Оценка:
Здравствуйте, samius, Вы писали:

S>Все немного сложнее. Объявления операций сложения/умножения и т.п. в INumber сами по себе мало чем полезны. Даже для того, чтобы посчитать среднее арифметическое от T[] нужно уметь складывать T с типом накопителя (например double) и потом делить тип накопителя на целое (double умеем, но TAgregate в общем случае — нет). Можно складывать T- друг с другом, но в случае byte[] быстро получим переполнение.


Всё это уже давно есть в BLToolkit:

static void Main()
{
    Console.WriteLine(Calc(5, 2, 3.0));
}

public static T2 Calc<T1,T2>(T1 x, T1 y, T2 z)
{
    return Operator.Division(
        ConvertTo<T2>.From(Operator.Addition(x, y)),
        z);
}

Выглядит, конечно, мрачноватенько, но пользоваться вполне можно.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: C# - идея расширения для where - новое ограничение дл
От: samius Япония http://sams-tricks.blogspot.com
Дата: 29.12.09 05:43
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, samius, Вы писали:


S>>Все немного сложнее. Объявления операций сложения/умножения и т.п. в INumber сами по себе мало чем полезны. Даже для того, чтобы посчитать среднее арифметическое от T[] нужно уметь складывать T с типом накопителя (например double) и потом делить тип накопителя на целое (double умеем, но TAgregate в общем случае — нет). Можно складывать T- друг с другом, но в случае byte[] быстро получим переполнение.


IT>Всё это уже давно есть в BLToolkit:


IT>Выглядит, конечно, мрачноватенько, но пользоваться вполне можно.


Здорово.
Инлайнится?
Re[8]: C# - идея расширения для where - новое ограничение дл
От: IT Россия linq2db.com
Дата: 29.12.09 05:45
Оценка:
Здравствуйте, samius, Вы писали:

S>Инлайнится?


Без понятия
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: C# - идея расширения для where - новое ограничение дл
От: samius Япония http://sams-tricks.blogspot.com
Дата: 29.12.09 05:59
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, samius, Вы писали:


S>>Инлайнится?


IT>Без понятия


Вижу, что не инлайнится. Делегаты, интерфейсы...
Все здорово, но для масштабных обобщенных вычислений не пойдет
Re[8]: C# - идея расширения для where - новое ограничение дл
От: Пельмешко Россия blog
Дата: 29.12.09 05:59
Оценка: 13 (2) +1
Здравствуйте, samius, Вы писали:

S>Здравствуйте, IT, Вы писали:


IT>>Выглядит, конечно, мрачноватенько, но пользоваться вполне можно.


S>Здорово.

S>Инлайнится?

В отличие от методов generic-типов, generic-методы совсем не инлайнятся, как показывает практика
Re[10]: C# - идея расширения для where - новое ограничение д
От: IT Россия linq2db.com
Дата: 29.12.09 06:03
Оценка:
Здравствуйте, samius, Вы писали:

S>Вижу, что не инлайнится. Делегаты, интерфейсы...


Скорее всего не будет инлайниться. Без боксинга обошлись и то уже хорошо.

S>Все здорово, но для масштабных обобщенных вычислений не пойдет


Я и не настаиваю Впрочем, для масштабных и обобщённых вообще ничего не подойдёт.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: C# - идея расширения для where - новое ограничение д
От: samius Япония http://sams-tricks.blogspot.com
Дата: 29.12.09 06:09
Оценка:
Здравствуйте, IT, Вы писали:

IT>Я и не настаиваю Впрочем, для масштабных и обобщённых вообще ничего не подойдёт.


Я как-то делал прототип Bitmap<T> и какую-то операцию над ним (уже не помню) через передачу generic арифметики над типом T. Выжал 98% производительности от необобщенной версии. Получилось громмоздко, потому в команде предпочли множественный copy&paste (число типов T было ограничено, не больше 10и).
Re[5]: C# - идея расширения для where - новое ограничение дл
От: konstardiy  
Дата: 29.12.09 15:14
Оценка:
Здравствуйте, barn_czn, Вы писали:
K>>
K>>public T Code<T>(T arg) where T simular <IntefaceType>
K>>



_>Это хорошая идея, и приходила в голову она не только вам ).

_>Но думаю воплотить ее не просто.
Есть такая проблема, мда...
Сложность воплощения не в реализации самой проверки а "уговорить добавить сответствующий элемент языка. Особенно если этот элемент применим только для Public — членов, то есть проверяются только они.

_>А вот еще идея. А что если вообще не завязыватся на имена методов? Ну скажем требование к типу-параметру

_>"тип должен иметь метод A : void A(double x)" заменяем на
_>"тип должен иметь метод с сигнатурой void [MethodName](double x)". Но тогда генерик не поймет какой из 2х методов одинаковой сигнатуры юзать.
_>Тут должен появится мапинг методов.

Мапинг методов... это перебор, потому что мапинг дожен быть на чтото — на имена,на Guid-ы операций....
Абсодютно обобщенный объект имеет интерфейс
public object this[object key] { get; set; }

У меня коллега на таком интерфейсе делал объекты, и можно было даже методы вызывать через этот интерфейс.
Re[2]: C# - идея расширения для where - новое ограничение дл
От: konstardiy  
Дата: 29.12.09 15:21
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, konstardiy, Вы писали:


K>>Вот простой пример:

K>>
K>>        public class TemplateT<A> where A has { A Operation(); }
K>>        {
K>>            A DoubleOperation(A arg)
K>>            {
K>>                return arg.Operation().Operation();
K>>            }
K>>        }
K>>

K>>Предлагаю осудить, кому интересно.
K>>Что такое расширение даст, что потребует, и так далее.

K>Я считаю, что лучше дать возможность сопоставлять констрейнт любому типу неинтрузивно.


K>Т.е. как-то так:


K>
K>public interface COperationable<A> { A Operation(A arg); }

K>//Foo - класс или структура, которую мы не можем изменить.
K>public type Foo implements COperationable
K>{
K>    A Operation(A arg)
K>    {
K>     //реализация
K>    }
K>}

K>public class TemplateT<A> where A : class COperationable
K>{
K>  A DoubleOperation(A arg)
K>  {
K>    return arg.Operation().Operation();
K>  }
K>}

K>...

K>var tt = new TemplateT<Foo>();
K>

K>Т.е. добавить урезанные классы типов, ну или абстрактные интерфейсы из Nice.
K>Все это разворачивается в:
K>
K>public interface COperationable<A> { A Operation(A arg); }

K>[Implementation("Foo", "COperationable")]
K>public struct Foo_COperationable : COperation<Foo>
K>{
K>    A Operation(A arg)
K>    {
K>     //реализация
K>    }
K>}

K>[Implicit("CT")]
K>[ClassType("A", "COperationable")]
K>public class TemplateT<A, CT> where CT : COperationable<A>, new()
K>{
K>    static CT ct = new CT();
K>  A DoubleOperation(A arg)
K>  {
K>    return ct.Operation(ct.Operation(ct));
K>  }
K>}

K>...
K>//компилятор подставляет второй неявный параметр,
K>//подбирая соответствующую реализацию для типа Foo из области видимости.
K>var tt = new TemplateT<Foo, Foo_COperationable>();
K>

Маленькое уточнение... было бы неплохо ввести обозначение "здесь будет подобран тип позднее".
public class A<B> where B simular String
{
}

public class A2<Arg> where Arg : A<*>
{
}

Екак-то так но этовсётаки перебор. Вероятность неоднознаности over 9000....
Re[5]: C# - идея расширения для where - новое ограничение дл
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.12.09 18:35
Оценка:
Здравствуйте, barn_czn, Вы писали:

_>А вот еще идея. А что если вообще не завязыватся на имена методов? Ну скажем требование к типу-параметру

_>"тип должен иметь метод A : void A(double x)" заменяем на
_>"тип должен иметь метод с сигнатурой void [MethodName](double x)". Но тогда генерик не поймет какой из 2х методов одинаковой сигнатуры юзать.
_>Тут должен появится мапинг методов.

_>К чему бы это привело на практике — незнаю. Как обычно наверно, в кривых руках эта фича создала бы монстроподобный код.

Как к чему? К yet another turing-complete macro language.
С этой точки зрения, эффективнее называть вещи своими именами, и указывать маппинг традиционным способом:
public DuckWrapper: IDuck
{
  public DuckWrapper(WildDuck duck) {_duck = duck;}
  public IDuck.Quack { _duck.Kryak(); }
}

Можно пойти обратным путём: собирать выражения в виде Expression и компилировать весь цикл математики, выполняя, таким образом, инлайнинг вручную.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: C# - идея расширения для where - новое ограничение дл
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 29.12.09 19:09
Оценка:
Здравствуйте, konstardiy, Вы писали:

Не ленись удалять ненужное цитирование.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
AVK Blog
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.