Если я использую ScriptSharp
механизм, тактовый сигнал и скорость являются членскими переменными класса (объявленный в другом месте) и startCadence, startSpeed, и startGear являются параметрами функции.
class Bicycle
{
private int gear, cadence, speed;
public Bicycle(int startCadence, int startSpeed, int startGear)
{
// set the value of member variables from passed parameters
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
}
8 ответов
Я использую jQuery. Это действительно хорошо. Но я считаю, что мне удобнее работать с C #. Даже если это подмножество.
Не бойтесь Javascript, это красивый и мощный язык. А с такими фреймворками, как jQuery , Prototype и Dojo , манипуляции с DOM и AJAX значительно упрощаются, а кроссбраузерные проблемы в основном ушли в прошлое.
О скрипте # , Я согласен с ответом mcintyre321 . Последний выпуск более года назад + закрытый исходный код = мне нечего делать.
ОБНОВЛЕНИЕ Январь / 2010: с момента первоначального написания этого ответа было выпущено # новых сценариев. Он по-прежнему имеет закрытый исходный код, но автор упоминает его открытый исходный код после 1.0
ОБНОВЛЕНИЕ Май 2011 г .: Script # теперь является открытым исходным кодом .
Как и другие, я бы порекомендовал некоторый JavaScript (а именно jQuery). Если вы хотите продолжить работу со сценарием #, блог Nikhil Kothari может стать для вас хорошим ресурсом. http://www.nikhilk.net/ScriptSharpIntro.aspx - При этом, я думаю, вы обнаружите, что вы более продуктивны с jQuery. Существует большая база данных плагинов, написанных сообществом, поэтому вам не обязательно изобретать велосипед для всего, что вы хотите сделать. Плагины jQuery вместо элементов управления ASP.NET
IMHO Script # подходит только для больших проектов, с действительно "богатым" веб-клиентом. Участвуя в подобном проекте, я мог только сказать, что Script # нам очень помог. Замечание Джозефемингуэя о строгой типизации для такого случая на 100% верно. Также это позволило нам быстро представить новых .NET-разработчиков без какого-либо опыта работы с JS. Предполагая, что Nikhil Kothari планирует открыть исходный код летом 2008 года, мы даже декомпилировали (никому не говорите! Это незаконно) и представили дженерики, перегрузки операторов, различные исправления ошибок и т. Д.
НО. Затем поддержка Script # исчезла. Проект на CodePlex с обсуждениями и отслеживанием проблем был закрыт (интересно, что части фреймворка там незадолго до этого публиковались). Ни обновлений, ни планов на будущее, ни объяснений. После такого я d рассматривать Script # только после того, как он станет открытым исходным кодом, чтобы сообщество могло его поддержать. Например, на CodePlex.
Я использую Script #, я думаю, что это здорово. Вы можете использовать его с любым фреймворком, jQuery, dojo с чем угодно, однако вам придется обернуть фреймворк, это может быть большой работой ...
Это ' Единственное преимущество, как я вижу, заключается в том, что он позволяет разрабатывать javascript в строго типизированной среде. Я считаю, что это ОГРОМНАЯ выгода. Я отказываюсь разрабатывать языки со слабой типизацией, так как обслуживание - это кошмар.
Если же вам нравится работать со слабо типизированным языком, то вам не понадобится Script #.
Сегодня вышел релиз, поэтому приятно видеть, что он все еще активен.
Несмотря на отсутствие обновлений в прошлом и отсутствие открытого исходного кода, я все равно буду использовать его. поверх простого js. Вы можете прекратить использование Script # в любое время и в дальнейшем с помощью «скомпилированного» js, если он вам не нравится.
Я согласен с вами, Вал, хотя он действительно подходит только для больших проектов на основе js. Я не думаю, что вы получите много пользы от использования его для выполнения основных функций страницы, таких как проверка ввода формы и т. Д. Вероятно, не стоит его настраивать.
Однако, если вы интенсивно используете javascript и вам нужно реплицировать ООП, я считаю, что это необходимо. Такие вещи, как рефакторинг, становится настолько простым, что с простым js я бы никогда не стал проводить рефакторинг, потому что это было слишком сложно реализовать, со временем мой код превратился в беспорядок.
Вау, Вэл, у тебя есть дженерики для работы, я впечатлен, это было сложно? Было бы здорово поддерживать универсальные шаблоны, а также перегрузку методов и операторов. Вы уверены, что его декомпилировать незаконно, мне нужно посмотреть, соответствуют ли это условиям использования.
Ух ты, Вэл, у тебя есть дженерики для работы это, я впечатлен, это было сложно? Поддержка дженериков была бы замечательной, поэтому будет перегрузка методов и операторов. josephhemingway
Все дело в том, что парсер ScriptSharp поддерживает полный синтаксис C # 2.0. Единственное, что нужно, - это сгенерировать правильный JS. Не так много работы, учитывая динамический характер JS. Дженерики будут действовать как дженерики в стиле Java, то есть не генерировать для каждого набора аргументов закрытого типа, а только один класс.
Вы уверены, что незаконно декомпилировать его, мне понадобится посмотрите, если это условия использования. Джозефемингуэй
Ага, это незаконно. EULA, показанное в настройке, четко упоминает это.
Короче говоря, мой ответ таков: если вам нравятся мощные IDE, работающие под Windows, OOD и C#, используйте ScriptSharp. Он более ремонтопригоден и структурирован, и достаточно стабилен для использования в серьезных проектах. Его также можно легко расширить, как показано ниже и в других проектах.
Поскольку это еще одна тема, проиндексированная Google, где люди называют Script# и jQuery взаимоисключающими, я просто хотел указать на то, что некоторые люди объединяют эти два мира, и в моем случае высвобождают много сил, делая это. Я предлагаю совершенно бесплатную и многократно используемую библиотеку для доступа к jQuery 1.4 из проектов Script#, а также полный исходный код решения, которое его генерирует (почти исключительно из собственного файла документации API jQuery):