class Program
    {
        static void Main()
        {
            String a = Null.Value;
            Exception b = Null.Value;
            int? c = Null.Value;
        }
    }

Как реализован класс Null ?

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

QL>Как реализован класс Null ?

class Null
{
    public static Null Value = new Null();

    public static implicit operator String(Null n)
    {
        return null;
    }

    public static implicit operator Exception(Null n)
    {
        return null;
    }
    
    public static implicit operator int?(Null n)
    {
        return null;
    }
}

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

QL>Как реализован класс Null ?

class Program
  {
    static void Main()
    {
      String a = Null.Value;
      Exception b = Null.Value;
      int? c = Null.Value;

      String a2 = Null2.Value;
      Exception b2 = Null2.Value;
      int? c2 = Null2.Value;
    }
  }

  class Null
  {
    public static dynamic Value
    {
      get { return null; }
    }
  }

  class Null2
  {
    public static implicit operator string(Null2 value)
    {
      return null;
    }
    public static implicit operator Exception(Null2 value)
    {
      return null;
    }
    public static implicit operator int?(Null2 value)
    {
      return null;
    }

    public static Null2 Value
    {
      get { return null; }
    }
  }

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

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

QL>>Как реализован класс Null ?

N>

N>class Null
N>{
N>    public static Null Value = new Null();

N>    public static implicit operator String(Null n)
N>    {
N>        return null;
N>    }

N>    public static implicit operator Exception(Null n)
N>    {
N>        return null;
N>    }
    
N>    public static implicit operator int?(Null n)
N>    {
N>        return null;
N>    }
N>}
N>

Имелся в виду более универсальный вариант, по типу такого:
{Любой ссылочный тип} {идентификатор} = Null.Value; // Возвращает null

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

QL>Имелся в виду более универсальный вариант, по типу такого:
QL>{Любой ссылочный тип} {идентификатор} = Null.Value; // Возвращает null

Ну а конвертеры и переопределенные операторы не пойдут? Такое возможно в C# ?

А>Ну а конвертеры и переопределенные операторы не пойдут? Такое возможно в C# ?

В смысле написать операторы на все возможные типы?

Мне одному "static dynamic" режет глаз?

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

HL>Мне одному "static dynamic" режет глаз?

Ага, не очень логично смотрится =)

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

QL>Ага, не очень логично смотрится =)
Так вы не томите — угадал, нет?

S>

S>  class Null
S>  {
S>      public static dynamic Value
S>      {
S>          get { return null; }
S>      }
S>  }
S>

S>Так вы не томите — угадал, нет?

Да, всё верно )

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

S> class Null
S> {
S> public static dynamic Value
S> {
S> get { return null; }
S> }
S> }

S>[/c#]

т.е. это нормальное применение dynamic?
получается можно писать фабрику таким макаром:

abstract class Car;
class Trunk : Car;
class Trunk : Car;

class CarFactory
{
Car Create(dynamic client)
{
return CreateCar(client);
}

Trunk Create(NewClient client)
{ return new Trunk(); }

Moto Create(OldClient client)
{ return new Trunk(); }
}

Здравствуйте, Аноним, Вы писали:

А>т.е. это нормальное применение dynamic?
А>получается можно писать фабрику таким макаром:

Да, если вас не пугает Create("blablabla"). Впрочем, я бы решил дополнительными перегрузками или ручным кастингом.

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

S>Здравствуйте, Аноним, Вы писали:

А>>т.е. это нормальное применение dynamic?
А>>получается можно писать фабрику таким макаром:

S>Да, если вас не пугает Create("blablabla"). Впрочем, я бы решил дополнительными перегрузками или ручным кастингом.

например?
по вышеупомянотому примеру. надо мне по типу клиента создать для определенный тип ТС

Здравствуйте, Аноним, Вы писали:

S>>Да, если вас не пугает Create("blablabla"). Впрочем, я бы решил дополнительными перегрузками или ручным кастингом.

А>например?
А>по вышеупомянотому примеру. надо мне по типу клиента создать для определенный тип ТС

public Car Create(OldClient client)
{
  // ...
}
public Car Create(NewClient client)
{
  // ...
}
public Car Create(ClientBase client)
{
  OldClient old = client as OldClient;
  if (old != null)
  {
    return Create(old);
  }
  else
  {
    NewClient new = client as NewClient;
    // ...
  }
}

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

S>>>Да, если вас не пугает Create("blablabla"). Впрочем, я бы решил дополнительными перегрузками или ручным кастингом.
А>>например?
А>>по вышеупомянотому примеру. надо мне по типу клиента создать для определенный тип ТС

S>public Car Create(OldClient client)
S>{
S>  // ...
S>}
S>public Car Create(NewClient client)
S>{
S>  // ...
S>}
S>public Car Create(ClientBase client)
S>{
S>  OldClient old = client as OldClient;
S>  if (old != null)
S>  {
S>    return Create(old);
S>  }
S>  else
S>  {
S>    NewClient new = client as NewClient;
S>    // ...
S>  }
S>}

Ну зачем же самому заниматься диспетчеризацией? Выигрыша никакого не будет.

S>public Car CreateCar(OldClient client) { }
S>public Car CreateCar(NewClient client) { }

// Не компилил
private Car DynamicCreate(dynamic client) { return CreateCar(client);  }

S>public Car Create(ClientBase client)
S>{
    return DynamicCreate(client);
S>}

По функциональности ничем не отличается от варианта с "client as …", но кода много меньше, что особенно будет заметно при многих поддерживаемых Client-ах. Но со строкой вызвать уже не выйдет.

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

_FR>По функциональности ничем не отличается от варианта с "client as …",

Зависит от того, как в предложенном варианте обрабатывается ситуация, когда не найден ни один вариант.

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

_FR>Ну зачем же самому заниматься диспетчеризацией? Выигрыша никакого не будет.

_FR>

S>>public Car CreateCar(OldClient client) { }
S>>public Car CreateCar(NewClient client) { }

_FR>// Не компилил
_FR>private Car DynamicCreate(dynamic client) { return CreateCar(client);  }

S>>public Car Create(ClientBase client)
S>>{
_FR>    return DynamicCreate(client);
S>>}
_FR>

А в чем смысл дополнительного DynamicCreate? Проще сразу return CreateCar((dynamic)client)

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

_FR>>Ну зачем же самому заниматься диспетчеризацией? Выигрыша никакого не будет.

S>>>public Car CreateCar(OldClient client) { }
S>>>public Car CreateCar(NewClient client) { }

_FR>>// Не компилил
_FR>>private Car DynamicCreate(dynamic client) { return CreateCar(client);  }

S>>>public Car Create(ClientBase client)
S>>>{
_FR>>    return DynamicCreate(client);
S>>>}

L>А в чем смысл дополнительного DynamicCreate? Проще сразу return CreateCar((dynamic)client)

Скорее всего. Не компилил, не разбирал, какие ещё хитрости могут быть.

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


L>А в чем смысл дополнительного DynamicCreate? Проще сразу return CreateCar((dynamic)client)

можно кратко для тех, кто пока не добрался до чтения про dynamic.
т.е. основное применение dynamic это динамическая подстановка типа как я привел здесь

Автор:
Дата: 11.10.10

?
вопрос отсутсвия имплементации ложится на плечи программера?

Здравствуйте, Аноним, Вы писали:

А>т.е. основное применение dynamic это динамическая подстановка типа как я привел здесь

Автор:
Дата: 11.10.10

?

Не совсем, речь идёт о добавлении позднего связывания. Если совсем уплощённо — о переносе части работы для компилятора в рантайм. Например, разрешение перегрузок будет выполняться по тем же правилам, что и при компиляции.
Из возможных фич — облегчение работы со всяким COMом/динамически сгенерированным кодом/duck typing.

Другое дело, что применить dynamic во вред (снижение производительности/понятности программы, больше ошибок в рантайме) довольно легко. И, в принципе, добавление dynamic идёт слегка вразрез с попыткой принести в mainstream статическую валидацию кода aka CodeContracts.

А>вопрос отсутсвия имплементации ложится на плечи программера?
DLR прожуёт что сможет, что не сможет — выплюнет исключением

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

А>>т.е. основное применение dynamic это динамическая подстановка типа как я привел здесь

Автор:
Дата: 11.10.10

?

S>Не совсем, речь идёт о добавлении позднего связывания. Если совсем уплощённо — о переносе части работы для компилятора в рантайм. Например, разрешение перегрузок будет выполняться по тем же правилам, что и при компиляции.

При компиляции каким компилотором? Например, в сходных ситуациях бэйсик и шарп по-разному разрешают перегрузки. Неужели DLR знает "из-под какого языка он работает", что бы разрешать перегрузки в соответствии с правилами компилятора? А какого конкретно компилятора?

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

_FR>Неужели DLR знает "из-под какого языка он работает", что бы разрешать перегрузки в соответствии с правилами компилятора? А какого конкретно компилятора?

Да, смотрите рефлектором.
Пруф: http://blogs.msdn.com/b/cburrows/archive/2008/10/27/c-dynamic.aspx

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

S>Пруф: http://blogs.msdn.com/b/cburrows/archive/2008/10/27/c-dynamic.aspx

я чего-то не пойму, для чего все эти старания? бред полный... чтобы вы не писали, чтобы не создавали, уже давно достаточно того, что имеем... а это — игрушки, чтобы повышать значимость и стоимость ИТ... чтобы было чем баловаться, пока бизнес за это платит...
люди давно по_на_создавали инструменты конструирования автоматизированных бизнес-процессов и годами не лезут в код, лишь периодически дорабатывая архитектуру и под_настраивая интерфейсы и поведение под изменения, изредка дополняя интерфейсы плагинами с редкими и слишком частным поведением. больше времени уходит на многообразие отчетов, оценок на результаты деловой деятельности...
что людям не хватает? зачем весь это бред? еще время на изучение, на обучение, на оттачивание навыков, на адаптацию этих навыков для реальной жизни...
блин, все больше и больше дыр для хакинга.. скоро код вообще будет нечитабильным, и понимать его будет только тот, кто его написал, так как "верно замечено" — нет правил, нет контрактов, реализация на луне, динамические описания на марсе, что происходит, ни кто не знает...
я понимаю, что мое высказывание может быть оценено как шоковая реакция на очередное новшество после гряды новшеств, которые до конца то еще в жизнь не вошли, а тут новье, прет, как плеснь )))))

Здравствуйте, Аноним, Вы писали:

Уважаемый, это вам в философию надо, там давно не было холиваров на тему IT-луддизма. В профильном форуме вас не поймут.

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

S>Здравствуйте, Аноним, Вы писали:

S>Уважаемый, это вам в философию надо, там давно не было холиваров на тему IT-луддизма. В профильном форуме вас не поймут.

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

...уничтожение двух чулочных станков, производивших дешёвые чулки и подрывавших дела опытных вязальщиц...

Тут все с точностью до наоборот — вы, ОПЫТНЫЕ ЧУЛОЧНИЦЫ, и отрасль создает ВАМ (самой себе) работу, запудривает мозги и создает сложности ))))) Если мы начнем спорить, то в роли луддита окажетесь вы

Здравствуйте, Аноним, Вы писали:

А>Тут все с точностью до наоборот — вы, ОПЫТНЫЕ ЧУЛОЧНИЦЫ, и отрасль создает ВАМ (самой себе) работу, запудривает мозги и создает сложности ))))) Если мы начнем спорить, то в роли луддита окажетесь вы

это очередной маркетинговый ход, попытка отхапать кусок рынка — дать динамическим языкам возможности фрэймворка..

The purpose of the DLR is to enable a system of dynamic languages to run on the .NET Framework and give them .NET interoperability. The DLR introduces dynamic objects to C# and Visual Basic in Visual Studio 2010 to support dynamic behavior in these languages and enable their interoperation with dynamic languages.

а споры о преимуществах и недостатках строго-типизированных языков и глубоко динамических — стары как мир... с одними меньше затрат на тестирование и меньше багов в будущем при эксплуатации, с другими быстрее развивается код.. одни применимы для управления космическими кораблями и атомными реакторами, другие для фривольностей на вэбстраничках..

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

S>это очередной маркетинговый ход, попытка отхапать кусок рынка — дать динамическим языкам возможности фрэймворка..
Чорд, я жертва маркетинга!

S>а споры о преимуществах и недостатках строго-типизированных языков и глубоко динамических — стары как мир...

Ну да. Споры начинаются, когда любая из областей пытается на голубом глазу отхряпать кусок у другой.

P.S. Ушёл удалять F#.

Здравствуйте, Аноним, Вы писали:

А>Уважаемый, может быть вы путаете понятия.. я сторонник, так сказать, анти-лудизма...

А>

А>...уничтожение двух чулочных станков, производивших дешёвые чулки и подрывавших дела опытных вязальщиц...
А>

А>Тут все с точностью до наоборот — вы, ОПЫТНЫЕ ЧУЛОЧНИЦЫ, и отрасль создает ВАМ (самой себе) работу, запудривает мозги и создает сложности ))))) Если мы начнем спорить, то в роли луддита окажетесь вы

Если не затруднит, не могли бы вы назвать марку и производителя "чулочного станка"? Заинтересовали.

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

S>Здравствуйте, Аноним, Вы писали:

S>Уважаемый, это вам в философию надо, там давно не было холиваров на тему IT-луддизма. В профильном форуме вас не поймут.

На самом деле он не настолько уж и не прав. Мне в свое время пришлось где-то с полгода поработать axapta-программистом. Когда я вернулся на .Net, меня очень неприятно поразила медленная скорость разработки под .Net.

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


L>На самом деле он не настолько уж и не прав. Мне в свое время пришлось где-то с полгода поработать axapta-программистом. Когда я вернулся на .Net, меня очень неприятно поразила медленная скорость разработки под .Net. Ну да. В своей области даже 1с рулит.

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

L>>На самом деле он не настолько уж и не прав. Мне в свое время пришлось где-то с полгода поработать axapta-программистом. Когда я вернулся на .Net, меня очень неприятно поразила медленная скорость разработки под .Net.

S>Ну да. В своей области даже 1с рулит.

Эта "своя область" на самом деле гораздо шире, чем считают большинство .Net-программистов. Для меня до сих пор остается загадкой, почему поставщики подобных решений не выдавили .Net/java.

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

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

L>>>На самом деле он не настолько уж и не прав. Мне в свое время пришлось где-то с полгода поработать axapta-программистом. Когда я вернулся на .Net, меня очень неприятно поразила медленная скорость разработки под .Net.

S>>Ну да. В своей области даже 1с рулит.

L>Эта "своя область" на самом деле гораздо шире, чем считают большинство .Net-программистов. Для меня до сих пор остается загадкой, почему поставщики подобных решений не выдавили .Net/java.

Кстати, очень грамотное замечание.
Я раньше работал с 1с 7.7., параллельно с С, С++ и Delphi, так на 1с ну просто очень быстро и очень много можно было сделать при высокой стабильности решения, и с высокой интеграцией.
Тем более, в 1с если сразу в наглую модули писать как внешние текстовые файлы, то если не изменялась структура данных, а только поведение модуля, то приложение даже не надо было закрывать и перекомпилировать! Пользователи получая сообщение, что надо бы обновить такую то форму, просто закрывали форму и открывали снова.
Вот вам динамика )))))
Давно не работал в 1с 7, но вот почитал немного восьмерку, так вообще кошмар. Это решение может заткнуть все дыры.
И по стоимости для бизнеса — это лучше чем аутсорсинговая контора с ее собственной крутой системой на супер новых языках и фрэймворках. Да и по интеграции и стабильности и масштабируемости решений — лучше (правда это мое мнение ), и бизнесу выгоднее связаться с 1с...
Повторюсь — это такое вот мнение, навеянное постом и наблюдениями за компаниями с крупными информационными системами. Правда не все достаточно грамотно используют 1с.